|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
RE: How to protect against cookie stealing?
Date: Thu Jul 24 2003 - 07:33:55 EDT
Well, there are only a limited number of things that one can do.
The objective is to detect a change when a request is made. What information can we check against?
- Source IP address - can change if behind a proxy server array, doesn't protect against other users behind the same proxy
- SSL sessionid - helps if you are using SSL, but this can also change, I think. Particularly if the session is idle for a while?
What else? Here is a sample request:
POST http://localhost:8080/WebGoat/attack HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword,
application/x-shockwave-flash, */*
Referer: http://localhost:8080/WebGoat/attack
Accept-Language: en-za
Content-Type: application/x-www-form-urlencoded
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: localhost:8080
Content-Length: 0
Pragma: no-cache
Cookie: JSESSIONID=5971DC264B764275ED682A353BD3D44C
- Accept header - this is unlikely to change, but is easy to guess
- Accept-Language - most likely to be en-us, but could vary. Worth adding, anyway.
- UserAgent - one would have a reasonably good chance of guessing this. A single incorrect guess should invalidate the session, although that would lead to DOS, perhaps.
I would be inclined to make up a validation string comprised of a hash of (Accept: + User-Agent: + Accept-Language:) at the time of the user's login and check that on every request. If it ever changes, immediately invalidate the session, and warn the real user when they make a request with the correct string, that someone is trying to access their session.
One could also check against the source IP as a precaution, and at least flag sessions where the source IP changes as potentially being compromised. Quite what you would do with that, I'm not sure :-)
One flaw with this scheme, though: If the attacker manages to execute some script or other scheme to get the sessionid to their server, they would be able to reap the headers as well :-(
Bang goes that theory. :-(
That brings us back to source IP and SSL sessionid.
IIRC, proxies are supposed to add an X-Forwarded-for header to the request headers. That could allow the server to track request that occur across different proxies. However, an attacker that does not go through a proxy would also be in a position to add such a spoofed header, and they would be able to reap it from the request that delivered the sessionid. If they were behind a proxy, they could also add that header, but it might be overwritten by an upstream proxy?
One could, over time, build up a list of IP addresses of known proxies, and source ranges that they serve. That could work, but would take time to build up.
Which leaves SSL sessionid. I'm not sure how reliable that is, and it doesn't help non secure sites.
Which I think explains why no-one has done anything about this problem! :-)
Rogan
Important Notice: This email is subject to important restrictions, qualifications and disclaimers ("the Disclaimer") that must be accessed and read by clicking here or by copying and pasting the following address into your Internet browser's address bar: http://www.Deloitte.co.za/Disc.htm. The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to ClientServiceCentre(at)Deloitte.co.za. Received on Thu Jul 24 12:59:47 2003
This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 14:07:54 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |