Comments on: Preventing CSRF attacks

By: artoodetoo

artoodetoo — Sat, 12 Jan 2008 14:16:18 +0000

Neal & Rickard, good job!

By: Neal

Neal — Sat, 05 Jan 2008 23:09:28 +0000

I just committed the new system to the repository if anyone is interested in taking a look and commenting. :)

By: dmspilot00

dmspilot00 — Sat, 29 Dec 2007 06:48:53 +0000

Rickard’s idea sounds great … not that I am surprised he came up with a good idea, he came up with PunBB after all ;)

Anyway, I appreciate the discussion here and seeing what’s on the minds of the developers. Good luck with 1.3 :)

By: Neal

Neal — Fri, 28 Dec 2007 23:58:58 +0000

I understood what you meant ;)
However, as I said, it would still open you up to a token being useful for any form: just set all the variables as they were. The problem is that we don’t want to restrict a page to only submitting to itself or to a fixed set of pages. That would solve the problem rather easily using your solution. However, it would be somewhat difficult for extension developers and we don’t want use of the token to become unnecessarily complicated. The basic idea is good and sound though. ;)

Rickard brought up a way to deal with this that is somewhat similar to yours and artoodetoo’s. The idea is that the hash should be composed of a random string and the page to which the form is going to be posted to (not the page posting the form). That way, given the base hash, any PunBB page can generate a hash to submit to any other page. However, the base hash won’t ever be exposed to the user, so you couldn’t just use the hash for submitting to any form.

By: dmspilot00

dmspilot00 — Fri, 28 Dec 2007 22:37:29 +0000

Thanks for taking care of that and for your response :)

I don’t mean comparing the hashed/hidden script_name to the form-processor’s script_name. Hash the user’s secret token from the database with the time and the script_name, then also include the time and script_name plaintext in the form. The form processor then checks that the hash is correct using the secret token from the database and the values from the form, and also uses the time from the hidden form field to make sure the form isn’t too old, and uses the script_name from the hidden form field to make sure it is something that is expected–like a referrer check without having to use HTTP_REFERER. This way, you can’t use the same token from (for example) the “post a topic” form for the “change your password” form. With the time, you can make individual forms expire after a set time. With this method the “public token” is always different but posting from multiple browser windows is not a problem.

Anyway, I am just exploring possibilities and giving you ideas; not trying to persuade you one way or the other. I liked artoodetoo’s method but this method has all the advantages and none of the disadvantages as his.

By: Neal

Neal — Fri, 28 Dec 2007 17:11:55 +0000

I just deleted the two other posts ;)
That’s good, except I think that would still have the issue of a CSRF token from one page being good for posting to any other page. We would, after all, want to allow one page to have a form on it that posts to another.

By: dmspilot00

dmspilot00 — Fri, 28 Dec 2007 06:48:18 +0000

(One more try, I hope the moderator deletes the messed up posts)

Humor me, what about this instead:

form method=”post” action=”somescript.php”
input type=”hidden” name=”csrf_token” value=”php echo sha1($some_secret_salt . $_SERVER['SCRIPT_NAME'] . time)”
input type=”hidden” name=”script_name” value=”php echo $_SERVER['SCRIPT_NAME']”
input type=”hidden” name=”time” value=”php echo time”
/form

The script_name and time can’t be tampered with because the hacker does not know the secret salt. The salt could be generated a number of ways; it can be per user or system wide, it can be permanent or regenerated for each logout/login. Plus, this way the token is always different, and there is no multiple browser problem.

By: Neal

Neal — Sat, 10 Nov 2007 14:24:37 +0000

I’m actually not going to do that, because as I said the burden is then on the developer to write a check in the proper place. So, any form where people forget to write it won’t be protected at all.
Instead, I’m thinking about re-generating the token after every successful request.

Edit: And of course, I forgot that I had this debate with Asbjørn a couple comments ago. Lucky for me, someone pointed it out. :P
So yeah, I’m not exactly sure what can be done to improve it without sacrificing usability or putting the burden of security on people writing the forms. We’re thinking about it though ;)

By: Neal

Neal — Fri, 09 Nov 2007 13:02:11 +0000

artoodetoo: I’ll see what I can do ;)

By: artoodetoo

artoodetoo — Thu, 08 Nov 2007 09:17:41 +0000

“…the current solution protects all POSTed data” Don’t put all your eggs in one basket. :)

If ANY (public) form has XSS-vulnerability, then easy to catch admin’s token and post data to ANY OTHER (admin’s-only) form.

My aproach, imho, is workaround both the token and the http referer limits.