[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Full-disclosure] XSS + XSRF/CSRF...
- To: full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: [Full-disclosure] XSS + XSRF/CSRF...
- From: Baey <baey@xxxxx>
- Date: Thu, 15 Feb 2007 10:32:39 +0100
Recently I've been testing some methods or semi-methods of securing web
applications against
XSRF/CSRF attacks (crypto tokens, POST instead of GET, Referer header
validation, etc.).
Generally these techniques work (more or less) but there is a major flaw in
such thinking:
we start to trust the data that comes from the user's browser only on the basis
of that user
has hit the final (tokenized/critical) webpage thru surfing the webapp data
flow, not just
hitting it directly (like clicking on some evil link).
This is where XSS come into play. If the same webapp is vulnerable to
cross-site scripting
the attacker can '0wn' the user's browser using some fancy tools like XSS
Proxy, XSS Shell,
BackWeb (aka Backframe) or BEEF. Or just by using XMLHttpRequest or
FlashRequest (he's still
in the context of the valid user's session and the same domain) to totally
break the anti-XSRF
techniques.
So how to defend against such powerful XSS+XSRF attack ?
The one what comes into my mind is to use something that only valid user can
have (SecureID,
one time pass, etc.) or the user is supposed to authorize the critical action
(ie. updating
profile, funds transfer, etc.) by 'hard-to-read' validation images (aka
CAPTCHA).
Jeremiah Grossman has pointed out
(http://jeremiahgrossman.blogspot.com/2007/01/preventing-csrf-when-vulnerable-to-xss.html)
some interesting method of disabling some XSS functionality in the browser
itself by overwriting
constructors of objects or redefining functions. It surely can help but it also
dooms all
Ajax-aware apps.
Stefan Esser has also put some 2c into the topic
(http://blog.php-security.org/archives/48-CSRF-protections-are-not-doomed-by-XSS.html)
He suggests to embedd all HTML forms in IFRAMEs which source is pointed out
into another domain.
That definitively stops XSS, but it can horrify all web developers who in that
case have to
rebuild whole web application architecture.
So as I see it, there is no one remedy. Defense in depth once again.
Cheers.
BK
Security Tshooter
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/