|
BugTraq
A technique to mitigate cookie-stealing XSS attacks Nov 05 2002 06:44PM Michael Howard (mikehow microsoft com) (3 replies) Re: A technique to mitigate cookie-stealing XSS attacks Nov 07 2002 08:26PM Justin King (justin othius com) (1 replies) Re: A technique to mitigate cookie-stealing XSS attacks Nov 10 2002 03:21AM Ulf Harnhammar (ulfh update uu se) (2 replies) RE: A technique to mitigate cookie-stealing XSS attacks Nov 12 2002 10:43AM jasonk (jasonk swin edu au) Re: A technique to mitigate cookie-stealing XSS attacks Nov 11 2002 08:29PM Seth Arnold (sarnold wirex com) Re: A technique to mitigate cookie-stealing XSS attacks Nov 05 2002 09:38PM Florian Weimer (Weimer CERT Uni-Stuttgart DE) (2 replies) Re: A technique to mitigate cookie-stealing XSS attacks Nov 08 2002 04:23AM daw mozart cs berkeley edu (David Wagner) Re: A technique to mitigate cookie-stealing XSS attacks Nov 06 2002 05:16AM Valdis Kletnieks vt edu (1 replies) Re: A technique to mitigate cookie-stealing XSS attacks Nov 08 2002 10:12AM Florian Weimer (Weimer CERT Uni-Stuttgart DE) |
|
Privacy Statement |
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
>
[ reply ]