当前位置：网站首页>Cross Site Request Forgery (CSRF): impact, examples, and Prevention

Cross Site Request Forgery (CSRF): impact, examples, and Prevention

2022-07-26 01:40:00 【allway2】

Cross-site request forgery (CSRF/XSRF), Also known as Sea Surf or Session Riding, It is a kind of network security vulnerability , It can induce the web browser to perform unnecessary operations . therefore , Attacker abuse Web The trust of the application in the victim's browser . It allows attackers to partially bypass the same origin policy , This strategy aims to prevent different websites from interfering with each other .

This is about application security Part of a wide range of guidelines

CSRF What is the impact of the attack ？

When a website sends data requests and user sessions to another website on behalf of users cookie when , Attackers can launch cross site request forgery attacks , This will abuse the trust relationship between the victim's browser and the web server .

In some cases , Depending on the type of operation , An attacker can completely control the user's account . If the infected user has a privileged role in the application , An attacker may be able to completely control all functions and data of the application , This is devastating for both enterprises and users . The result may be data theft 、 Unauthorized transfer of funds 、 Damaged customer relationships 、 Password change, etc .

How Cross Site Request Forgery works ？

When users try to access the site , Browsers usually automatically include credentials in the request , To make the login process more convenient . These credentials may include the user's session cookie、 Basic authentication credentials 、IP Address and Windows Domain credentials .

The inherent risk of this mechanism is that attackers can easily impersonate users . Once the user passes the authentication of the site , The site cannot distinguish between forged requests and legitimate user requests .

stay CSRF In attack , The attacker used the identity of the victim , And use it to perform operations on behalf of the user without the user's consent . Attackers usually follow the following process ：

They use social engineering techniques to persuade victims to email 、 Chat messages or similar communication methods, click the link .
Malicious links themselves or web pages visited by users will trigger requests for target sites
The request allegedly came from the user , And take advantage of the fact that users have logged in to the website .
The website acknowledges the request and performs the operation requested by the attacker without the user's knowledge or consent .

CSRF Attacks usually try to change the state of the server , But it can also be used to access sensitive data . If the attacker successfully attacks the victim's account CSRF attack , They can transfer funds 、 Buy the product 、 Modify account information （ Such as delivery address ）、 Change the password or any other action available when the user logs in .

CSRF Examples of attacks

The following example shows 5,000 Typical of US dollar bank transfer GET The request may be as follows ：

GET https://abank.com/transfer.do?account=RandPerson&amount=$5000 HTTP/1.1

An attacker can modify the script , So that 5,000 The dollar is transferred to their personal account . Malicious requests can be as follows ：

GET https://abank.com/transfer.do?account=SomeAttacker&amount=$5000 HTTP/1.1

after , Attackers can embed requests into seemingly harmless hyperlinks ：

<a href="https://abank.com/transfer.do?account=SomeAttacker&amount=$5000">Click for more information</a>

The next step is to distribute hyperlinks to a large number of bank customers via email . Those who log in to their bank account and click this link will inadvertently initiate 5,000 The transfer of dollars .

If the bank's website only uses POST request , Cannot be used <a> href Tags to build malicious requests . however , Attacks can be made in <form> Pass in the tag .

This is the appearance of such a form , It can even be a self submitted form ：

<body onload="document.forms[0].submit()> <form id=”csrf” action="https://abank.com/transfer.do" method="POST"> <input type="hidden" name="account" value="SomeAttacker"/> <input type="hidden" name="amount" value="$5000"/> </form> </body>

Because the form above has no submit button , It will be triggered without the user's knowledge and consent . contrary , This button consists of only one line javascript Replace ：

document.getElementById('csrf').submit();

What is? CSRF Tokens, ？

CSRF The token is the only one generated by the server-side application 、 Unpredictable secret value , And send it to the client to include the subsequent HTTP In request . After issuing the token , When the client makes a request , The server checks whether the request contains the expected token , If the token is missing or invalid , Then reject it .

CSRF Tokens can prevent CSRF attack , Because they can prevent attackers from forming completely effective HTTP request , These requests can be made available to victims . Attackers cannot identify or predict users CSRF The value of the token , Therefore, any request they generate should not be accepted by the application .

common CSRF Loophole ：CSRF Weaknesses in token implementation

Some of the most common CSRF The vulnerability is caused by CSRF Caused by an error in the token verification process . Make sure your CSRF The process does not have any of these weaknesses .

Verification depends on the existence of the token

In some applications , If the token does not exist , Then the verification process will be skipped . This means that the attacker only needs to find the code containing the token information and delete it , The application does not perform token validation .

CSRF The token is not related to the user session

Some applications maintain a token pool , Just use the token in the pool , It will be accepted . however , The application does not bind a specific token to a specific user . The attacker only needs to get at least one token from the pool , You can use it to impersonate any user .

Use HTTP Method to change token validation

In some applications , Use GET Method, not POST Method will result in CSRF Verification does not work . The attacker only needs to start from POST Switch to GET, You can easily bypass the verification process .

CSRF The token is copied to cookie

Some applications do not record tokens that are already in use . contrary , They copy the request parameters associated with each token to the user's cookie in . In this setting , An attacker can use the expected format of the application to create a token containing cookie, Place it in the user's browser , And then execute CSRF attack . The request sent by the user browser will be verified , Because it will match the malicious provided by the attacker cookie.

CSRF The prevention of ： transcend CSRF token

prevent CSRF The basic method is to realize CSRF token , At the same time, avoid the weaknesses we described in the previous section . The following is to prevent CSRF Other ways to attack .

Use advanced authentication techniques to reduce CSRF

When all parameters used in the form are recognized , Attackers can launch CSRF attack . therefore , In order to prevent CSRF attack , You can add an additional parameter , This parameter has additional value unknown to the attacker , But the server needs to verify .

The most widely used CSRF Attack prevention technology is called anti CSRF Token or synchronizer token . When a user sends some authenticated requests by submitting a form , The request should contain a random token . The website will then verify the presence of this token before processing the sent request , If the token is missing or the value is incorrect , The request will be rejected , Attackers will not be able to initiate CSRF attack .

RFC 6265 bisSameSite As defined in cookie Attribute attempts to alleviate CSRF attack . This attribute tells the browser when it can send with cross site requests cookie.cookie Attribute has three possible values —— 、 or . Most mobile browsers and all desktop browsers support this property .SameSiteStrict LaxNone

The Strict value You can tell the browser not to send to the site during the cross site browsing session cookie. This includes sessions that follow regular links . for example , When the user logs in GitHub And browse the private managed by the company GitHub Project time , The browser will not send messages to GitHub Send session cookie, This limits access to the project .

If you don't need to allow external websites to link to the transaction page , You can use Strict flag. however , If you need to strike a balance between availability and security , Enable users guided by external links to maintain login sessions - You should use the default Lax value . Usually , stay Lax Cross site requests granted in mode are considered Security Of HTTP Method .

Here are the USES SameSite cookie Two properties cookie Example ：

Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

Based on user interaction CSRF defense

Usually , Defense mechanisms that require user intervention will have a negative impact on the user experience . however , In some cases , For example, financial transactions , It is appropriate and necessary to implement this technology . for example , You can add verification code , This helps to verify that it is indeed a human user rather than a robot .

A one-time token also ensures that it is the user and not the attacker using the login session . The token is usually sent to the user's email address or phone number , And use the information provided by the user to verify . Besides , You can introduce reauthentication , This helps to distinguish CSRF Sessions and real users .

Many developers ignore the CSRF Loophole . This is because the user has not been authenticated at this stage , So the developer assumes no CSRF The risk of . However , This assumption is not always true . An attacker can perform login CSRF attack , This may have different effects depending on the application .

Sign in CSRF An attack can be made by creating a pre session （ Start the session before user authentication ） And request a token in the login form to alleviate .

If you cannot trust subdomains （ for example , If you allow your users to define their own sub domains ）, It is difficult to ease login CSRF. In these cases , You can use strict subdomain and path level reference header validation to reduce the complexity of login forms CSRF risk .

On a regular basis Web Application security testing to identify CSRF

Even if the problem with CSRF The attack Web Vulnerabilities in the application , Application updates and code changes may also expose your application to CSRF.Web Application security testing can help you continuously scan and test Web Potential security vulnerabilities in applications , Include CSRF Loophole .

Bright Helps cross the development process early Web Applications and API Automatically detect and fix many vulnerabilities , Include CSRF.

By way of DAST Scan left shift and integrate them into SDLC in , Developers and application security professionals can find vulnerabilities early , And fix them before they appear in the production environment .Bright By automatically verifying each vulnerability , Complete the scan in a few minutes and achieve zero false positives . This allows developers to adopt the solution and use it throughout the development lifecycle .

Scan any Web Application or REST、SOAP and GraphQL API To prevent CSRF Loophole ： free The trial Bright

Please refer to our additional guide topic on critical application security

With our content partners , We have written in-depth guides on several other topics , These guides are also useful when you explore the world of application security .