RE: A technique to mitigate cookie-stealing XSS attacks

["Jason Coombs" <jasonc () science org>]

Aloha,

Everyone interested in preventing XSS should review and understand

http://www.xwt.org/sop.txt

which is a vulnerability that combines XSS with bad data in DNS to allow an
attacker to hijack a Web browser (IE) and force it to function as a proxy
for requests of the attacker's choosing -- requests that can target any IP
address, including the intranet, but that are limited to HTTP/1.0-compliant
sites with http:// URLs and perhaps other URI prefixes that permit URL-style
remote procedure call instruction encoding where the browser or its OS
platform will, when presented with the URL, invoke a protocol handler and
pass it an instruction buffer.

> However, I'd like to point out that this security feature does not help
> prevent disclosure of information to third-parties that JS/VB (and more)
> have access to. (Highly browser dependent of course.)

In general, information should not be accessible automatically to Web
browsers. At the very least there should be a prove-you're-human
counter-measure deployed by Web applications that serve sensitive
information to browser clients (as opposed to XML Web services clients).

As for information served up by the browser itself, Cookies, History, Cache,
etc. none of this information should be provided automatically to a
requestor -- that is, a thread of execution controlled by a script or other
code -- one could even argue that a client program should never have been
allowed to serve up any of this information in the first place because this
ability violates the separation between client and server that is so crucial
to enforcing security policies.

I'm in favor of the draconian security measure of deny-all first, and then
allow. Rather than HttpOnly, browsers SHOULD adopt support for "client-side
scripting DOM restrictions on a domain per domain, site by site basis" as
Jeremiah Grossman suggests, with the default being no scripting unless a new
HTTP header is supplied in the response that requests permission to script a
particular DOM element AND the browser grants such permission explicitly to
the FQDN. This would create a new need for a manageability interface to
allow administrators to configure appropriate DOM/FQDN permissions for large
install bases, of course... But that's another thread of discussion.

Sincerely,

Jason Coombs
jasonc () science org

-----Original Message-----
From: Jeremiah Grossman [mailto:jeremiah () whitehatsec com]
Sent: Monday, November 11, 2002 8:20 AM
To: Michael Howard
Subject: Re: A technique to mitigate cookie-stealing XSS attacks


First, I'd like to thank the "Microsoft Internet Explorer Team" for
instituting some level of security to thwart the plague that is XSS.
Sure it might not be a solution for everyone in all instances, but what
is. Small steps to find better solutions, use what you have where you
can.


However, I'd like to point out that this security feature does not help
prevent disclosure of information to third-parties that JS/VB (and more)
have access to. (Highly browser dependent of course.)


Client-Side languages have been seen to have access to information
regarding Plugin's, User-Agent's, History, Cache, IP/Hostname, Screen
Size/Resolution, Machine Type, OS-Type, etc etc etc. This information
can quite easily be passed off-domain to third-parties.


This new HTTPOnly security feature would simply stop cookie hijacking
via document.cookie. Nothing else. Which is good, but important to know
the limitations and the risks.


> From a user standpoint, I'd like to see my browsers give me the ability
to assess my own client-side scripting DOM restrictions on a domain per
domain, site by site basis. The ability to give site the minimum DOM
access as possible for desired functionality. Mozilla already has some
form of this.

This might be a bit more than a normal user can handle, but this is why
we have defaults.


Jeremiah Grossman
WhiteHat Security, Inc.



On Tue, 2002-11-05 at 10:44, 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.
>
> 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