Skip to content

Defending against CSRF

Jump to bottom
Ivan Ristic edited this page Jun 7, 2013 · 1 revision

Defending against CSRF

Attack

A malicious web site can have a request sent to the victim web site, exploiting the privileges the user might have on it.

Defense

Web applications should be build with CSRF defense in mind, which comes to using per-form or per-session secret tokens, something the application can validate and the malicious web site cannot discover.

What a WAF could do:

  1. Parse HTML response to detect form(s), then inject protection token(s) (modify response)
  2. On every POST request, verify that the protection token is provided

Issues:

  • Unable to protect GET requests
  • Some applications will construct forms dynamically, in which case we would not be able to detect them
  • It is not possible to add protection tokens to background AJAX requests (however, the really keen could resort to modifying the underlying JavaScript and/or libraries, but that is not only difficult, but can work only if the JavaScript code is served from the same web server)
  • Form modification should ideally take the destination (action) into account, and avoid including the secret into a form that is delivered elsewhere. That should defend against attackers that are able to inject forms, but not JavaScript. Alternatively, it might be possible to build a token to include the intended domain name.
  • Secret must be generated on per-site bases. If a WAF is designed to protect several sites, we want to avoid the situation of the site tokens also working on the other sites protected by the same WAF.

Token generation strategies:

  • HMAC -- preferred approach because does not require keeping state; need a way to reliably synchronise the secret among proxies; may consider secret rotation; tokens should only be valid for a limited amount of time
  • Random token generation with persistence (keeping state introduces a lot of overhead, especially for a system that needs to work across a cluster or even geographically separated proxies)

Engine requirements

  • Response parsing (to identify forms, chunks of JavaScript code)
  • Response modification

Notes

  • URL rewriting/encryption also defends against CSRF, but it's also far more invasive and may prevent linking
Clone this wiki locally