Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted
  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.

share|improve this answer
1  
Well, I meant, the CSRF protections would be compromised even after the XSS had been fixed if it was simply per-user. ie. once compromised always compromised. phpBB's approach doesn't have that weakness. What other scenarios do you think could result in the salt being disclosed? –  compcert Feb 2 '12 at 20:28
    
right, sorry for the misunderstanding. Just thought it's an important point to make in case this wasn't clear for some reason. XSS is definitely one scenario, but others range from someone with database access, stupid programming mistake outputing this or using it somewhere else, to social engineering etc. The main point is trying to avoid static elements that might get compromised, and rather use dynamic elements that don't carry any of that risk, and that are just as easy to implement. –  Yoav Aner Feb 2 '12 at 21:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.