Defenses against CSRF attack

Known defensive techniques against CSRF

CSRF protection in a POST Request

1. Cross Site Request Forgery (CSRF) Token

CSRF token is used for defense, protected sites require the CSRF token when requests are submitted that could potentially alter data.

• A web application would generate a token with two parts: one that user would receive and one that the application would retain. When user attempts to make transfer requests, he would have to submit his token, which the web application would then validate with its side of the token.
• The design of these tokens makes them guessable and only accessible to the specific user they’re assigned to.

How does the user get the token?

• Browser could get the CSRF token from a cookie, an embedded script on the website, or as part of the content delivered from the site

Where to find them in webpage or HTTP requests?

• They aren’t always obviously named, but some potential examples of names include X-CSRF-TOKEN, lia-token, rt, or form-id. Tokens can be included in HTTP request headers, in an HTTP POST body, or as a hidden field.

2. Cross Origin Resource Sharing (CORS)

• Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

Example:

In a cross-origin request from a front-end JavaScript code served from https://domain-a.com uses XMLHttpRequest to make a request for https://domain-b.com/data.json

3. Origin or Referrer based

• The web application could check the value of the Origin or Referrer header submitted with an HTTP request and ensure it contains the expected value.

Example:

• In some cases, Twitter will check the Origin header and, if it’s not included, check the Referrer header.
• This works because browsers control these headers and attackers can’t set or change them remotely (this excludes exploiting browser vulnerability)

4. Cookie samesite attribute

• Browsers are now beginning to implement support for a new cookie attribute called samesite.
• This attribute can be set as strict or lax. When set as strict, the browser will not send the cookie with any HTTP request that doesn’t originate from the site. This includes even simple HTTP GET requests.

Example:

• If you were logged into Amazon and it used strict samesite cookies, the browser would not submit your cookies if you were following a link from another site. Also, Amazon would not recognize you as logged in until you visited another Amazon web page and the cookies were then submitted. In contrast, setting the samesite attribute as lax instructs browsers to send cookies with initial GET requests.

CSRF protection in a GET Request

• Data handling or changes through GET request should be completely removed.

Limitations of the techniques

1. CSRF token — poor implementation

• Not mandating the token
• Token manipulation

2. CORS — Avoiding the initial OPTIONS call

• Changing from POST request to GET request
• Using the content type application/x-www-form-urlencoded
• Dependent on browser security implementation

3. Origin or Referrer based

• Dependent on browser security implementation

4. Cookie samesite attribute

• Dependent on browser security implementation
• Fairly new mitigation method, not all browsers supports