Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [Full-disclosure] XSS + XSRF/CSRF... |
|---|---|
| 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/
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [Full-disclosure] Diagnostics Mode + Phreaking, Paul Melson |
|---|---|
| Next by Date: | [Full-disclosure] Nifty New Open Source Management Tools, Reece Mills |
| Previous by Thread: | [Full-disclosure] Firefox: serious cookie stealing / same-domain bypass vulnerability, Michal Zalewski |
| Next by Thread: | Re: [Full-disclosure] XSS + XSRF/CSRF..., pagvac |
| Indexes: | [Date] [Thread] [Top] [All Lists] |