WebApp Sec mailing list archives
RE: How to protect against cookie stealing?
From: ".:[ Death Star]:." <deathstar () optonline net>
Date: Fri, 25 Jul 2003 05:39:59 -0400
Mr. Dawes, I agree with you regarding the XSS issues. The question that we all need to answer to is how critical is the content that we are trying to protect in the first place. If the website is a company private site that only needs to be accessed by customers, employees, and partners, and the integrity of the information is a top priority then using such thing as ActiveX is important at the time being. Of course there will always be the danger of a smart cracker sitting in the background eavesdropping and stealing sessions (haven't you known by now that there is no such thing as 100% secured). I believe that we as security professionals need to promote security up to its most extents while keeping other things in mind (such as privacy, Performance, and budget). If someone needs to totally 100% protect the sessions of his/her website from crackers I advice him/her to shut it down. Another thing, if we to eliminate things like proxy's that provide anonymity then we are destroying the only thing left out there to protect the privacy of the user. So we are left with no choice but to take the position of sitting ducks waiting to be hunted. Issues such as sessions and cookies will always raise a red flag. A new solution needs to take place; for example, using smart cards in the identification process when a user wants to buy something online (just like the Blue card from American Express). There will always be proxies, there will always be spoofers, and there will always be uber haxors, and no matter what we do, until we have the actual access control generated physically from the user station there will always be session hijacking. Regards, Tarek. -----Original Message----- From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za] Sent: Friday, July 25, 2003 2:34 AM To: '.:[ Death Star]:.'; 'Phil Cox'; webappsec () securityfocus com Subject: RE: How to protect against cookie stealing? Hi Death, :-) The reason that one can't simply link the IP address to the session is that there are ISP's, in particular AOL, that use cache arrays in a load balancing configuration. So a request that goes through one proxy could be followed by one that goes through a different one. Plus the fact that all users behind a single proxy would be seen to have the same IP address. A lot of people do not permit active content such as ActiveX objects, which would be the only way to get the MAC address from the client. Besides which, if the originating site can access this object through a script, so could the attacker through an XSS, and supply that information to the attacker at the same time as the sessionid. I think this is the reason that nothing has been done about this problem: * If the attacker can't XSS the user, they can't get the sessionid (unless it is predictable, which is just stupid!), hence there is no problem. * If the attacker CAN XSS the user, then they can also get whatever other information that they need to impersonate the user, except for the IP address, which unfortunately, we can't rely on anyway, so we CAN'T do anything about the problem. Rogan
-----Original Message----- From: .:[ Death Star]:. [mailto:deathstar () optonline net] Sent: 24 July 2003 07:14 PM To: 'Dawes, Rogan (ZA - Johannesburg)'; 'Phil Cox'; webappsec () securityfocus com Subject: RE: How to protect against cookie stealing? It is possible to associate each session ID with one IP address. In other words, you can make your script reject sessions generated from the same IP (this is to avoid proxy's having the same IP address for different sessions and the same IP address requesting an existing session). This can be done by keeping an active table of sessionID's and associated IP's. There is another solution, you can use both sessionID's and cookies, so based on the IP address you would look for the cookie before giving the user access control. The session ID will store 2 fields (example userid and associated ip address) the cookie will hold other fields. And u can use multiple sessions and multiple cookies that will be destroyed upon opening another page. Another solution is to create a script that will place an object on the user machine this will allow your server not only to check the ip (user gateway or proxy) but also the MAC and the local IP associated with it (could be the local IP of the user) and this info will also be associated with the gateway IP (public IP of the user). -----Original Message----- From: Dawes, Rogan (ZA - Johannesburg) [mailto:rdawes () deloitte co za] Sent: Thursday, July 24, 2003 7:34 AM To: 'Phil Cox'; webappsec () securityfocus com Subject: RE: How to protect against cookie stealing? 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-----Original Message----- From: Phil Cox [mailto:Phil.Cox () SystemExperts com] Sent: 24 July 2003 07:34 AM To: webappsec () securityfocus com Subject: How to protect against cookie stealing? All, I have a question on how people are handling cookie stealing and session segregation. For example, it is possible to use session cookie information on multiple systems for most (all?) web applications I know of. Here is a scenario: When a user logs in he is assigned a BLAH_SESSIONID cookie which serves as an authorization mechanism in the application. The application does not associate the cookie to any session-specific information (e.g., source IP address), so another user can also use the BLAH_SESSIONID cookie to access the same information (over a different TCP/IP session) that the legitimate user can. If an attacker obtains, or guesses a valid BLAH_SESSIONID cookie for an active session, he can use it without the user'sknowledge. Forexample, I was able to execute the following command using an BLAH_SESSIONID that was obtained from another session: Command on Linux box: # curl -b "BLAH_SESSIONID=0000FDHTNLVY5WX" https://somesite.com/App/Function? Returns the page: (some portion of the returned page) Historically I have believed that having the applicationassociate theBLAH_SESSIONID session cookie and its associated privileges with a specific SSL session or source IP address would prevent this session stealing. But recently I have been told that this solution does not work because of the dynamic IP nature of MANY ISP's and the disassociation of SSL/HTTP. I would like to know what others are doing to solve this problem, or if they are just not solving it at all. Thoughts and comments are appreciated... PhilImportant 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 () Deloitte co za.
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 () Deloitte co za.
Current thread:
- Re: How to protect against cookie stealing?, (continued)
- Re: How to protect against cookie stealing? Marc Slemko (Jul 27)
- RE: How to protect against cookie stealing? Dawes, Rogan (ZA - Johannesburg) (Jul 24)
- RE: How to protect against cookie stealing? .:[ Death Star]:. (Jul 24)
- Re: How to protect against cookie stealing? Chris Green (Jul 26)
- Re: How to protect against cookie stealing? Erik Kangas, PhD (Jul 26)
- RE: How to protect against cookie stealing? .:[ Death Star]:. (Jul 24)
- RE: How to protect against cookie stealing? Ingo Struck (Jul 24)
- RE: How to protect against cookie stealing? Gabriel Lawrence (Jul 27)
- Re: How to protect against cookie stealing? Mark Reardon (Jul 24)
- Re: How to protect against cookie stealing? Ken Anderson (Jul 24)
- RE: How to protect against cookie stealing? Dawes, Rogan (ZA - Johannesburg) (Jul 27)
- RE: How to protect against cookie stealing? .:[ Death Star]:. (Jul 27)
- RE: How to protect against cookie stealing? Dawes, Rogan (ZA - Johannesburg) (Jul 27)
- RE: How to protect against cookie stealing? Dawes, Rogan (ZA - Johannesburg) (Jul 28)
- RE: How to protect against cookie stealing? PortSwigger (Jul 29)