First, you need to set whether cross-origin requests and cross-origin frame requests are allowed for nginx on the server side (both are not allowed by default ). Furthermore, the browser imposes strict cross-origin ajax restrictions and does not allow cross-origin access cookies. So what we do for csrf during web development (generally we add a hiddencsrftokeninput to form) is unnecessary? First, you need to set whether cross-origin requests and cross-origin frame requests are allowed for nginx on the server side (both are not allowed by default ).
Furthermore, the browser imposes strict cross-origin ajax restrictions and does not allow cross-origin access cookies.
So what we do for csrf during web development (generally we add a hidden csrf token input to form) is unnecessary? Reply content: Hahaha, of course, still needed.
After nginx is configured with 'x-Frame-options' to 'sameorigin', iframe cannot be used for different subdomains in the same domain, since it cannot be opened, let alone get the cookie through js to get the session id.
However, a simpler attack is still unavoidable:
If you are in a Wi-Fi environment (LAN) where I have my hands and feet, I have contaminated the dns and made a malicious website called csrf-attack, then you log on to a website without csrf defense called no-csrf-token, and then I made a page in csrf-attack, which contains a form like this:
The browser cannot prevent crsf attacks. [The browser is so secure now ]......
This is really not a phishing post? Everything is visible in the background.
