Cookie Question

Ace_Online

I am storing (or plan to store) important information in a cookie. Therefore, I do not want people to be able to view the information in the cookie. When I store the cookie I do not put a time of expiration, so the cookie expires when the person closes his or her browser (or executes the logout script). I noticed that when I set the cookie to expire when the browser closes, it is not stored in the temporary internet files along with all of the other cookies which have expiration times. Therefore, I can not access the information by means of searching the temporary internet files. So my question is..... is the cookie information stored on the hard drive if you do not set an expiration time? And how secure is it to store important information in this type of cookie? I will be using ssl.

Thanks,
Ace

bretticus

My first suggestion would be not to store sensitive information is cookies period. It seems to me you can store the same information server-side in $_SESSION array. Sessions write a "key file" temporary cookie to your browser and keep the contents server-side, so it's basically the same thing, just more secure.

If you're expecting literally tons of session data you may want to store less sensitive information client-side, but I would highly NOT recommend it.

bretticus

PS....

To answer the cookie question...

Yes, you can set the cookie to not timeout for longer period of time, hence it's no longer a temporary cookie. If you need to do this and the data is sensitive, as you say, I would suggest storing the information in a database like MySQL, etc, instead.

Ace_Online

I would do the session setup, but I don't know how to get the session to terminate if the user decides to close his or her browser.... is that possible?

bretticus

The session cookie is a temp cookie and should die when your browser is closed as long as you don't spawn a browser window from a window that was spawned by the window of the session window ;-) At least that's the way IE seems to work ;-)

In words that should be much easier to digest, if you had just one browser window open and had the temp cookie, by closign that window and then running the browser again, that temp cookei should be gone.

Ace_Online

Yes, but when the temp cookie is destroyed, can the session be destroyed also? I experimented with sessions before and sometimes I could not close them and so there were a lot of sessions still open on the server (the files were still in the /tmp directory) and I could not delete them from the web.

So I'm mainly just concerned about my /tmp folder not filling up with open sessions and then other unauthorized people being able to re-open these sessions that are still on the server.

bretticus

Hmmm.... I'm not sure on this.

I believe....and you may have to experiment here...that the session.cache_expire value in your php.ini controls how long a session can stick around being inactive.

This is do know though. The session will time out and the data in /tmp will go away ;-)

Another suggestion is to use the JavaScript onUnload event in your body tags to destroy destroy sessions, but this probably requires opening popups windows and get's complicated if the users are simply surfing around where they should keep their session active.

bretticus

By the way...

Since you're using SSL, in theory, no "man-in-the-middle" should be able to hijack a session id. They would have to be able to guess a limited number of session ids out there that do not follow any predictable sequence. If you want to add an additional level of security, you could have an include script that sets $SERVER['REMOTE_HOST'] to a session variable and then checks the current $SERVER['REMOTE_HOST'] against the session cached value.

Jayson

Originally posted by bretticus
By the way...

Since you're using SSL, in theory, no "man-in-the-middle" should be able to hijack a session id. They would have to be able to guess a limited number of session ids out there that do not follow any predictable sequence. If you want to add an additional level of security, you could have an include script that sets $SERVER['REMOTE_HOST'] to a session variable and then checks the current $SERVER['REMOTE_HOST'] against the session cached value.

I disagree with checking the ID against REMOTE_HOST. Some service providers (mainly AOL :rolleyes: ) will have a different IP address with each request. So that wouldn't work. Those people wouldn't be able to use your site, and you'd effectively be shutting out, how many million? 35 million AOL users? And whatever other ISP's use this same method.

I think a uniquely generated key, say, 50 bytes of alphanumeric characters or longer, should be sufficient for identifying someone in a session.

Like bretticus already suggested, the sensitive data could be stored in $_SESSION, or in some MySQL database.

bretticus

I disagree with checking the ID against REMOTE_HOST. Some service providers (mainly AOL ) will have a different IP address with each request. So that wouldn't work. Those people wouldn't be able to use your site, and you'd effectively be shutting out, how many million? 35 million AOL users? And whatever other ISP's use this same method.

Are you saying that AOL users will be changing ips during the lifetime of a session??? Is this some kind of dynamic proxying specific to AOL???

Keep in mind, the session dies eventually and even if it doesn't the next time they make a request (after losing the temp cookie), they are assigned a new session. If you are referring to DHCP then I must disagree with you...

Now, this does bring up a good point, you may have to look for a X_FORWARDED_FOR header to be certain that you are not just checkign the proxy server each time.

Please elaborate on the AOL issue for me Jayson. It may be that I just have no clue how AOL, in particular, does things. However, I cannot imagine that anybody would have dynamic random proxying for hosts or whatever it would be called.

😃

Jayson

Originally posted by bretticus

Please elaborate on the AOL issue for me Jayson. It may be that I just have no clue how AOL, in particular, does things. However, I cannot imagine that anybody would have dynamic random proxying for hosts or whatever it would be called.

😃

I don't know why they do that, but that's how it works. Check the logs on your site sometime for the people that are on AOL. It looks something like this... taken from my site:

152.163.188.4 - - [19/Oct/2002:17:50:47 -0700] "GET / HTTP/1.0" 200 30508 "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.189.172 - - [19/Oct/2002:17:50:47 -0700] "GET /menuhover.js HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.189.67 - - [19/Oct/2002:17:50:49 -0700] "GET /gfx/menumissionover.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.188.72 - - [19/Oct/2002:17:50:50 -0700] "GET /gfx/menusuccess.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.189.66 - - [19/Oct/2002:17:50:52 -0700] "GET /gfx/menusuccessover.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.188.161 - - [19/Oct/2002:17:50:52 -0700] "GET /gfx/menuhistory.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.189.237 - - [19/Oct/2002:17:50:52 -0700] "GET /gfx/menutv.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.189.100 - - [19/Oct/2002:17:50:52 -0700] "GET /gfx/menuinteract.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.188.36 - - [19/Oct/2002:17:50:53 -0700] "GET /gfx/menueventsover.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.188.194 - - [19/Oct/2002:17:50:53 -0700] "GET /gfx/menuevents.jpg HTTP/1.0" 304 - "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"
152.163.188.36 - - [19/Oct/2002:17:50:55 -0700] "GET /gfx/menumulti.jpg HTTP/1.0" 200 2768 "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"

I don't have reverse lookups turned on on my server at the moment, but those are AOL IP's. That's all one viewing, loading the homepage and the graphics on it, and each request is a different IP.

bretticus

Hmmm....

I see your point. Are you sure it's not just because to use AOL you get the exact same browser?

However the times are very close...

Very interesting...

If this were proxy traffic would the header say it was something besides "Mozilla/4.0 (compatible; MSIE 5.5; AOL 6.0; Windows 98)"? "cause they almost look like different hosts allthough I've never looked at my logs that in-depth.

Okay, well, check for AOL in the header in your logic (then somebody just spoofs and they bypass that ... allbeight not too likely to do that and guess an active php session id;-)