Page 1 of 1
Session Fixation & Cookies
Posted: Sat Feb 18, 2006 6:44 pm
by seodevhead
If you are only using cookies on your website using the set_cookie() function... do you have to worry about session fixation/hijacking?? Using cookies only does not in anyway use session data, correct? Because I am only using cookies, I don't have to worry about using such preventitive functions such as regenerate_session_id(), etc.
Is the only concern for cookie theft XSS and browser bugs??? I just wanted to ask and make sure before I move forward. Reading some security tutorials left me a bit confused as to whether or not session data is used in conjuction with cookies... that is... set_cookie().
**** I'm sorry - I meant to post this in PHP Security Forum - Please Move *****
d11wtq | Moved 
Posted: Sat Feb 18, 2006 6:57 pm
by josh
If someone gets the sessionID they own the session, if you are storing the session in the cookie it is a bit trickier for an attacker then if they could just grab the URL. In my opinion the sessionID should go in the cookie and not anywhere else so you don't have to worry about users copying and pasting it into emails and that kind of thing. If your website has an XSS bug the attacker can still easily grab the cookie. Additional measures should be taken
Posted: Sat Feb 18, 2006 9:04 pm
by seodevhead
So by using the set_cookie() function only... I am not even utilizing sessions at all... or session ID's for that matter. Is that correct?
Posted: Sat Feb 18, 2006 9:10 pm
by feyd
you're circumventing any advantages and disadvantages you'd gain or lose by using the built-in session handling. Knowing how to handle sessions manually is a good thing to know, but I don't recommend it unless you know what you're doing.
Posted: Sat Feb 18, 2006 9:15 pm
by seodevhead
The reason I am a bit paranoid is because my script parses URL's much like these forums do. What I would hate to see is some hacker using that feature of automatic URL parsing to links in my scripts to create a link to steal someone else's cookies. I'm not too keen on how this is done... but are there any preventative measures I need to take with such a feature enabled for a script?
Like I said... I am only using cookies.. so I am not sure if a hacker could append a ?PHPSESSID=1234 to the end of a link and cause trouble.
Posted: Sat Feb 18, 2006 9:33 pm
by feyd
write your scripts correctly and they won't be able to inject HTML that would actually alter your page.
The session id used by php is fairly secure, last I checked. If someone can get my session id via a url, they can get it via the cookie too. Both require the same attack. Neither is secure as you think. The only difference with cookies and url is if the user happens to copy the url with the id in it.
As always, when doing an administrative thing, require them to input their password again. It's a bit annoying, but a price you pay for increased security.
Posted: Sun Feb 19, 2006 12:53 am
by Roja
feyd wrote:The session id used by php is fairly secure, last I checked. If someone can get my session id via a url, they can get it via the cookie too. Both require the same attack.
Thats not totally accurate.
The difference is the http_referer field. If my session_id is in the url, and I go to
http://example.com/evil_hacker.php , it can see the session_id in the url, and they could steal it from there. Cookies don't do that.
Another issue is on SSL. Cookies sent via ssl are part of the stream, and thus encrypted in transit. The url however, is not - leaving it able to be sniffed cleartext in transit.
Cookies, oddly enough, are slightly more secure as a result.
Posted: Sun Feb 19, 2006 1:25 am
by feyd
heh, I forgot about those, albeit rare for me, instances.

Posted: Sun Feb 19, 2006 3:15 am
by Benjamin
I recently wrote a login script which does the following:
1. Creates a random alphanumeric 10 digit string
2. Captures the users IP address
3. Gets a timestamp in microtime
3. Stores the random string in a cookie or session
4. Sets another session or cookie value to true
5. Stores all this in a database of logged in users.
When the user clicks on another page:
1. The database is queried with a select statement such as "select * from logged in where ip=$remote_ip and sessionid=$sessionid"
2. If no rows are retrieved the session is destroyed
3. If a row is retreived and the user hasn't clicked on any pages within the last 600 seconds the session is destroyed
4. If everything is ok, the datatbase is updated with a new microtime.
So basically it's binding a login to an ip and a cookie for a certain amount of time, and not even the customer number is stored in a cookie. Is this pretty secure?
Posted: Sun Feb 19, 2006 7:26 am
by AGISB
agtlewis wrote:I recently wrote a login script which does the following:
1. Creates a random alphanumeric 10 digit string
2. Captures the users IP address
3. Gets a timestamp in microtime
3. Stores the random string in a cookie or session
4. Sets another session or cookie value to true
5. Stores all this in a database of logged in users.
When the user clicks on another page:
1. The database is queried with a select statement such as "select * from logged in where ip=$remote_ip and sessionid=$sessionid"
2. If no rows are retrieved the session is destroyed
3. If a row is retreived and the user hasn't clicked on any pages within the last 600 seconds the session is destroyed
4. If everything is ok, the datatbase is updated with a new microtime.
So basically it's binding a login to an ip and a cookie for a certain amount of time, and not even the customer number is stored in a cookie. Is this pretty secure?
This is pretty secure but can be a problem with AOL users and other proxy users. They might have to login each page they access. However I have the feeling that the proxy problem is way less iminent today as it was a couple of years back.
Posted: Sun Feb 19, 2006 1:46 pm
by yum-jelly
So what happens to the person who does not even allow for a session based cookie. I mean security starts at the script level, if you think PHP core functions are good enough then you need to rethink that logic. Because using things like session_transid or just putting session_start() is not very good logic. Session high jacking more than half the time results from using core functions. Go search google, for common session names you will see it. It only take maybe one or two lines of code to built a simple if(when to add, when not to add) type control that is used based on what the user allows. So I guess I am saying is, restrictions placed on a user only means you as the developer did not incorporate the best logic in your script or service. As for session high jacking, it not your problem if you have developed a secure system, the only thing you can do is educate your users so they understand what is the best way to use your service. I think people waste to much time on security, less is always better, because the more you try to protect against will result in more chances you have left a opening.
yj!
Posted: Sun Feb 19, 2006 1:50 pm
by josh
Last time I checked PHP only puts the ID in relative URLs and URLs that are part of your domain.
Posted: Sun Feb 19, 2006 1:54 pm
by feyd
right, but your browser, being the dumbie that it is, will send your session id in the referral header. Now, if you disable your referrals, that's different... but how many people actually do that? Not many.
Posted: Mon Feb 20, 2006 12:21 am
by AGISB
yum-jelly wrote:So what happens to the person who does not even allow for a session based cookie. I mean security starts at the script level, if you think PHP core functions are good enough then you need to rethink that logic. Because using things like session_transid or just putting session_start() is not very good logic. Session high jacking more than half the time results from using core functions. Go search google, for common session names you will see it. It only take maybe one or two lines of code to built a simple if(when to add, when not to add) type control that is used based on what the user allows.
Thats why you do a timestamp based approach. Google indexes fast but not as fast as the session expires in a good designed system.
yum-jelly wrote:
So I guess I am saying is, restrictions placed on a user only means you as the developer did not incorporate the best logic in your script or service. As for session high jacking, it not your problem if you have developed a secure system, the only thing you can do is educate your users so they understand what is the best way to use your service. I think people waste to much time on security, less is always better, because the more you try to protect against will result in more chances you have left a opening.
Thats a statement that makes my toenails go up.
1. user restrictions are a very important and not a design flaw.
2. you cannot waste time on security.
3. educating users is a waste of time however. You get 1 of 1000 users to rethink and 999 go forward as always. As 1 hole is enough the 999 will work way more holes than that. So security is the only option you got. Disable the user errors as best as you can and you got a pretty secure system.
4. How can you leave openings by closing them? You might create a new one but well you have at least closed the known ones.
Posted: Mon Feb 20, 2006 8:28 am
by Maugrim_The_Reaper
So I guess I am saying is, restrictions placed on a user only means you as the developer did not incorporate the best logic in your script or service. As for session high jacking, it not your problem if you have developed a secure system, the only thing you can do is educate your users so they understand what is the best way to use your service. I think people waste to much time on security, less is always better, because the more you try to protect against will result in more chances you have left a opening.
Less is always the worst possible security design flaw. Less means you're not covering the obscure less publicised groups of security exploits. A key concept in security is Defense in Depth - not only do you add a security layer to prevent an exploit, you can also add second and third layers which may be redundant but exist on the assumption the primary layer will fails.
Never assume a single protection is enough - it's not. Human error makes it impossible for anything to be a certainty.
If I took your approach I might filter incoming variables and nothing else. But what about escaping output? What about $_SERVER variable filtering? What about user verification and permissions? What about CSRF? etc.
Less is an idea that ignorant developers promote. Not being offensive here

It's just a fact of PHP, you need to educate yourself in PHP security before you realise more security measures makes a more secure application, esp. if implemented consistently.
Leaving any security implementation decision to users is a waste of time. The vast majority neither care or know what they are, and why they exist. Besides most PHP apps still need cookies and javascript enabled. What else can a user do???