At 10:44 AM 2002-11-05 -0800, Michael Howard wrote:
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.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.
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?
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.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.
--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 - [EMAIL PROTECTED]
