CSRF prevention in PHP

Question

Two questions.

1. Where does one download the PHP version of OWASP's CSRF Guard? The following URL says to check Git:

   https://www.owasp.org/index.php/PHP_CSRF_Guard

   All I see on Git however is *.java files and *.js files. If there are PHP files where in the directory structure are they?

2. phpBB prevents CSRF by adding two hidden parameters to all forms. The time and a SHA1 hash of the time, a per-user "form salt", the session identifier and the form name. Source:

   https://github.com/phpbb/phpbb3/blob/c3aa466523e9b074bc4479eccc7b0514972f4b28/phpBB/includes/functions.php#L2544

   My question is... why is anything other than the form salt necessary? To prevent CSRF all you need is a random string that an attacker can't predict so that they can't send an HTTP request blind and the form salt would do the trick it seems to me. Hashing that together with everything else just seems unnecessary.

   Maybe their motivation is that the form salt could be compromised if someone copy / pasted the HTML contents of the page? Maybe it's intended to future proof it? An XSS vulnerability would permanently compromise the CSRF protections if the form salt was used directly whereas with a hash of time and the form salt protects against that scenario.

   Also, if the salt was just two characters or so I could understand doing the sha1() hash but a two character long salt is just insecure because all you need to do at that point is send 256**2 blind HTTP requests, each with a different token. But it's not two characters long either.

Answer 1

1. Peculiar, but you're not the first person to ask about it, and there's even a suggested implementation for CSRF protection there + the code hosted on github. I can't really vouch for this mechanism though, haven't really inspected it too closely.

2. Interesting question. It does seem to me that phpbb went a little over-the-top with the implementation, but there's some logic behind it. The salt alone wouldn't be enough, because in the phpbb case, the user_form_salt value is a static per-user value, which doesn't change for that particular user. This means that once this value is known/disclosed (and there are probably many ways in which this value can be leaked or obtained), then all user forms can be compromised. Forever (or more precisely for the duration of this salt, but it doesn't change typically). The method implemented there has the advantage that the value constantly changes, yet it is 'reproducible' by the server for checking without having to store it anywhere. It uses existing stored data + some random elements to generate the CSRF token. I am not too sure but am guessing that using, e.g. hash/HMAC of the time with the some internal (not-exposed) random session variable as key, would achieve the same result.

Lastly, just a short note about your comment regarding XSS and CSRF. You said that

An XSS vulnerability would permanently compromise the CSRF protections if the form salt was used directly whereas with a hash of time and the form salt protects against that scenario.

Basically, an XSS vulnerability has the potential to compromise ANY CSRF protection. If the attacker is able to execute code with the user session, they have access to all form data, however well protected it may be.