CSRF Protection

Overview

This page describes protections implemented by the GridShib-CA against Cross Site Request Forgery (CSRF) attacks.

The Threat

While there are not obvious attacks of consequence via CSRF against the GridShib-CA, it is possible that a malicious website could trick a user with an existing authentication session with an identity provider trusted by a GridShib-CA deployment into downloading a credential. In theory this could, in combination with some other attack giving an attacker some sort of access to the users local system or the ability to hijack their secure sessions, the ability to steal or copy the credential.

Protection process

Protection is implemented by the GridShibCA::CSRF.pm module. The protection provided is that described in the OWASP prevention cheat sheet.The goal of the protection is to ensure that any submission to a CSRF-protected command came from a expected work flow (i.e. a legitimate form and not a malicious website). In summary that protection is as follows.

  • A random nonce is generated at user sign-on.
    • The nonce is 40 random alphanumeric characters (a-z, A-Z, 0-9 or almost 6 bits of entropy per character).
    • Randomness is generated with the standard PERL rand() function.
    • Seeding via srand() is not done by the GridShib-CA, meaning the default seeding is done by rand().
  • The nonce is placed into a cookie with the name "CSRFProtection".
    • The cookie should only be sent by the browser in requests back to GridShib-CA host, meaning it should be private to the user's browser and the GridShib-CA.
  • When an form is submitted to a CSRF-protected command, that GridShib-CA requires:
    • The the submission be done via the POST method. This prevents GET methods requests which could be embedded into various HTML tags which the user does not have to explicitly click on (e.g. img).
    • The submission be accompanied by a "CSRFProtection" cookie.
    • The submission contains a parameter by the name "CSRFProtection" with a value that matches the cookie. This aims to assure the creator of the form had access to the CSRFProtection cookie and hence was on the GridShib-CA host.

For additional details about the implementation and its history, see Bug 6610

Note that instead of embedding the token into a cookie, it could instead have been stored in the GridShib-CA session. However this would make it more difficult to add third-party applications to the GridShib-CA deployment since they would need to understand GridShib-CA sessions instead of a standard cookie.

What parts of the GridShib-CA are protected?

Currently the following commands of GridshibCA.cgi are protected:
  • GridShibCA::LaunchJNLP.pm (the Java Web Start application launcher)
Note that GridShibCA::IssueCred.pm also needs CSRF protection, but accomplishes that using Credential Issuance Sessions instead, which are only created by request of the user.

What forms should do?

Applications generating forms that submit to CSRF-protected commands of the Gridshib-CA should read the value of the CSRFProtection cookie and include that value in a hidden field with the name of CSRFProtection. E.g.:

<form action="/launchGSCA.jnlp" method="POST">
<input type="hidden" name="CSRFProtection" value="fKD7xWlv1Z44ld2LSKoBDhfYZTIGLpmNtdKDyc9M" />
<input type="submit" value="JavaWebStart"/>
</form>
Templates generated by the GridShib-CA may use the $CSRF->getFormElement() code to generate the input field. E.g.:
<form action="/launchGSCA.jnlp" method="POST">
{ $CSRF->getFormElement(); }
<input type="submit" value="JavaWebStart"/>
</form>

Comments