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 (at) scifi.squawk (dot) com [email concealed]
>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 (at) scifi.squawk (dot) com [email concealed]
[ reply ]