[27769] in bugtraq
Re: A technique to mitigate cookie-stealing XSS attacks
daemon@ATHENA.MIT.EDU (Peter Watkins)
Fri Nov 8 15:18:51 2002
Date: Fri, 8 Nov 2002 14:49:39 -0500
From: Peter Watkins <peterw@usa.net>
To: Nick Simicich <njs@scifi.squawk.com>
Message-ID: <20021108144939.A5755@usa.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT"
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20021107232340.04ea2328@199.74.151.1>; from njs@scifi.squawk.com on Thu, Nov 07, 2002 at 11:50:03PM -0500
--tKW2IUtsqtDRztdT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 07, 2002 at 11:50:03PM -0500, Nick Simicich wrote:
> At 10:44 AM 2002-11-05 -0800, Michael Howard wrote:
>=20
> >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.
> Has anyone looked at the impact of simply changing the default: Do not=
=20
> allow cookies to be accessed from javascript unless they were set from=20
> javascript in the first place, or have a trailing jscript on any cookie=
=20
> that *should* be returned by document.cookie.
> The only thing that breaks is the subset who set a cookie with the=20
> set-cookie header who then want to access the cookie with javascript, and=
=20
> as others note, that just is not done much.
It would break a fair bit of code at my employer's site, things like=20
logout buttons that are displayed if the user appears to be logged in=20
(better to let the client burn those cycles than the server), etc. This=20
will allow us to flag the session-authenticating cookies as HTTP-only=20
while leaving the session-identifying cookies available to scripts.
Most importantly, your suggestion would break applications that are safely=
=20
written.=20
Counter-argument: the IE team's HttpOnly approach can be adopted now,=20
without breaking any existing apps. Maybe it's not as good as the
denied-unless-allowed model you suggest, but it's better than the current=
=20
anything-goes status quo.
> >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!
And a very welcome one; many thanks to Microsoft for implementing, and the=
=20
Bugtraq folks for approving the post describing the feature.
This mechanism has been suggested as a feature enhancement to the Open=20
Source Mozilla browser; interested parties can read details (and vote if=20
you like the idea) at
http://bugzilla.mozilla.org/show_bug.cgi?id=3D178993
-Peter
--=20
Peter Watkins - peterw@tux.org - peterw@usa.net - http://www.tux.org/~peter=
w/=20
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123=
692
--tKW2IUtsqtDRztdT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9zBVTZxiiRvTzl6gRAoaKAJ9mSTeq5oteR5C/HlOfmr9twOUVGQCgpc8n
vA/ZCHnTIGhhqCd0ou7FHBc=
=FQmW
-----END PGP SIGNATURE-----
--tKW2IUtsqtDRztdT--
