跨站点请求伪造（CSRF） 是一种攻击类型，当恶意网站、电子邮件、博客、即时消息或程序导致用户的Web浏览器在用户通过身份验证后对受信任的站点执行不需要的操作时，就会发生这种攻击。CSRF攻击之所以有效，是因为浏览器请求会自动包含所有Cookie（包括会话Cookie）。因此，如果用户通过了站点的身份验证，则站点无法区分合法的授权请求和伪造的身份验证请求。当使用适当的授权时，这种攻击就会被阻止，这意味着需要一个挑战-响应机制来验证请求者的身份和权限。

成功的CSRF攻击的影响仅限于易受攻击的应用程序暴露的功能和用户权限。例如，此攻击可能导致转移资金、更改密码或使用用户的凭据进行购买。实际上，攻击者使用CSRF攻击，在受害者不知情的情况下，通过受害者的浏览器使目标系统执行某项功能，至少在提交未经授权的事务之前是如此。

防止CSRF漏洞
尽管有许多CSRF预防机制。例如，使用referer头，使用HttpOnly标志，发送X请求-与使用jQuery等自定义头。但并非所有这些方法在所有情况下都有效。在某些情况下，它们是无效的，而在其他情况下，很难在特定应用程序中实现或产生副作用。

总之，防御CSRF应遵循以下原则：

• 检查您的框架是否具有内置的CSRF保护，如果框架没有内置的CSRF保护，请将CSRF令牌添加到所有状态更改请求（在站点上引起操作的请求）中，并在后端验证它们
• 对于有状态软件，请使用同步器标记模式，对于无状态软件，请使用双重提交Cookie
• 至少实施一项缓解措施纵深防御缓解措施截面
• 考虑SameSite
  Cookie属性对于会话Cookie但是要注意不要专门为域设置cookie，因为这会引入安全漏洞，即该域的所有子域共享cookie。当子域的CNAME不属于您控制的域时，这尤其是一个问题。
• 考虑实施基于用户交互的保护用于高度敏感的操作
• 考虑一下使用自定义请求标头
• 考虑使用标准标头验证来源
• 请记住，任何跨站点脚本（XSS）都可以用来击败所有CSRF缓解技术!
• 不要将GET请求用于状态更改操作。
• 如果您出于任何原因这样做，请针对CSRF保护这些资源
• 如需了解详情 可在留言板跟博主交流