PHP security question: sessions vs cookies
I just want to know which is better to handle user authentication issues...
I currently use the default session handling (which is cleaner and is more portable). But should cookies be used explicitly to handle this? Which is better? The session handling functions or the cookie functions? |
AFAIK, PHP *relies* on being able to write cookies in order to *implement* "sessions", doesn't it? Once you create a session, aren't you implicitly using cookies anyway , whether or not you explicitly read or write cookies in your own PHP code?
|
I know that. But there are cookie functions which allow me to set cookies explicitly.
Sessions work even if cookies are disabled, but uses the query string in the browser to keep track of the session vars. I read somewhere that this may be a security risk, but I cannot seem to find it. Anyway, most users have cookies enabled. Which way would create portable and secure code? |
The security problem with encoding stuff in the URL is two-fold:
1. It's easily read (even more easily than the stuff in forms you'd have to "view source" to see), revealing (possibly unwanted) details about your web application's internals 2. It lends itself to cross-site scripting attacks (people can cut/paste from the URL to manually access different parts of the web app, perhaps subverting it). Here's a link that gives a *much* better explanation than I'm doing (sorry! it's late ;-): http://www.cgisecurity.com/articles/xss-faq.shtml A great book covering an *extremely* wide range security issues is: Security Warrior, Peikari & Chuvakin 'Hope that helps .. PSM |
Quote:
sure there are some security concerns, but imo they are *at worst* balanced with cookies. the technique i use to preserve the session id is to pass the id using GET.. the requested page then checks the session id with a database that contains active sessions that allows only one session per userid.. the system checks the request against the current session, referrer url, ip address, and i had implemented a timestamp but threw it out due to being a bit of an overkill for my purposes. if anything does not match the user info in the db, the session is erased and the user is forced to login again. while it may be possible to hijack a session using this method, it is extremely unlikely. if you would want anymore info feel free.. i worked a while on this system and built it from scratch.. so i feel like i have a pretty good understanding of any security concerns with it.. |
Harishankar -
Everything Xhi is saying is correct. A couple of additional points: 1. "mm" is completely a server-side thing. It has nothing directly to do with the "cookies vs URL" issue we were discussing: http://us3.php.net/session http://www.sitepoint.com/article/p3p-cookies-ie6/2 2. Here's a bit more on the "session hijacking" Xhi mentions: Quote:
3. PHP "global variables" is another potential security risk. Newer versions of PHP all default to "register_globals = false" (in php.ini): Quote:
4. To the extent you're using PHP "out of the box" (it sounds like Xhi has done considerable work on his own infrastructure), cookies are arguably the best, easiest, most reliable way to go. IMHO .. PSM |
Quote:
Quote:
good description on the session hijacking.. that is why i would recommend doing checks on ip address and referrer url along with the session id.. and of course you are correct on the global variables.. they should *never* be enabled.. my only reasons for using cookieless sessions were that i just do not like using cookies and wanted to see if i could implement a fully functional site without cookies.. i did and so i ran with it.. |
I am creating a script where I cannot predict how the server set up will be like since I'll release it to the public.
My script is a simple CMS system (GPL license) with a small number of features to build a website. Actually I think at present I'll stick to the session management that is built in to PHP. When I complete my script, I would be glad if experts could take the code, see what security flaws exist and so on. I'm doing all the basic security things like converting form data into correct data type and converting to mysql query safe strings and such. I am also writing the code to be entire using $_SESSION vars and checking if they are set and so on. That's what Open Source is for, isn't it? Learning something new all the time. :) |
After reading a bit about sessions, I decided to use a cookie to encode a particular string and store it in the user's browser.
Unless the cookie is set with this value, the administrator session will not authenticate even if the session Id is correct. Will this be of any value? Or is it weak? |
yes thats not a bad idea..
one thing i had done was everytime a user is registered they have a unique hash entered in a userhash db.. you could store a hash of a hash, or hash of part of a hash, etc in the cookie and test against the admin hashes in the db.. |
I'm also using JavaScript to MD5 encrypt the password before it's submitted. Since this is a single user application (CMS with one user only) is that a good idea? Anyway, I guess most people have JavaScript enabled. Otherwise the password will not work.
|
All times are GMT -5. The time now is 03:58 PM. |