Here’s an overview of the key concepts, impact and effective mitigation strategies of cross-site request forgery, also known as CSRF.
CSRF (cross-site request forgery) was included in the OWASP (Open Worldwide Application Security Project) Top 10 list in 2013 but was removed from it in 2017 as the statistical data did not justify its place there. However, CSRF still impacts web applications a great deal.
The effect of a CSRF exploit varies from case to case. There are multiple factors that decide the severity of the exploit, which could be:
- Unauthorised actions [money transfer, account setting changes]
- Privilege escalation [admin access]
- Application integrity and confidentiality loss [data theft]
- Possible loss of reputation [negative image within users or communities]
SOP (Same-Origin Policy)
To understand why CSRF is successful, one needs to understand the Same-Origin Policy (SOP) used by browsers. The latter follow SOP by default and only allow requests from the same origin. However, there is a business need for the user to make a cross-origin or cross-domain request to the application server. There are a lot of security concerns around allowing cross-domain requests. Initially, browser implementations used CORS (cross-origin resource sharing) to accommodate cross-domain requests while taking security concerns into consideration. Recent implementations have come up with a cookie attribute called ‘SameSite’. Let us discuss CORS and SameSite in brief.
To address the need of cross-origin requests, CORS specifications are used, and browsers are made compliant with CORS specs. Application servers explicitly whitelist the trusted domains from where they can accept cross-origin requests and browsers are directed accordingly, using CORS-specific response headers.
Browsers are also implemented to consider the cookie attribute called ‘SameSite’. These attribute values are set by the application server and direct the browser to decide if the domain cookies are to be included in the request or not. The browser decides for which cases the session cookies are to be sent for different types of requests to the server. All modern browsers support this attribute, which is an effective means of protection from CSRF attacks.
Role of the browser in a CSRF attack
The typical CSRF attack scenario is shown in Figure 1.
It is clear from this figure that the attacker takes advantage of the browser sending domain cookies for the server to validate the session authenticity. Therefore, the victim needs to be logged in to the same browser for a successful CSRF exploit.
This means that the success of the CSRF exploit depends on the browser sending the session cookies along with the http request. Thus, the obvious protection mechanism is to direct the browser in which conditions the session cookies are to be sent with the request.
SameSite cookie attributes
The browsers follow SOP (Same-Origin Policy) when domain cookies are sent for the specific request. The introduction of SameSite is an extension of this ability, where the server directs the browser in which category of requests the latter should include the session cookies. You can refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite for the browsers that support the SameSite attribute.
There are three possible values of the SameSite attribute:
- None
- Lax
- Strict
This attribute is used as one of the protections against CSRF attacks.
CORS (cross-origin resource sharing)
Applications are expected to accept cross-site requests, i.e., requests coming from other domains. With strict SOP, browsers will not make any cross-domain requests, which may hamper the functioning of these applications. CORS is the answer to this challenge. Here, the application server indicates which domains are allowed to make requests to the application, which methods can be used in the endpoint while making such requests, and which requests the browser should send with domain cookies.
Since the server relies on browser support for CORS, it becomes necessary to understand how browsers decide which cross-domain requests are to be sent to the server and, if so, whether the domain cookies are to be sent along with the request. Let us understand browser handling for this.
Modern browser implementations treat requests in two categories: simple and non-simple (pre-flight).
To identify the request category, the browser uses the following parameters:
- Request verb
- Content/media type of the request
- Type of the request as cross-site/same-origin/same-site
Criteria for simple requests
For the following parameters, browsers treat the request to be a simple request and send it as such to the server without any pre-flight.
Simple request safelist headers and the values
Methods: POST, GET, HEAD
Safe listed request headers: Accept, Accept-Language, Content-Language, Content-Type
Media types: text/plain, multipart/form-data, application/x-www-form-urlencoded
GET and HEAD methods do not need media type. Browsers treat such requests as simple requests. For POST requests, the media types mentioned above are that of the simple request. For any other media types other than the ones mentioned above for POST request, the request is non-simple and the browser makes a pre-flight before sending the actual request.
What does pre-flight mean?
Once the browser analyses and identifies specific requests to be non-simple — for example, XHR POST request with content-type as ‘application/json’ — it does not send this POST request directly to the server. It first checks if the server is ready to accept such a request or not, and if yes, in what conditions it will do so. This check is done with the help of the OPTIONS method, called a ‘pre-flight’ request, where the browser adds headers in the request to get clarity on various parameters allowed by the server.
The CORS request headers are as follows:
- Access-Control-Request-Headers
- Access-Control-Request-Method
- Origin [CORS flow depends on the value of this requst header]
The CORS response headers are as follows:
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
The browser checks for the CORS response headers and decides whether to make the actual request or not.
Figure 2 is a quick reference for the conditions in which CSRF is possible.
CSRF guarding mechanisms
The effects of CSRF cannot be underestimated and defence against it should be well thought of. So let’s discuss the common defence mechanisms to protect against CSRF:
- Use of CSRF tokens
- Use of SameSite attribute
- CORS
- Use of fetch meta headers
Use of CSRF tokens
This is a very commonly used method for CSRF protection. The application owner must first identify the sensitive requests which need CSRF protection. Normally, all the state changing methods are sensitive requests. In this case, the application server generates the dynamic token (random value which is not easily guessable) and the browser includes this token value in the specific request header (custom). This request header is a custom header. The value of such a header is set with the value of the token generated and the request is sent. The application server, upon receiving the request, checks and validates the header and its value. If the validation is successful, it processes the request and responds.
You can refer to the sequence diagram in Figure 3.
Use of SameSite attribute
We have already discussed how CSRF protection can be enforced using the SameSite attribute. Developers can refer to meta headers (fetch specifications) set by the browser implementations for a quick reference on which requests the browser is treating as same-site and cross-site.
-
Samesite=strict
In this case, the browser will not share the cookie information for the requests that are not from the same origin. This means any request other than the server from which the cookie is received will be treated as NOT a candidate for sending the domain cookie. All such requests are expected to have 401 kinds of response. This way, strict cookie policies can be enforced by the application server depending on the need of making and accepting the cross-site requests.
-
Samesite=lax
This is a more relaxing setting and is a default one if not explicitly set by the server. With this setting, any cross-site requests will not have cookies sent but same-site requests will have a cookie added by the browser. Classic cases can be requested by the sub-domain of the TLD (top-level domain).
-
Samesite=none
This is the most relaxing configuration on the cookie. The cookie will be shared for any cross-site request by the browser. The only mandate is to have a cookie set with a ‘secure’ flag. The product owner can choose and select the combination of SameSite attributes and the CORS policy to attain freedom on cross-origin requests.
Note
The developer or the owner of the code should make effective use of CORS and SameSite for maximum security. For example, setting SameSite to strict while devising CORS to allow all arbitrary origins to make a request with the application server will be conflicting. So, the mitigation mechanisms used must be carefully devised.
CORS
Figure 5 describes the concepts related to CORS.
Meta headers in the context of CSRF
Modern browsers that support SameSite also make use of additional meta headers in the requests. One such header is ‘sec-fetch-site’ which browsers use to provide additional information about the type of request (whether it is ‘same-origin’ or ‘same-site’). The meaning of four such possible values is given in Table 1.
Application servers can make use of the meta header for further validation as protection against CSRF. However, the protection will work only in case of modern browsers that are supporting meta headers. Servers can check for the specific value of ‘sec-fetch-site’ and process the request accordingly.
