Preface: I haven’t updated for a long time. In the recent interview process, the interviewer asked about CSRF, but didn’t answer it. It was embarrassing. So I found an English article of CSRF and translated it, which is also a learning bar.

Waht is a CSRF?

Here we go:

Cross-site request forgery (CSRF/XSRF), also known as Sea surf or Session Riding, is an attack on Web applications that use cookies for validation, in which an attacker can trick a victim into sending an unintended request. Thus, an attacker can abuse the trust (user information) that the application leaves in the victim’s browser. Although CSRF attacks do not provide the attacker with response information returned from the service, a good attacker can do great damage. Especially with social engineering trap attacks on administrators.

CSRF is an obfuscation proxy attack that uses the victim’s authentication and authorization information to forge a request and send it to the server. A CSRF vulnerability can affect a high-privileged user like a super administrator and take control of the entire application. In a successful CSRF attack, the victim’s browser is induced by a malicious web site to do a harmful action by sending the attacker’s expected HTTP request to the server. Normally, an attack like this involves modifying some data in a Web application submission form.

Whether the request is valid or not, the victim’s browser contains a Cookie in the request header. Cookies are often used to store user session identity information, so users don’t need to enter their login information every time they send a request, which may sound impractical. If the cookie in the victim’s session is still valid (the browser does not need to open a window or Tab) and the application has a CSRF vulnerability, the attacker can use CSRF to send any malicious request to the server, and the server has no way to tell whether it is a legitimate request or not.

CSRF attacks, which can be used in online banking, can force victims to perform operations involving their bank accounts. CSRF can also make XSS attacks easier. Therefore, CSRF can be considered a serious network security issue, even if it is not currently on the Top10 list proposed by OWASP. OWASP Top 10

CSRF attacks in GET requests

    <img src="http://example.com/changePassword.php/?newPassword=attackerPassword">
Copy the code

The CSRF attack above uses HTTP GET requests. If the victim visits a site that the attacker controls to attach the above request, the browser sends a request containing a cookie to the attacker’s forged URL.

CSRF attack in POST request

Get requests are not the only Http methods an attacker can exploit. POST requests can also easily fulfill CSRF requests, but of course an attacker needs to submit a small POST request using Javascript.

Here is a simple example where CSRF sends a POST request using the iframe tag. The code is loaded in an iframe, and the load victims are unaware.

The Iframe definition

<iframe src="http://attacker.com/csrfAttack" style="width:0; height:0; border:0; border:none;" ></iframe>Copy the code

The Iframe HTML content

<body onload="document.getElementById('csrf').submit()">
  <form id="csrf" action="http://example.com/changePassword.php" method="POST">
    <input name="newPassword" value="attackerPassword" />
  </form>
</body>
Copy the code

CSRF prevention

There are two main approaches to preventing CSRF attacks. Synchronize cookies with the anti-CSRF Token already provided to the browser, or prevent the browser from sending cookies to the server in the first place.

Anti-CSRF Tokens

Currently, the recommended and most widely used defense against CSRF attacks is the anti-CSRF token, sometimes referred to as the synchronizer token, or simply the CSRF token. When a user submits a form submission that requires a cookie or other authorization request, a random token should be included in the request. The server verifies that the token is present and correct before processing the request. If the token is missing or wrong, the request will be rejected.

It is highly recommended that you use an existing, tested and reliable anti-CSRF library. Depending on your choice of language and framework, there are many high-quality open source libraries available. The designed anti-CSRF system features include the following attributes

1: The anti-CsrF token is unique in each user session 2: the session is automatically released at the appropriate time 3: the anti-CSRF should be an encrypted random number of valid length 4: the anti-CsrF should be encrypted secure, that is, generated by a strong pseudo-random number generation algorithm (PRNG). 5: Anti-CSRf token can be added to a hidden field in a form or url. 6: The server should reject requests that do not pass validationCopy the code

Same site Cookie

Same-site cookies are a new feature that instructs the browser to disable the use of certain cookies by third parties. The same site feature is set on the server side, where cookies are set and the browser is required to carry cookies only on requests from the first-party environment. Therefore, requests must be sent under same-origin (requests made by third-party sites do not contain same-site cookies). This can effectively eliminate CSRF attacks without using a synchronization token. Unfortunately, this method of preventing CSRF is not supported in all browsers, but more and more browsers are starting to use it.

English website: www.acunetix.com/blog/articl…