|
|
Posted by Gordon Burditt on 10/18/05 11:19
>Thanks for the tips guys. I got my system working and sort of wrapped
>my head around the idea of session-based authentication.
>
>I decided to use IP based tracking. You and the following poster warn
>against this, but those problems shouldn't apply to my application.
>This application is being used on our intranet, so I'm not worried
>about dial-up users or users behind a proxy. Having said that, I don't
>know if it adds much -- I'm not expecting anybody to sniff SIDs on our
>local network, but I guess anything is possible?
Sniffing SIDs is much easier on a LAN than doing it from a different
country.
>To respond to Gordon, I'm not passing plaintext passwords around, only
>an MD5 hashed password. But your comment I found a little unsettling:
>are you implying that session variables (besides the session id) are
>transmitted over the network? I assumed that they were only resident in
>the server's memory, and the SID was the only data that was carried
>back and forth.
One (BAD!!) alternative to depending on sessions and having the
user enter a password on each page is to hide the password in a
hidden field on the next page, so it can be used again. This
involves sending the password in plaintext TO the user, and again
when the user submits the page, which makes it a really BAD idea.
However, if someone refuses to trust the secrecy of session IDs,
and they don't want the user to enter the password every page,
they're pretty much stuck with it. But since they don't trust the
secrecy of session IDs, I guess they don't trust the secrecy of
passwords either. Now they are REALLY stuck.
This is *NOT* what session variables do, unless you also include
the values of session variables in the output. Session variables
stay on the server unless your scripts do something with them. Now,
some session variables can be safely output to the page: "You now
have 3 items in your shopping cart, which are ...". Passwords
aren't one of these.
>What I am *now* concerned about is this: I'm not the only user with
>write access on our web server. So if my authentication simply consists
>of placing an authentication flag in the session variables, somebody
>could write a PHP script in another directory on the server which
>starts a new session, fills out that flag, and then redirects the
>browser to my supposedly "protected" page. The only thing preventing
>this is not knowing the name of that flag, but if I ever released my
>code to anybody else then my site would be compromised.
Session IDs are normally stored in cookies. A cookie in the XYZ
domain shouldn't be passed to you in the DEF domain. However, you
can't count on users not manually inserting cookies into their
browsers.
You can make the name of the "authenticated" flag configurable.
That's not a very good or secure solution.
This is a problem. It is possible to write a session handler which
stores session variables in your database rather than in a common
directory of files. Now, how do you keep your DB password secret
in such an environment, such that YOUR scripts can use it, but the
other guy's scripts can't, both running on the same instance of
Apache and PHP? The DB password issue is relevant even if you
don't use sessions or don't put sessions in the DB - anyone who
can write to your DB can add themselves to the user list.
If you were concerned before, you should be really frightened now.
About the only semi-good answer I've heard for multiple potentially
mutually-hostile customers on the same box involves (a) you have
to trust the admin of the box to set this up, and (b) the admin
puts the parameters for your DB in the Apache config file inside a
<Virtualhost> directive, so each site only sees its own password,
(c) use the default setup to connect to the DB, and (d) I think
safe mode has to be on and no site is allowed to access the Apache
config file and preferably no site is allowed to open files in
another user's tree. Some of this may go out the window if any
user is allowed to write and install his own CGIs not subject
to PHP safe mode.
>So right now I'm sticking with checking the database on each page. My
>app doesn't have a lot of simultaneous users (not many users totally
>actually, its a backend tool for the IT dept.), and the intranet web
>server in general runs at no load, so this overhead isn't a problem.
>Really, the application isn't even so important that I expect people to
>go to these lengths to crack it. My real goal here is to learn
>something, so that if on a future project I really do need to "do it
>right", I'll know what that takes.
>How does a timeout work? Does PHP do it automatically or do I need to
>compare timestamps to decide when the timeout period has elapsed?
php.ini has some parameters for automatic session cleanup, primarily
for getting rid of long-abandoned sessions so your disk doesn't
fill up or the number of files in a single directory doesn't make
the system slow to a crawl. You can also put a timestamp (probably
updated on each page hit) in the session and compare yourself, if
you want to be sure of on-time expiration.
Gordon L. Burditt
Navigation:
[Reply to this message]
|