WebApp Sec mailing list archives
Re: Cookie stealing and replay in a corporate single sign on environment
From: "Willard Fernortner" <fernortner () hotmail com>
Date: Wed, 15 Jun 2005 11:34:32 -0400
Irene,I think you missed my point about SSL not being able to protect SSO cookies. I'm really not concerned about someone stealing cookies by sniffing network traffic (which is what SSL would protect), but rather I'm concerned that Cross Site Scripting flaws can be used to steal cookies EVEN when SSL is used. SSL simply cannot stop cookie stealing via Cross Site Scripting... it only ensures that nobody can see the exploit as it travels through the SSL tunnel.
WF
From: Irene Abezgauz <irene.abezgauz () gmail com> Reply-To: Irene Abezgauz <irene.abezgauz () gmail com> To: Willard Fernortner <fernortner () hotmail com> CC: webappsec () securityfocus comSubject: Re: Cookie stealing and replay in a corporate single sign on environmentDate: Wed, 15 Jun 2005 13:50:43 +0200 Willard, To me SSL seems like a good solution to the problem of replaying attacks. The cookie is never sent individually but is encrypted together with the request as a whole, meaning you cannot just "extract the cookie part" and then replay it. You could say that since you know the size of the encryption block you could guess where the cookie is (however unpractical that may seem). And yet, if you guessed where the cookie is and extracted it, and even if theoretically the cookie is floating around between the servers holding a note saying "sniff me", it won't help since each individual SSL connection has a different set of keys so you can't just send it in your own connection. If the servers don't use SSL among themselves it is a problem, not a cookie related problem but generally "A Problem". Irene Irene Abezgauz Application Security Consultant Hacktics Ltd. Mobile: +972-54-6545405 Email: irene () hacktics com Web: www.hacktics.com On 6/15/05, Willard Fernortner <fernortner () hotmail com> wrote:> I'm wondering if anyone else has given thought to cookie replay attacks when> using a web single sign-on solution on a corporate network. Here are my > concerns: >> -- Web single sign-on typically works using a shared cookie that is passed > to all intranet web sites in the corporate domain (e.g. *.myintranet.com). > Because these cookies are passed to ALL internal web sites, there are plenty> of opportunities for these cookies to be stolen: >> a) They can be harvested by employees, contractors, or anyone else that > is allowed to publish a web page to ANY corporate web site (through server> log files or through JavaScript on published web pages)> b) They can be stolen using a cross site scripting flaw on ANY web site> in the corporate domain > > -- Once an SSO cookie is stolen, the attacker can use that cookie to> impersonate the victim to HR, financial, or other sensitive web applications> that the victim has access to. The implications could be huge. >> -- Most people I've talked to appear to be clueless that a problem exists. > I often hear "we use SSL" when bringing up the issue. SSL doesn't matter.> Cross site scripting can be used to steal cookies regardless of SSL use.> Similarly, I often hear "the SSO cookie is encrypted". That doesn't matter> either. I just need to replay the encrypted cookie "blob" in an attack. >> Aside from "don't use single sign on" and "use certificates" (neither are > options for us for several reasons), what can be done to mitigate the risks?> I've considered the following: >> -- Track the IP address of the legitimate user when they authenticate, then> validate that the user is coming from the same IP address for each> subsequent request to the SSO environment. Most SSO vendors support this> out of the box. However, IP addresses can be spoofed (it's not hard to > spoof your bosses IP address when you are on the same subnet), and IP > validation doesn't work in NAT environments. Still, I think this is > probably the most feasible option. > > -- Use timeout values to force periodic re-authentication. However, > reauthenticating too often defeats the purpose of SSO. >> -- Use some sort of nonce so that cookies can only be used one time. This > probably wouldn't work well in an SSO environment when a user might want to> have multiple web applications open at once though. > > -- Put sensitive applications into a separate sub-domain (e.g.> *.secure.myintranet.com), then use a separate SSO cookie for that specific> domain. > > Any other thoughts? Has anyone else here implemented SSO on a corporate> network, and if so, are you doing anything to prevent cookie stealing and > replay? If you aren't doing anything, is it due to ignorance, or have you> specifically decided not to address the problem? Why? > > Thanks > WF > > >
Current thread:
- Cookie stealing and replay in a corporate single sign on environment Willard Fernortner (Jun 14)
- Re: Cookie stealing and replay in a corporate single sign on environment Irene Abezgauz (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Willard Fernortner (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Irene Abezgauz (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Willard Fernortner (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Willie Northway (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Saqib Ali (Jun 15)
- <Possible follow-ups>
- RE: Cookie stealing and replay in a corporate single sign on environment Cyrill Osterwalder (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Ivan Ristic (Jun 15)
- RE: Cookie stealing and replay in a corporate single sign on environment Cyrill Osterwalder (Jun 15)
- Re: Cookie stealing and replay in a corporate single sign on environment Irene Abezgauz (Jun 15)