Tuesday, April 24, 2012

CSRF afterparty & MUST READ rules

Good day everyone! HN submission

A month ago I was possessed with CSRF and related stuff. I received quite useful and interesting feedback on initial "Theory" post. In a nutshell it was a *traditional* negation "not our problem, it always has been working this way, apps should protect themselves". Now, let me to give up my proposal(introducing "top bars" for allowing/disallowing POST request in every browser by default) because it is too radical and backwards-incompatible. You win. I'm always open to discuss solutions/attitudes and this time I really changed my mind and want to be "agile" with real world facts and your opinions!

But you should do the same. Also I wrote a post demonstrating a few CSRF vulns on popular/alexa top websites. It was marked [dead] on HN though - I don't know why :D You(people, hackers, w3c, whatever) shouldn't be stubborn, be agile to solve fresh(and old ones surely too) problems, please, just try to consider new ways to fix/deal the CSRF problem because it is extremely common but extremely dangerous either, yet! Here are what I got:

SaferWeb: Whitelist Your Routes, "match" is Evil


Related:
CSRF afterparty & MUST READ rules
Playing With Referer & Origin + disqus.com and yfrog.com Vulnerability)


Sometimes developers use GET for state-changing requests by purpose. This determines low-skilled developer. In this post I want to describe another vector of attack - GET Accessible Actions(GAA) - when framework abstractions + bad practices make "Good Guys' apps" insecure.

There is a thing I found exploring DSL's and engines' internals - many frameworks do "dirty work" for developer - they merge GET(stored in URL string)+POST(stored in Body) params into one unified hash. IMO it's cool and awesome to use - "params" for Rails and $_REQUEST for PHP.


But! As I found out it often confuses mechanism of handling GET requests from others(POST-like - PUT/DELETE/etc).
Same "state-changing" code is accessible via GET either, it is GAA, opening the easiest to use hole: <img src=URL/create_message?message[body]=SPAM>

Playing With Referer & Origin + disqus.com and yfrog.com Vulnerability


(related: CSRF afterparty & MUST READ rules )


If you read owasp you should know that Referer has never been a good protection. If user submits form from https:// URL than referer header is omitted due to security reasons - it's known fact. But having https page is a big deal for hacker - very uncomfortable for massive attacks(rapidly banned/reported, expensive certificates).

I found a way(in fact two ways) to omit this header from any page - it is the trick with about:blank.

Monday, April 2, 2012

A few CSRF-like vulnerable examples.


Remark: Post is published on April 2(but was expected yesterday) coz Berlin haz no free wifi cause I'm not joking and I figured out that Sunday is the worst day for urgent updates. Well, who cares the date, enjoy:

TL;DR:

I'm trying hard to prove my point that statement "CSRF is only the developers' problem" is not true. I provided some examples and I want you to check them out. I really appreciate any viewpoint at this problem. Thank you for your attention in advance!