CSRFProtectionNotEnabled.qhelp

<!DOCTYPE qhelp PUBLIC
 "-//Semmle//qhelp//EN"
 "qhelp.dtd">
<qhelp>

  <overview>
    <p>
      Cross-site request forgery (CSRF) is a type of vulnerability in which an
      attacker is able to force a user to carry out an action that the user did
      not intend.
    </p>

    <p>
      The attacker tricks an authenticated user into submitting a request to the
      web application. Typically this request will result in a state change on
      the server, such as changing the user's password. The request can be
      initiated when the user visits a site controlled by the attacker. If the
      web application relies only on cookies for authentication, or on other
      credentials that are automatically included in the request, then this
      request will appear as legitimate to the server.
    </p>

    <p>
      A common countermeasure for CSRF is to generate a unique token to be
      included in the HTML sent from the server to a user. This token can be
      used as a hidden field to be sent back with requests to the server, where
      the server can then check that the token is valid and associated with the
      relevant user session.
    </p>
  </overview>

  <recommendation>
    <p>
      In the Rails web framework, CSRF protection is enabled by the adding a call to
      the <code>protect_from_forgery</code> method inside an
      <code>ActionController</code> class. Typically this is done in the
      <code>ApplicationController</code> class, or an equivalent class from which
      other controller classes are subclassed.

      The default behaviour of this method is to null the session when an invalid
      CSRF token is provided. This may not be sufficient to avoid a CSRF
      vulnerability - for example if parts of the session are memoized. Calling
      <code>protect_from_forgery with: :exception</code> can help to avoid this
      by raising an exception on an invalid CSRF token instead.

      Note that Rails versions 5 and later
      automatically run <code>protect_from_forgery with: :exception</code>
      by default, but manually calling <code>protect_from_forgery</code> with
      no <code>with</code> argument will downgrade protection to provide an empty
      session rather than raise an exception.
    </p>
  </recommendation>

  <example>
    <p>
      The following example shows a case where CSRF protection is enabled with
      a secure request handling strategy of <code>:exception</code>.
    </p>

    <sample src="examples/ProtectFromForgeryGood.rb"/>

  </example>

  <references>
    <li>Wikipedia: <a href="https://en.wikipedia.org/wiki/Cross-site_request_forgery">Cross-site request forgery</a></li>
    <li>OWASP: <a href="https://owasp.org/www-community/attacks/csrf">Cross-site request forgery</a></li>
    <li>Securing Rails Applications: <a href="https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf">Cross-Site Request Forgery (CSRF)</a></li>
    <li>Veracode: <a href="https://www.veracode.com/blog/managing-appsec/when-rails-protectfromforgery-fails">When Rails' protect_from_forgery Fails</a>.</li>
  </references>

</qhelp>