Session Fixation & Cookies

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

Post Reply
User avatar
seodevhead
Forum Regular
Posts: 705
Joined: Sat Oct 08, 2005 8:18 pm
Location: Windermere, FL

Session Fixation & Cookies

Post 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 ;)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post 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
User avatar
seodevhead
Forum Regular
Posts: 705
Joined: Sat Oct 08, 2005 8:18 pm
Location: Windermere, FL

Post 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?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
User avatar
seodevhead
Forum Regular
Posts: 705
Joined: Sat Oct 08, 2005 8:18 pm
Location: Windermere, FL

Post 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.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post 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.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

heh, I forgot about those, albeit rare for me, instances. :)
User avatar
Benjamin
Site Administrator
Posts: 6935
Joined: Sun May 19, 2002 10:24 pm

Post 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?
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post 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.
yum-jelly
Forum Commoner
Posts: 98
Joined: Sat Oct 29, 2005 9:16 pm

Post 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!
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Post by josh »

Roja wrote:f 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.
Last time I checked PHP only puts the ID in relative URLs and URLs that are part of your domain.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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???
Post Reply