Re: A technique to mitigate cookie-stealing XSS attacks

[Nick Simicich <njs () scifi squawk com>]

At 10:44 AM 2002-11-05 -0800, Michael Howard wrote:

> During the Windows Security Push in Feb/Mar 2002, the Microsoft Internet
> Explorer team devised a method to reduce the risk of cookie-stealing
> attacks via XSS vulnerabilities.

If I understand  the XSS vulnerability correctly, it is all based on the 
ability of javascript to access cookies through the document.cookie 
property.  If I can convince a web server to return my user specified 
javascript to the browser such that it is executed by the browser, it can 
invoke a url that pulls (say) an image from an attacker's web site with the 
cookie exposed, which might allow the cracker to access the site as me.

Your point is that everyone who is worried about this can freeze the 
cookies away from the javascript --- the website designer is incented to 
change this because they will want to make their app more secure, and the 
end user is incented to install the fixes to their browser because Windows 
update will tell them to anyway.

I tried a google search for document.cookie.  It showed "about 181,000" hits.

Every hit I looked at was an "example" of how to use this property.

Has anyone looked at the impact of simply changing the default:  Do not 
allow cookies to be accessed from javascript unless they were set from 
javascript in the first place, or have a trailing jscript on any cookie 
that *should* be returned by document.cookie.

This essentially instantly secures all legacy apps that do not use 
javascript at all.

It also instantly cures all legacy apps that use javascript, but which 
never use document.cookie.

It allows people who use cookies to communicate from one piece of 
javascript to another to keep working.

The only thing that breaks is the subset who set a cookie with the 
set-cookie header who then want to access the cookie with javascript, and 
as others note, that just is not done much.  You could even combine this 
with a security zone setting (perhaps) or a flag on the cookie that does 
the reverse of what you talk about here --- specifically says that this 
particular cookie is OK to cross to the the javascript.document.cookie 
space from the set-cookie space.

Has anyone done the analysis? What breaks?

> In a nutshell, if Internet Explorer 6.0 SP1 detects a cookie that has a
> trailing HttpOnly (case insensitive) it will return an empty string to
> the browser when accessed from script, such as by using document.cookie.

I personally think that there are so many better ways to do this that, even 
though your goal is laudable, making this quick patch will require that it 
be supported forever...it might be best not to cross this chasm in two leaps.

> Obviously, the server must add this option to all outgoing cookies.
>
> Note, this does _not fix_ XSS bugs in server code; it only helps reduce
> the potential damage from cookie disclosure threats. Nothing more. Think
> of it as a very small insurance policy!
>
> A full write-up outlining the HttpOnly flag, as well as source code to
> set this option, is at
> http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp.
>
> Cheers, Michael Howard
> Secure Windows Initiative
> Microsoft Corp.
>
> Writing Secure Code
> http://www.microsoft.com/mspress/books/5612.asp

--
If you doubt that magnet therapy works, I put to you this observation: When 
refrigerators were first invented, in the 1940s, they were rather 
unreliable, but then they became significantly more reliable. The basic 
design of the refrigerator did not change, and we all know that quality was 
important back then, so I doubt that newer refrigerators are made better. 
Refrigerators have become more reliable because of the rise of the 
refrigerator magnet.
Nick Simicich - njs () scifi squawk com