CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站。
CSRF 攻击主要是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。

CSRF 攻击可以做哪些事？

  • 自动发起 Get 请求
  • 自动发起 Post 请求

  • 引诱用户点击链接

    自动发起 Get 请求

    <!DOCTYPE html>

    黑客的站点：CSRF攻击演示

    2. 什么是 CSRF？如何防御CSRF攻击？ - 图1
    如上述代码：如果黑客将转账的请求接口隐藏在 img 标签内，当该页面加载并自动发起 img 的资源请求时，服务器则会发起黑客隐藏在 img 标签内的接口。

    自动发起 Post 请求

    <!DOCTYPE html>

    黑客的站点：CSRF攻击演示


    如上述代码，当用户打开该站点之后，这个表单会被自动执行提交；当表单被提交之后，服务器就会执行转账操作。

    引诱客户点击链接

    2. 什么是 CSRF？如何防御CSRF攻击？ - 图2

    如上述代码，引诱客户点击美女链接，发起转账请求。

    与 XSS 攻击的区别？

    CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击。
    发起 CSRF 攻击的三个必要条件：

  • 目标站点有 CSRF 漏洞

  • 用户要登录过目标站点，并在浏览器留有该站点的登录状态（Cookie）

  • 需要用户打开第三方站点（如黑客的站点）

    如何防范 CSRF 攻击？

  • 充分利用好 Cookie 的 SameSite 属性

  • 验证请求的来源站点 （Referrer Policy）

  • CSRF Token

    利用 Cookie 的 SameSite 属性防范 CSRF 攻击

    黑客会利用用户的登录状态来发起 CSRF 攻击，而 Cookie 正是浏览器和服务器之间维护登录状态的一个关键数据，因此要阻止 CSRF 攻击，我们首先就要考虑在 Cookie 上来做文章。
    通常 CSRF 攻击都是从第三方站点发起的，要防止 CSRF 攻击，我们最好能实现从第三方站点发送请求时禁止 Cookie 的发送，而 Cookie 中的 SameSite 属性正是为了解决这个问题的，通过使用 SameSite 可以有效地降低 CSRF 攻击的风险。
    SameSite 属性有以下几个值：

  • Strict：完全禁止第三方 Cookie

  • Lax：从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
  • None：任何情况下都会发送 Cookie 数据。

    利用 HTTP 请求头中的 Referer 和 Origin 字段来验证请求的来源站点

    Referer 是 HTTP 请求头中的一个字段，记录了该 HTTP 请求的来源地址。
    虽然可以通过 Referer 告诉服务器 HTTP 请求的来源，但是有一些场景是不适合将来源 URL 暴露给服务器的，因此浏览器提供给开发者一个选项，可以不用上传 Referer 值，具体可参考 Referrer Policy。
    但在服务器端验证请求头中的 Referer 并不是太可靠，因此标准委员会又制定了 Origin 属性，在一些重要的场合，比如通过 XMLHttpRequest、Fecth 发起跨站请求或者通过 Post 方法发送请求时，都会带上 Origin 属性。
    服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer 值。

    CSRF Token

    这个流程大致分两步：
    第一步，在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。
    第二步，在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。

    参考链接

    34 | CSRF攻击：陌生链接不要随便点 (geekbang.org)