CSRF is called cross-site request forgery, XSRF is also called XSRF, but it’s pretty much the same, you can think of it as a combination of XSS and CSRF. I didn’t really understand the attack, so I wrote an interface, tried it out, and made the request directly.

First look at the interface:

const http=require('http');



http.createServer(function(requset,response){

 response.setHeader('Access-Control-Allow-Credentials'.'true');

 response.end('123');

}).listen(3000);
Copy the code

When I access the image address, it appears:

A cookie associated with a cross-site resource at was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None

Cookies are not allowed if I set:

response.setHeader(‘Set-Cookie’, ‘a=888; Path=/; SameSite=Lax’);

Then the request succeeds with the IMG tag:

<img src="http://192.168.164.31:3000/" alt="">
Copy the code

Although the cookie is not carried, I don’t know if this is the reason:

Chrome plans to make Lax the default. At this point, the site can choose to explicitly turn off the SameSite property and set it to None. However, the Secure attribute must be set at the same time (cookies can only be sent through HTTPS). Otherwise, cookies are invalid.

Don’t write out good interface to verify, so had to something simple to understand, is the user access security website, log in, after the success of the login, user authentication login information recorded in the browser, users in a secure web site can be normal operation at this time, if after the user in the same browser to access unsafe websites, Insecure websites use various methods to attack the login information of users of secure websites, such as:

1. After the secure website A logs in, the insecure website B invokes the interface of get request through img, script and other non-cross-domain elements. If it is judged by the request carrying cookie, the request can be directly successful.

2. If the background is POST interface, only POST can be used for verification data to obtain parameters. Insecure website B can embed secure website A through IFRAM, and then submit requests through form form.

This is generally known as a simple CSRF. Some sources say that there are hundreds of methods that can trigger a request, including 196 for HTML alone. PDF JavaScript, ServiceWorkers, and other weird ways to do XSRF attacks.

There are ways to defend against attacks, such as checking Referer, adding validation tokens, not saving cookies, not using global cookies, customizing header attributes and validation, and so on.

Although I do not know whether CSRF attack is really so simple, I suddenly found that the project I have done is not as safe as I imagined, and I feel that I can be attacked at will.

It’s hard to imagine a security team like Ali, the first target of almost any hack, dealing with more than just CSRF.