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:
Tuesday, April 24, 2012
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>
(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
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:
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!