Comments on: Preventing XSS Exploitation with CSRF Tokens?!?! http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/ Thoughts on Security in an Uncivilized World… Wed, 08 Sep 2010 02:39:08 -0700 hourly 1 http://wordpress.org/?v=3.0.1 By: Arian http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/comment-page-1/#comment-327 Arian Wed, 02 Apr 2008 19:00:33 +0000 http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/#comment-327 A few years ago at BH EU and Vegas, and a few of the OWASP conferences, I explored this in depth. We even created a WAF that could operate transparently on the .NET framework (called razorwire) to use tokens for this mitigation. They did a lot more than just make "request automation" difficult though. We eventually scrapped it as we found too many caveats and too little time to develop our WAF. Protecting "high profile" pages is worthless though, as we've seen from real-world attacks. I've seen hackers target obscure dynamic pages and rewrite them to redirect and then CSRF (or whatever) the "high-value" pages of a site. Nice writeup. -ae A few years ago at BH EU and Vegas, and a few of the OWASP conferences, I explored this in depth. We even created a WAF that could operate transparently on the .NET framework (called razorwire) to use tokens for this mitigation. They did a lot more than just make “request automation” difficult though.

We eventually scrapped it as we found too many caveats and too little time to develop our WAF.

Protecting “high profile” pages is worthless though, as we’ve seen from real-world attacks. I’ve seen hackers target obscure dynamic pages and rewrite them to redirect and then CSRF (or whatever) the “high-value” pages of a site.

Nice writeup.

-ae

]]> By: xssniper http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/comment-page-1/#comment-306 xssniper Thu, 20 Mar 2008 13:29:15 +0000 http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/#comment-306 Sweet dude... great techniques... you bring up a great point on how, given the right mentality, skill set, and circumstances, CSRF tokens that protect XSS can be defeated... it’s a great parallel to how stack protections were defeated (in certain circumstances) by some legit security researchers... As for the "High Priority" pages, this should be different for every organization and in line with their specific business objectives. To some, it may be going over their flagship domain, to others it may be reviewing pages that have a need for fast page loads, while others may want to start with the pages that have the most dynamic content... I'm guessing if I was in this situation, I would probably start with the pages available to unauthenticated users first. These pages usually have the greatest exposure (take a look at XSSed.com and compare the unauthenticated vs authenticated XSS numbers) and these pages probably offer less dynamic content than authenticated only pages. I'm also guessing that you would want to allow people to link to your publically available content, so CSRF tokens may become a burden to some users (as they constantly have to go through a portal page). Oh yeah... I would definitely leave the CSRF protection for logout functionality in place :) Sweet dude… great techniques… you bring up a great point on how, given the right mentality, skill set, and circumstances, CSRF tokens that protect XSS can be defeated… it’s a great parallel to how stack protections were defeated (in certain circumstances) by some legit security researchers…

As for the “High Priority” pages, this should be different for every organization and in line with their specific business objectives. To some, it may be going over their flagship domain, to others it may be reviewing pages that have a need for fast page loads, while others may want to start with the pages that have the most dynamic content…

I’m guessing if I was in this situation, I would probably start with the pages available to unauthenticated users first. These pages usually have the greatest exposure (take a look at XSSed.com and compare the unauthenticated vs authenticated XSS numbers) and these pages probably offer less dynamic content than authenticated only pages. I’m also guessing that you would want to allow people to link to your publically available content, so CSRF tokens may become a burden to some users (as they constantly have to go through a portal page).

Oh yeah… I would definitely leave the CSRF protection for logout functionality in place :)

]]> By: kuza55 http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/comment-page-1/#comment-305 kuza55 Thu, 20 Mar 2008 12:02:50 +0000 http://xs-sniper.com/blog/2008/03/19/preventing-xss-exploitation-with-csrf-tokens/#comment-305 CSRF Protected XSS vulnerabilities aren't quite as exploitable as they were before the last Flash update, but they're still pretty exploitable: http://kuza55.blogspot.com/2008/02/exploiting-csrf-protected-xss.html You can't use a standard payload with most of the attacks there (though when you can write cookies with arbitrary paths, then you can), but many times even logged-out xss is good enough to do something worthwhile, even if it is at the very, very least phishing. Anyway, would you be able to clarify what you would consider '“high priority” pages'? Would this be pages where csrf tokens don't help e.g. where you know you could have persistent xss? Or something else? CSRF Protected XSS vulnerabilities aren’t quite as exploitable as they were before the last Flash update, but they’re still pretty exploitable: http://kuza55.blogspot.com/2008/02/exploiting-csrf-protected-xss.html
You can’t use a standard payload with most of the attacks there (though when you can write cookies with arbitrary paths, then you can), but many times even logged-out xss is good enough to do something worthwhile, even if it is at the very, very least phishing.

Anyway, would you be able to clarify what you would consider ‘“high priority” pages’? Would this be pages where csrf tokens don’t help e.g. where you know you could have persistent xss? Or something else?

]]>