lol, no sooner had I spoke than it sprang back into action! I now have the source you posted. Looking it over!
"M1tch" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Okay, having had my own solution shot and burned ;), I would love to look at > yours, but unfortunately the page (well, the entire site), will not load. > It could be a temporary outage with either ISP, but is there anyway you > could post it here? (I perhaps flag it as large?). > > On my site, I'm not really bothered about most of the session data being > hijacked, because a user would still not be able to be malicious (any > serious function- like post article/forum message/etc) has a permission > check before it's executed, that verifies the username/password. > Of course, this then becomes a problem if the user has stored the password > in session, as this is the sensitive part. > > Why oh why is AOL so terrible. I didn't like them before, but now! Grrrrr > > Andy > > "Mar Tin" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > Dear all: > > > > Until I read the article "PHP Session security" > > (http://www.webkreator.com/php/configuration/php-session-security.html) > > I haven't noticed how insecure PHP Sessions are. > > > > > > > > Basically there're 2 problems: > > > > *) It's possible to hijack a session if you know the > > SID (session id) > > > > 1) If you're on a shared server (cheap webhosting) > > other users can get the SIDs by doing "ls /tmp/sess_*" > > (/tmp/ is defined on session.save_path on the config > > file, so it may be different). > > > > 2) When a user clicks on an external link, the > > browser sends the REFERER url and sometimes it > > contains the SID (if session.use_trans_sid is enabled) > > > > PHP offers a security measure: with > > session.referer_check it will reject SIDs comming from > > other referers, but the referer url can be easily > > forged. > > > > *) Users can read session data from the session files, > > which are owned by the server process (every user > > which has an account on the webserver can read server > > owned files) > > > > (If you're intrested in the subject I would recommend > > to read full the article: > > http://www.webkreator.com/php/configuration/php-session-security.html) > > > > I have developed some functions to avoid this > > problems. They replace the standard session functions > > (using session_set_save_handler), so you only have to > > include the file at the beggining of your script and > > (afaik) you're safe :) > > > > This is the idea: > > > > Apart from the session cookie, I set another one (with > > the same name and the string '_sec' appended). On this > > cookie I set a random KEY. > > The name of the file which contains the session data > > is the md5 hash of the SID and the KEY together. This > > turns impossible to guess the session id by looking at > > the filenames. > > > > To hide the data inside the file, the serialized > > string is crypted using the KEY as password, so nobody > > can see the content of your user's sessions. > > > > You can find the code here: > > http://www.n3rds.com.ar/files/docs/php_sessions/sess_handler.txt > > > > Im looking for suggestions to make it 100% compatible > > with the standard session functions, and I would like > > to hear some thougts about the idea > > > > Martin Sarsale > > [EMAIL PROTECTED] > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Finance - Get real-time stock quotes > > http://finance.yahoo.com > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
