Message-ID: <b7a807650702150535l785b57d5r2ca5073f0c77d8bc@mail.gmail.com>
Date: Thu, 15 Feb 2007 13:35:17 +0000
From: pagvac <unknown.pentester@...il.com>
To: Baey <baey@...pl>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: XSS + XSRF/CSRF...

Hello there Baey, I agree with you: there is no magic solution against
XSS/CSRF attacks. It is indeed scary that the trusted/unique token can
be stolen with a simple AJAX request provided a XSS hole is found.

In summary, I think we have three realistic solutions for XSS/CSRF
attacks that should all be combined if possible:

1. Keep XSS vulns to minimum (i.e.: filter all user input that gets
returned to the browser)
2. Tokenize all requests (especially "interesting" requests)
3. Protect "interesting"/dangerous requests by asking the user for
something only he/she knows (i.e.: password)

Elaborating more on point #2 and #3, there are some examples of real
life webapps that are vulnerable to CSRF - the mistakes keep repeating
themselves, and we all have seen them:

Example 1

Changing the account's password requires the user to enter the
previous password which is good protection against CSRF (and account
hijacking in general). *However*, the webapp doesn't do so when
changing the user's email address in the profile. This is insane. If
the request that changes the user's email address is NOT tokenized,
accounts can most likely be compromised by forging the change-email
request and changing the email address to the attacker's. Finally, the
attacker submits his/her email address in the "forgot password"
facility, and voila, account hijacked! :-(

Example 2

The webapp correctly tokenizes the change-password and change-email
requests. However, administrative tasks such as add-new-user or
make-guestuser-administrator are NOT tokenized, neither is the user
asked for secret information (i.e.: password). Forging both requests
can of course lead the the attacker becoming an admin, and therefore
the application being compromised.

You might be interested in checking the following for a real example
of the second attack:

http://www.gnucitizen.org/blog/csrf-ing-blogger-classic

Anyways, these are just some of my thoughts on XSS/CSRF issues.

On 2/15/07, Baey <baey@...pl> wrote:
> 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/
>


-- 
pagvac
[http://ikwt.com/]

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists