“CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim’s behalf”
“For most sites, browser requests automatically include any credentials associated with the site, such as the user’s session cookie, IP address, Windows domain credentials, and so forth. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish between the forged request sent by the victim and a legitimate request sent by the victim”
“CSRF attacks target state-changing requests”
“This type of attack occurs when a malicious website contains a link, a form button or some JavaScript that is intended to perform some action on your website, using the credentials of a logged-in user who visits the malicious site in their browser”
Login CSRF: “The attacker forces a non-authenticated user to log in to an account the attacker controls. If the victim does not realize this, they may add personal data - such as credit card information - to the account. The attacker can then log back into the account to view this data, along with the victim’s activity history on the web application”
Example of Django: How to Protect against CSRF
1: A CSRF cookie that is a raondom secret value, which other sites will have not access to
“CsrfViewMiddleware sends this cookie with the response whenever django.middleware.csrf.get_token() is called. It can also send it in other cases”
“For security reasons, the value of the secret is changed each time a user logs in”
2. A hidden form field with the name csrfmiddlewaretoken, present in all outgoing POST forms
“[T]he value of this field is not simply the secret. It is scrambled differently with each response using a mask. The mask is generated randomly on every call to get_token(), so the form field value is different each time”
“This part is done by the template tag”
3. For all incoming requests that are not using HTTP GET, HEAD, OPTIONS or TRACE, a CSRF cookie must be present, and the csrfmiddlewaretoken field must be present and correct. If it isn’t, the user will get a 403 error.
“When validating the csrfmiddlewaretoken field value, only the secret, not the full token, is compared with the secret in the cookie value. This allows the use of ever-changing tokens. While each request may use its own token, the secret remains common to all.”
“This check is done by CsrfViewMiddleware
4. CsrfViewMiddleware verifies the Origin header, if provided by the browser, against the current host and the CSRF_TRUSTED_ORIGINS setting
“This provides protection against cross-subdomain attacks.”
5. If the Origin header isn’t provided, CsrfViewMiddleware performs strict referer checking
“This means that even if a subdomain can set or cookies on your domain, it can’t force a user to post to your application since that request won’t come from your own exact domain”
“This also addresses a main-in-the-middle attacks that’s possible under HTTPS when using a session independent secret, due to the fact that HTTP Set-Cookie headers are (unfortunately) accepted by clients even when they are talking to a site under HTTPS (Referer checking is not done by HTTP requests because the presence of the Referer header isn’t reliable enough under HTTP)”