Introduction to the

CSRF stands for cross-site request Forgery, also known as one-click attack or session hijacking. It is a malicious use of a website, mainly using the trust of authorized users to the site. Innocent end users are tricked by attackers into submitting unwanted Web requests. Malicious sites can send such commands in a number of ways. For example, custom image tags, hidden forms, and JavaScript XMLHttpRequests can all work without user interaction or even knowledge.

If a CSRF attack occurs, client or server data may be accidentally leaked, session status may be changed, or user information may be modified.

The characteristics of CSRF

In a malicious attack on CSRF, the attacker’s goal is to make the victim unknowingly submit a malicious Web request to a site that has access to it. The request is carefully designed to contain URL parameters, cookies, and other data that would normally appear to the Web server handling the request. A user who authenticates through cookies stored in the user’s Web browser may unknowingly send HTTP requests to sites that trust the user, leading to unnecessary operations.

Why this attack? Because for Web browsers, they will automatically and invisibly include any cookies used by a given domain in any Web request sent to that domain. The CSRF attack takes advantage of this property because any Web request made by the browser will automatically contain any cookies (session cookies and other cookies) that the victim created when logging into the site. If a user is tricked into unintentionally submitting a request through the browser, these auto-included cookies will enable forgery to also pass authentication on the target server, resulting in a malicious attack.

To generate such an attack URL, a malicious attacker needs to construct a Web request that can be executed, such as changing the account password on the target page. An attacker can embed this link on a page within the attacker’s control. For example, it could be embedded in an HTML image tag in an email sent to a victim, and the image would load automatically when the victim opened his email. Once the victim clicks the link, their browser automatically contains all the cookies used by the site and submits the request to the Web server. The Web server will execute the malicious request.

The history of CSRF

It was used in attacks as early as 2001. However, because the attack uses the user’s own IP address and looks like a normal request from the user, there is little direct evidence of the attack. Known CSRF attacks are as follows:

In 2006, Netflix revealed numerous CSRF vulnerabilities that allowed an attacker to change the recipient address of a victim’s account to buy goods for the attacker. YouTube was also hit by CSRF in 2008, which allowed any attacker to perform almost everything for any user. McAfee Secure has also been attacked by CSRF, which allows attackers to change corporate systems. In 2018, some routers were also attacked by CSRF, allowing them to modify their DNS Settings.

Limitations of CSRF attacks

In order to achieve a CSRF attack, certain conditions are required. In fact, a CSRF attack is not very simple. The following conditions must be met:

  1. The target Web service does not check the referrer header of the request, and CSRF cannot be used if only cognate requests are allowed.
  2. An attacker must either find a form submission file on the target site or find a URL with attack properties that performs some action (for example, transfer money or change the victim’s email address or password).
  3. An attacker must determine the correct value for all form or URL inputs; If any of them are required to be a secret authentication value or ID that the attacker cannot guess, the attack is likely to fail (unless the attacker is very lucky in their guess).
  4. When the victim logs on to the target site, the attacker must lure the victim to a web page with malicious code.
  5. An attacker can only make a request, but cannot see what the target site sends back to the user in response to the attack request. If the operation is continuous, subsequent CSRF attacks will not be completed.

CSRF attack defense

Because Web browsers handle different HTTP requests differently, protection against CSRF attacks is related to the method of HTTP requests.

In HTTP GET, using CSRF attacks is very simple, such as inserting the attack URL into the IMG tag to be automatically loaded. However, according to the HTTP specification, the GET method should not be used to modify data. Applications that use GET for updating data operations should switch to HTTP POST or use anti-CSRF protection.

The HTTP POST vulnerability of CSRF depends on usage: In the simplest form of POST, where the data is encoded as a query string (field1 = Value1 &field2 = value2), CSRF attacks can be easily implemented using simple HTML, which means anti-CSRF measures must be taken.

If you send data in any other format (JSON, XML), the standard approach is to make a POST request using XMLHttpRequest and protect against CSRF attacks through the same Origin Policy (SOP) and cross-domain resource sharing (CORS).

Other HTTP methods (PUT, DELETE, and so on) can only use the same origin policy (SOP) and cross-domain resource sharing (CORS) to prevent XMLHttpRequest requests from CSRF; However, these measures will not work on sites that explicitly disable them using the Access-Control-Allow-Origin: * header.

Let’s explain some specific techniques to prevent CSRF

STP technology

The full name of STP is Synchronizer Token Pattern. This means that all HTML forms include a hidden token field. Tokens can be generated in a variety of ways, as long as they are random. Because the attacker cannot predict the value of this token, a CSRF attack cannot be carried out. For example:

<input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />
Copy the code

STP is the most compatible because it relies solely on HTML, but carrying tokens on every request adds complexity to the program, and since tokens are unique and unpredictable, it also enforces an appropriate sequence of events, which can raise usability issues (such as users opening multiple tabs). This can be relaxed by using a per-session CSRF token instead of a per-request CSRF token.

Cookie-to-header token

Consider this approach if your Web application uses javascript primarily for interaction.

When accessing a Web service for the first time, a random token is set in a cookie that cannot be accessed in a cross-domain request:

Set-Cookie: csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; Domain=.wikipedia.org; SameSite=Lax; Secure
Copy the code

When the client runs javascript, the token value is read from the cookie and copied into the custom HTTP header sent with each transaction request

X-ray Csrftoken: i8XNjC4b8KVok4uw5RftR38Wgp2BFwqlCopy the code

The server verifies the existence and integrity of the token. JavaScript running from malicious files or E-mail cannot successfully read cookie values to copy into custom headers. Even if a CSRF token cookie is automatically sent along with a malicious request, the server still needs a valid X-CSRF-token header.

This technique has been implemented in many frameworks, such as Django and AngularJS, and works well with AJAX applications because tokens remain constant throughout the user session.

Note that to use this technique, the same origin policy must be ensured.

Double Submit Cookie

This method is similar to the cookie-to-header method, but does not involve JavaScript, and a site can either set the CSRF token as a cookie or insert it as a hidden field in each HTML form. After submitting the form, the site can check if the cookie token matches the form token. The same-origin policy prevents an attacker from reading or setting cookies on the target domain, so they cannot place valid tokens in their well-designed form.

The advantage of this technique over the synchronizer pattern is that tokens do not need to be stored on the server.

SameSite cookie attribute

When the server sets cookies, it can include an additional “SameSite” property that indicates whether the browser attaches cookies to cross-site requests. If this property is set to “strict”, cookies are only sent on requests from the same source, invalidating CSRF. However, this requires the browser to recognize and implement the properties correctly, and also requires the cookie to have the “Secure” flag.

Client-side safeguards

Browsers themselves can block CSRF by providing a default denial policy for cross-site requests. Like Mozilla Firefox RequestPolicy or uMatrix for Firefox and Google Chrome/Chromium. However, this can seriously disrupt the normal operation of many websites.

Some browser extensions such as the CsFire extension (also available for Firefox) can reduce the impact of normal browsing by removing authentication information from cross-site requests.

This article is available at www.flydean.com/csrf/

The most popular interpretation, the most profound dry goods, the most concise tutorial, many tips you didn’t know waiting for you to discover!

Welcome to pay attention to my public number: “procedures those things”, understand technology, more understand you!