With the rapid development of the Internet, web security becomes more and more important.

What is a CSRF

CSRF stands for Cross Site Request Forgery. So how was it faked? Take a look at the following example:

I logged in to website A
http://www.a.com
xxx/delete? id=1

For these reasons, users go to website B (or possibly a phishing site) http://www.b.com. ; When users return to a website, they find that their personal information is missing!

Yes, it was this invisible picture that sent a request to delete personal information to server A, and server A lacked corresponding defense measures, causing the disaster. Similar scenarios could include property damage, account cancellation… Etc. If the link is sent to friends or public platforms through the message or Posting interface, the attack will spread like a virus after friends or platform users view it (see Baidu’s CSRF Worm).

How to launch a CSRF attack

We are not here to teach you how to be bad. We know that if you know your enemy, you can win a hundred battles. If you know how to defend yourself, you have to know the nature of the attack, right?

We know that HTTP is stateless, that is, it does not distinguish between users and requests, and it does not record request status. That’s why sessions and cookies are used to distinguish users and verify identities. Once this step is passed, the request is considered legitimate. So as long as we get the identity certificate (session, cookie), can not pretend to be the user to do anything?

After the user logs in to http://www.a.com, he jumps to (or opens) http://www.b.com. We have a tag like this on the B website

<img hidden src="http://www.a.com/xxx/delete?id=1" />
Copy the code

As soon as the tag is loaded, a’s server receives the removal request. Can you only attack with img tags? Too young, Too simple. Any tag with a SRC attribute will work. What about the request/XXX /delete? Id =1 can I just change it to POST? Too young, Too simple, Too! Post requests that we attack like this:

<form hidden action="http://www.a.com/xxx/delete" method="post">
    <input value="1" name="id"</form> <script> window.onload =function(){
    document.forms[0].submit();
}
</script>
Copy the code

How do I defend against CSRF attacks

Based on the above attack process, we found that as long as the session or cookie was forged, the following steps were fine. Defensively, you want it to be less smooth.

  • Verification code

    This is the simplest and most effective way to log in, register, and prevent machine ticket brushing we see a lot. Unfortunately, we can’t do this with every request at every step.

  • Referer Check(why Referer is not written as Referrer, that’s historical.

    If a request comes from the domain www.a.com, the server validates the source of the client’s request with the value of the HTTP request header’s Referer field as www.a.com. This step needs to be implemented by the server. The problem is that the server does not always fetch the Referer, or even in some cases does not send it (for reasons you can check).

  • Anti CSRF Token

    The nature of CSRF is that the parameters of any request that has been spoofed are predictable. Then we add randomly generated tokens to the request parameters, and the attack cost increases in an instant. Tokens must be unpredictable, and if our randomly generated token is an 8-digit number, it will take no time for an attacker to brute force crack it. Tokens must satisfy both confidentiality and randomness.

Reference: White Hat on Web Security, by Wu Hanqing