什么是CSRF跨站请求伪造

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的网络安全攻击类型，它利用用户在已认证的Web应用程序上执行非自愿的操作。攻击者通过欺骗用户来执行未经授权的操作，这些操作可能包括更改用户密码、发送恶意请求等。

CSRF攻击通常利用了Web应用程序的信任关系，攻击者诱使已认证用户执行恶意操作，而用户无法察觉。攻击者可以通过各种方式来实施CSRF攻击，包括在受害者浏览器中植入恶意代码、诱使用户点击带有恶意请求的链接等。

CSRF攻击

攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮 件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过（cookie 里带来 sessionId 等 身份认证的信息），所以被访问的网站会认为是真正的用户操作而去运行。

比如用户登录了某银行网站（假设为 http://www.examplebank.com/，并且转账地址为 http://www.examplebank.com/withdraw?amount=1000&transferTo=PayeeName），登录后 cookie 里会包含登录用户的 sessionid，攻击者可以在另一个网站上放置如下代码

（或者直接就是跳出来一个弹框，弹框上有一张色色的图片，你只要点击了这张图片，就会触发请求。注意这里攻击者并不知道你的详细请求地址，但是它完全可以多放置一些常见银行网站的请求，互联网上那么多人万一就真的碰对了。这个就是我们常说的钓鱼网址。就像在茫茫大海上钓鱼，万一就真的碰到了呢。当然，一般来说也就是用你电脑上的算力挖点矿而已。）

<img src="http://www.examplebank.com/withdraw

?account=Aloce&amount=1000&for=badman">

那么如果正常的用户误点了上面这张图片，由于相同域名的请求会自动带上 cookie，而 cookie 里带有 正常登录用户的 sessionid，类似上面这样的转账操作在 server 就会成功，会造成极大的安全风险

CSRF 攻击的工作原理流程：

1. 认证会话利用：

   • 用户在登录了一个网站之后，网站会分配一个认证令牌（比如Cookie、session、token等）来标识用户的会话。
   • 任何拥有该会话令牌的请求都会被服务器视为来自合法用户的请求。

2. 攻击者构造伪造请求：

   • 攻击者构造一个恶意网站（例如通过电子邮件或者社交工程方式诱使用户访问）。
   • 在恶意网站中，攻击者通过HTML表单、图片请求或者JavaScript等方式，向目标网站发送一个请求。
   • 请求中包含了合法用户在目标网站的操作，比如发起转账、修改信息等。

3. 用户执行未经意的操作：

   • 如果用户已经在浏览器中保持了登录状态，并且在攻击者构造的恶意网站上执行了某些操作（如点击了一个链接或者加载了一个图片），浏览器会自动发送之前伪造的请求到目标网站。

4. 服务器接受伪造请求：

   • 目标网站接收到这个请求时，并不能区分它是由合法用户发起的还是由攻击者伪造的，因为请求中包含了合法的认证信息（比如Cookie）。

5. 执行未经授权的操作：

   • 目标网站会执行请求中指定的操作，这可能导致用户不愿意的结果，如转账、信息修改等。

CSRF 攻击的根本原因在于对于同样域名的每个请求来说，它的 cookie 都会被自动带上，这个是浏览器 的机制决定的，所以很多人据此认定 cookie 不安全。

使用 token 确实避免了CSRF 的问题，但正如上文所述，由于 token 保存在 本地浏览器的localstorage中，它会被 JS 读 取，从存储角度来看也不安全（实际上防护 CSRF 攻击的正确方式是用 CSRF token）

所以不管是 cookie 还是 token，从存储角度来看其实都不安全，都有暴露的风险，我们所说的安全更多 的是强调传输中的安全（可以在请求头中加入随机的密钥），可以用 HTTPS 协议来传输， 这样的话请求头都能被加密，也就保证了传输中 的安全。

为了防范CSRF攻击，可以采取以下一些常见的防御措施：

1. 同源检查（Same-Site Cookies）：确保Cookie仅对于与设置Cookie的网站具有相同域的请求可见。通过设置SameSite属性为Strict或Lax来限制Cookie的发送，从而减少CSRF攻击的风险。

2. CSRF令牌（CSRF Token）：在表单提交或者请求中包含一个随机生成的令牌，并在后端验证该令牌的有效性。攻击者由于无法获取到合法的CSRF令牌，因此无法成功发起CSRF攻击。

3. 双重Cookie提交（Double Submit Cookie）：在用户的Cookie和请求参数中都包含一个随机生成的令牌，服务器校验两者是否匹配来防止CSRF攻击。

4. 自定义请求头：要求在请求中包含自定义的HTTP头部，并在后端进行验证，确保请求是来自合法的源。

5. 验证码：对于敏感操作，可以要求用户输入验证码，以确认其操作是经过身份验证的。

以上措施并非绝对安全，但结合使用可以大大降低CSRF攻击的风险。在开发Web应用程序时，请务必考虑采取适当的安全措施来防范CSRF攻击。