- Introduction
- Features of CSRF
- The history of CSRF
- Limitations of CSRF attacks
- Prevention of CSRF attacks
- STP technology
- Cookie-to-header token
- Double Submit Cookie
- SameSite cookie attribute
- Client-side safeguards
Introduction
Coupon https://m.fenfaw.cn/The full name of CSRF is Cross-site request forgery cross-site request forgery, also known as one-click attack or session hijacking. It is a malicious use of the website, mainly using the trust of authorized users in the site, innocent end users The attacker was tricked into submitting a Web request they didn't want. Malicious websites can send such commands in a variety of ways. For example, special image tags, hidden forms, and JavaScript XMLHttpRequests can all work without user interaction or even knowledge.
If a CSRF attack occurs, it may cause accidental leakage of client or server data, change of session status, or modification of user information.
Features of CSRF
In the CSRF malicious attack, the attacker's goal is to make the attacked unknowingly submit a malicious web request to a website that has permission to visit. The request is carefully designed to include URL parameters, cookies, and other data that is normally displayed by the Web server processing the request. A user who is authenticated through a cookie stored in the user's web browser may unknowingly send an HTTP request to a site that trusts the user, resulting in unnecessary operations.
Why is there such an 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. CSRF attacks take advantage of this attribute because any web request made by the browser will automatically include any cookies (including session cookies and other cookies) created when the victim logs on to the website. If a user is tricked into submitting a request through the browser inadvertently, these automatically included cookies will enable the forgery to pass the authentication of the target server, thereby causing a malicious attack.
In order to generate such an attack URL, the malicious attacker needs to construct a web request that can be executed, such as changing the account password on the target page. The attacker can embed the link on a page within the attacker's control. For example, it can be embedded in the html image tag in the email sent to the victim, and the image will be automatically loaded when the victim opens his email. Once the victim clicks the link, their browser will automatically include all cookies used by the website and submit the request to the web server. The web server will execute the malicious request.
The history of CSRF
As early as 2001, some people began to use it to carry out attacks. However, because the attack uses the user's own IP address, which looks like a normal request from the user, there is little direct evidence of the attack. The well-known CSRF attacks currently known are as follows:
In 2006, Netflix broke a number of CSRF vulnerabilities. Attackers could change the recipient's account receiving address to purchase goods for the attackers themselves.
YouTube was also attacked by CSRF in 2008, which allows any attacker to perform almost all operations of any user.
McAfee Secure has also been attacked by CSRF, which allows attackers to change the company's systems.
In 2018, some routers were also attacked by CSRF, which made it possible to modify the router's DNS settings.
Limitations of CSRF attacks
To achieve a CSRF attack requires certain conditions. In fact, a CSRF attack is not a very simple thing. The following conditions must be met:
- The target web service does not check the referrer header of the request. If only the same-origin request is allowed, CSRF cannot be used.
- The attacker must find the form submission file on the target site, or find a URL with offensive attributes that will perform certain actions (for example, transfer money or change the victim's email address or password).
- The attacker must determine the correct value for all forms or URL inputs; if any of them is required to be a secret authentication value or ID that the attacker cannot guess, the attack is likely to fail (unless the attacker is in their guess very lucky).
- When the victim logs in to the target site, the attacker must induce the victim to enter a web page with malicious code.
- The attacker can only send requests, but cannot see the content sent back to the user by the target site in response to the attack request. If the operation is continuous, subsequent CSRF attacks will not be completed.
Prevention of CSRF attacks
Because web browsers handle different HTTP requests in different ways, the defense against CSRF attacks is related to the HTTP request method.
In HTTP GET, the use of CSRF attack is very simple, for example, the attack URL is brought into the IMG tag and it will be automatically loaded. However, according to the HTTP specification, the GET method should not be used to modify data. Applications that use GET to update data should switch to HTTP POST or use anti-CSRF protection.
The HTTP POST vulnerability of CSRF depends on the use case:
In the simplest form of POST, the data is encoded as a query string (field1 = value1 & field2 = value2), and a simple HTML form can be used to easily implement CSRF attacks, which means that countermeasures must be taken. CSRF measures.
If the data is sent in any other format (JSON, XML), the standard method is to use XMLHttpRequest to make a POST request, and use Same Origin Policy (SOP) and Cross-domain Resource Sharing (CORS) to prevent CSRF attacks.
Other HTTP methods (PUT, DELETE, etc.) can only use the same-origin policy (SOP) and cross-domain resource sharing (CORS) to prevent CSRF XMLHttpRequest requests; however, when using Access-Control-Allow-Origin: *The header is clear These measures will have no effect on websites where they are disabled.
Let's explain several techniques to prevent CSRF in detail below
STP technology
The full name of STP is Synchronizer token pattern. In other words, all HTML forms include a hidden token field. The token can be generated in many ways, as long as the randomness is guaranteed. Because the attacker cannot predict the value of this token, CSRF attacks cannot be performed. For example, the following code:
<input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />
STP is the most compatible because it only relies on HTML, but each request with a token will increase the complexity of the program. Since the token is unique and unpredictable, it will also enforce the proper sequence of events, which will Cause some usability issues (for example, the user opens multiple tabs). It can be relaxed by using every session CSRF token instead of every request CSRF token.
Cookie-to-header token
If the web application mainly uses javascript to interact, consider using this approach.
When accessing the web service for the first time, a random token is set in the cookie, and the cookie cannot be accessed in cross-domain requests:
Set-Cookie: csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; Domain=.wikipedia.org; SameSite=Lax; Secure
When running javascript on the client side, read the token value from the cookie and copy it to the custom HTTP header sent with each transaction request
X-Csrftoken：i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
The server verifies the existence and integrity of the token. Because JavaScript running from malicious files or emails cannot successfully read the cookie value to copy into the custom header. Even if the csrf token cookie is automatically sent with the malicious request, the server still needs a valid X-Csrf-Token header.
This technology has been implemented by many frameworks, such as Django and AngularJS, because the token remains the same throughout the user session, so it can work well with AJAX applications.
Note that to use this technology, 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. The site can 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 whether the cookie token matches the form token. The same-origin policy prevents attackers from reading or setting cookies on the target domain, so they cannot place valid tokens in their carefully designed form.
Compared with the synchronizer mode, the advantage of this technology is that there is no need to store the token on the server.
SameSite cookie attribute
When the server sets a cookie, it can include an additional "SameSite" attribute, indicating whether the browser attaches the cookie to the cross-site request. If this attribute is set to "strict", cookies are only sent in requests from the same origin, thus invalidating CSRF. However, this requires the browser to recognize and correctly implement the attribute, and also requires the cookie to have the "Secure" logo.
Client-side safeguards
The browser itself can block CSRF by providing a default rejection policy for cross-site requests. Such as RequestPolicy of Mozilla Firefox or uMatrix of Firefox and Google Chrome / Chromium. However, this may seriously interfere with the normal operation of many websites.
Some browser extensions such as the CsFire extension (also applicable to Firefox) can reduce the impact on normal browsing by removing authentication information from cross-site requests.
This article has been included in http://www.flydean.com/csrf/
The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!
Welcome to pay attention to my official account: "Program those things", know technology, know you better!