Two things often talked about in WEB security: XSS and Cross-site request forgery (CSRF). These two concepts are also frequently asked in front-end interviews.
As long as WEB security is involved, they must be mentioned. From my previous interview experience, I have tried on these two things many times.
A few things, but let me describe them in detail, and I can't imagine the results. In the past few days, I have consulted related books and finally figured out these two things. So I decided to write an article to record the two of them for future review. This article first introduces cross-site request forgery CSRF.
What is Cross-site request forgery?
CSRF (Cross-Site Request Forgery). Also called One Click Attack and Session Riding, usually abbreviated as CSRF or XSRF. If you don’t know what it means from the name, you can understand this: an attacker (hacker, phishing site) has stolen your identity and sent malicious requests in your name, these requests include sending mail, sending messages, stealing Account number, purchase of goods, bank transfer, so that your personal privacy is leaked and the property is lost.
Cross-site request forgery (CSRF) status
The attack method of CSRF has been proposed by foreign security personnel in 2000, but in India, it was not noticed until 2006. In 2008, many large communities and interactive websites at home and abroad broke CSRF vulnerabilities, such as the New York Times, Metafilter, YouTube, and Baidu. And now, many sites on the Internet are still unprepared for it, so that the security industry calls CSRF "the sleeping giant".
CSRF attack example
After listening so much, maybe everyone is still in the fog, and the concept of light listening may not be enough for CSRF. Below I will give an example to let everyone have a deeper understanding of CSRF.
Let's first assume that there is a CSRF vulnerability in Paytm, my Paytm account is Alice, and the attacker's Paytm account is xxx.
Then we can request http://paytm.com/withdraw?account=Alice&amount=1000&for=Alice2 through the web page to transfer my account Alice $10,00 to another account Alice2.
Normally after the request is sent to the Paytm server, the server will first verify whether the request comes from a legitimate session and the user of the session has successfully logged in.
The attacker also has the account xxx in the payment bar. He knows that the URL above can be used for transfer operations, so he can send a request http://paytm.com/withdraw?account=Alice&amount=1000&for=xxx to the Paytm backend.
But this request came from the attacker and not from my Alice, so it cannot pass the security authentication, so the request is invalid. At this time, the attacker xxx thought of using CSRF, he made a yellow website himself, and put the following code in the website:
http://paytm.com/withdraw?account=Alice&amount=1000&for=xxx and lured me to visit his website through a yellow link.
When I couldn't help but temptation, I clicked in, the above request will be sent to Paytm from my own browser, and this request will be accompanied by a cookie in my browser.
In most cases, the request will fail, because Paytm requires my authentication information, but if I haven’t just visited Paytm and haven’t closed the Paytm page, the cookie in my browser holds my authentication information, this request will get a response.
I transferred $1000 from my account to the xxx account, and I didn't know that the attacker got away with the money after getting the money. Therefore, you must restrain yourself in the future and do not open other people's links casually.
CSRF Principle
The following picture explains the principle of cross-site request forgery (CSRF)
As can be seen from the above figure, to complete a CSRF attack, the victim must complete the following two steps in sequence:
- Log in to the trusted website and generate cookies locally.
- Without logging out from a trusted website, visit the hacker website.
Seeing this, you may ask: "If I don't meet one of the above two conditions, I won't be attacked by CSRF." Yes, it is true, but you cannot guarantee that the following will not happen:
- You cannot guarantee that after you log in to a website, you will no longer open a tab page and visit other websites.
- You cannot guarantee that after you close the browser, your local cookies will expire immediately, and your last session has ended.
- The so-called attack website mentioned above may be a phishing website or a yellow website.
How to defend against CSRF
Verify the HTTP referrer field
According to the HTTP protocol, there is a Referer field in the HTTP header, which records the address of the HTTP request, indicating that the HTTP request was sent from that page.
For example, when you visit http://paytm.com/withdraw account=Alice&amount=1000&for=xxx, the user must first log in to the Paytm website and then trigger the transfer event by clicking the button on the page.
At this time, the Referer value of the transfer request is the URL where the transfer page is located, usually, any address beginning with the domain name paytm.com.
If the attacker wants to carry out a CSRF attack, then he can only construct a request at his own site, at this time the Referer value points to the hacker's own website.
Therefore, to defend against CSRF attacks, Paytm only needs to verify the Referer value for each transfer request. If the domain name starts with Paytm.com, it is a legitimate request, on the contrary, it is an illegal request and rejected.
The advantage of this method is that it is simple and easy to do. You only need to add an interceptor in the background to check the Referer.
However, this method is not foolproof. The value of the Referer is provided by the browser. Some low-level browsers can tamper with the value of Referer in some way, which gives attackers an opportunity.
For security reasons, users can be set to no longer provide the Referer value when sending HTTP requests, so that when they normally visit the Paytm website, they are mistaken for CSRF attacks because they do not provide the Referer value, and they refuse to access. In practice, the second method is usually used to defend against CSRF attacks.
Add token verification
The reason why the CSRF attack is successful is that the attacker can completely forge the user's request.
All user authentication information in the request is stored in the cookie, so the attacker can directly use the user's own cookie without knowing the authentication information. To pass security verification.
To prevent CSRF, the key is to put in the request information that the hacker cannot forge, and the information does not exist in the cookie. You can add a randomly generated token to the HTTP request in the form of parameters, and establish an interceptor on the server to verify the token.
If there is no token in the request or the token is incorrect, it is considered that it may be a CSRF attack and reject the request.
Now the industry's consistent approach is to use Anti CSRF Token to defend against CSRF.
- The user visits a form page.
- The server generates a token and puts it in the user's session or in the browser's cookie.
- Attach the Token parameter to the page form.
- After the user submits the request, the server verifies whether the Token in the form is the same as the Token in the user's Session (or Cookies). If they are the same, they are legal requests. If they are not, they are illegal.
This token value must be random and unpredictable. Due to the existence of Token, the attacker can no longer construct a request with a legitimate Token to implement a CSRF attack.
In addition, the use of Token should pay attention to the confidentiality of the Token, try to change the sensitive operation from GET to POST, and submit it in the form or AJAX to avoid Token leakage.
Captcha
The verification code forces users to interact with the application to complete the final request. Under normal circumstances, the verification code can well contain CSRF attacks. However, due to user experience considerations, the website cannot add verification codes to all operations. Therefore, the verification code can only be used as an auxiliary means.Try to use POST Limit GET
The GET interface can directly expose the request address to the attacker, so it is better not to use GET to prevent CSRF. Of course, POST is not foolproof. The attacker only needs to construct a form, but it needs to be done on a third-party page, which increases the possibility of exposure.
Add custom attributes in the HTTP header
This method also uses tokens and authentication, but it puts tokens in the HTTP request header. By using AJAX we can add our custom attributes in our request header, but this method requires us to change the entire station request to AJAX. If it is a new station, the old station is undoubtedly needed to be rewritten The whole site is very undesirable.
Well, CSRF is finished, the next article we introduce XSS cross-site scripting attack.