Anti-CSRF and static pages
By Romain Wednesday, August 8 2007 - 18:37 UTC - Vulnerabilities - Permalink
By Romain Wednesday, August 8 2007 - 18:37 UTC - Vulnerabilities - Permalink
Protecting against Cross-Site Request Forgery
(CSRF) is something that we tend to see everywhere now.
What we usually see is a solution with a token in the form pdp described this a couple of months ago here: Preventing CSRF. Now, the problem is when you don't have dynamic pages, when you are stuck with static HTML pages but you can use JavaScript! Of course, the first reflex when you want to prevent CSRF is to use only POST variable when you send data, this make the attack a little harder.
I started thinking of this because I had this problem: I had static pages that are using Ajax to send data using POST. I talked with Stefano Di Paola about this (because my problem was not only CSRF, but also parameter tampering...). We both conclude on the following Ajax based solution:
So you need 3 files:
You can find the demo here: anti-csrf/index.html
Comments
I don't think it is enough secured. If the attacker has access to a machine of the same NAT-ed network as the target (which does occur), it is possible for him to find the token.
You're absolutely right if he has the same User_Agent... This solution is definitely not perfect and Stefano has a better one by adding time the generated token.
In this case you could simply use the session id as in the article of gnucitizen.org you point to, since a session id is.... a random token with a time limit.
And you could directly read it from the cookie (CSRF isn't relevant on a site without cookies) instead of using a double-XHR.
But the constrain is about static page :)
What do you mean by static pages? Pages not generated by PHP? I would I violate this constraint?
Originally, people are coming to the target web page directly (plain HTML files pages).
The idea of this was simply to prevent somebody to force another guy to make a validation of the form on that HTML file.
Sure, this is CSRF. Your case with static pages is not very different than the usual case, except that the submission must be made with XHRs.
I was suggesting to reuse a more usual and stronger protection that still applies to your case.