|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: recent 'cross site scripting' CERT advisory
From: Taneli Huuskonen (huuskone
CC.HELSINKI.FI)Date: Tue Feb 08 2000 - 01:59:56 CST
- Next message: Torsten Landschoff: "Re: Debian (frozen): Perms on /usr/lib/libguile.so.6.0.0"
- Previous message: Adam Gray: "Novell GroupWise 5.5 Enhancement Pack Web Access Denial of Servic e"
- In reply to: Ari Gordon-Schlosberg: "Re: recent 'cross site scripting' CERT advisory"
- Next in thread: Mikael Olsson: "Re: recent 'cross site scripting' CERT advisory"
- Next in thread: Henri Torgemane: "Re: recent 'cross site scripting' CERT advisory"
- Next in thread: Marc Slemko: "Re: recent 'cross site scripting' CERT advisory"
- Reply: Taneli Huuskonen: "Re: recent 'cross site scripting' CERT advisory"
- Reply: Mikael Olsson: "Re: recent 'cross site scripting' CERT advisory"
- Reply: Peter W: "Re: recent 'cross site scripting' CERT advisory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
-----BEGIN PGP SIGNED MESSAGE-----
Ari Gordon-Schlosberg wrote:
> [Bill Thompson <bill
DIAL.PIPEX.COM>]
> > One form of protection from a truly *cross-site* attack that I didn't
> > see mentioned in the CERT advisory is the trusty "HTTP_REFERER"
[...]
>
> HTTP_REFERER is trivial to spoof, and it's likely that anyone perpetrating
> a sophisticated attack would laugh at having to spoof the Referer: header.
> It's a form of trusting the client, which is a big, huge, no-no. It's okay
Bill Thompson's comment makes sense in the following scenario. Suppose
a page on www.evil.com contained a link to www.trusted.com's login page,
with something funny embedded in a query string. Then an unsuspecting
victim might be tricked into following the link and getting back a page
with evil.com's javascript embedded in it. Now, if trusted.com's
webserver refused to serve anything else but the index page unless the
Referer: field contained a trusted.com URL, this attack would be foiled.
Now, is there a way to trick a browser into lying about the referrer?
Taneli Huuskonen
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQB1AwUBOJ/M9AUw3ir1nvhZAQEg2QL/VmBUGamGJACoVXCFG8n2G4OQCZk/wGrr
j+wFyzKtFA1YFE6KoIV3I+msJ/QVZJJ8hk6n6Oy45Z5/KkCSdNTQFz7OV+c2v0ua
Q/OXeo/4zUpZNl82Fgdx44rNxu21FkPY
=INX4
-----END PGP SIGNATURE-----
-- I don't | All messages will be PGP signed, | Fight for your right to speak for | encrypted mail preferred. Keys: | use sealed envelopes. the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
- Next message: Torsten Landschoff: "Re: Debian (frozen): Perms on /usr/lib/libguile.so.6.0.0"
- Previous message: Adam Gray: "Novell GroupWise 5.5 Enhancement Pack Web Access Denial of Servic e"
- In reply to: Ari Gordon-Schlosberg: "Re: recent 'cross site scripting' CERT advisory"
- Next in thread: Mikael Olsson: "Re: recent 'cross site scripting' CERT advisory"
- Next in thread: Henri Torgemane: "Re: recent 'cross site scripting' CERT advisory"
- Next in thread: Marc Slemko: "Re: recent 'cross site scripting' CERT advisory"
- Reply: Taneli Huuskonen: "Re: recent 'cross site scripting' CERT advisory"
- Reply: Mikael Olsson: "Re: recent 'cross site scripting' CERT advisory"
- Reply: Peter W: "Re: recent 'cross site scripting' CERT advisory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]