XSS的攻击方式是黑客向用户页面注入恶意脚本，通过恶意脚本将用户页面的数据上传到黑客的服务器，最后黑客重用这些数据进行恶意操作。 XSS攻击会带来巨大的破坏力，但另一种类型的攻击也不容忽视。 那是今天要说的CSRF攻击。
请相信你经常听到的话。 “别点击那个链接，小心病毒！ ”点击链接怎么能感染病毒呢？
结合有关CSRF攻击的实际典型案例进行分析，2007年的一天，David无意中打开了Gmail邮箱中的邮件，点击了该邮件的链接。 几天后，David发现他的域名被盗了。 但是，几经周折，David回到了他的域名。 他的域名被盗，也表明是因为不小心点击了链接。
David的域名是怎么被偷的呢？
结合下图分析David域名盗窃过程。
首先，David开始请求登录Gmail邮箱，Gmail服务器将向David的浏览器返回登录状态。 此信息包含Cookie、Session等，Gmail邮箱在David浏览器中处于登录状态。
然后，黑客诱惑David打开类似hacker.com的链接，在hacker.com页面上创建邮件过滤器，并通过Gmail提供的HTTP配置界面设置新的邮件过滤器功能。 此过滤器将David的所有邮件转发到黑客邮箱。
最后一件事很简单。 由于有David的邮件内容，黑客可以前往域名提供商端重置David域名帐户密码，重置密码后，将其转出到黑客帐户。
以上就是David域名被盗的完整过程。 其中的前两个步骤是今天要讲的CSRF攻击。 David回到他的域名后，把整个攻击过程分享到了他的网站上。 如果你感兴趣，请参考
CSRF攻击CSRF是什么？ 英文全名为Cross-site request forgery，故又称“伪造跨网站请求”，指黑客引导用户打开黑客网站，黑客网站利用用户登录状态发起跨网站请求简而言之，CSRF 攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事
通常，用户打开黑客页面后，黑客会通过三种方式实施CSRF攻击。
以极客时间官网为例，分析一下这三种攻击方式是如何实施的。 这里假设网站具有转账功能，可以通过POST或Get进行转账。 转账接口如下：
有了上面的转账接口，我们就可以模拟CSRF攻击。
1 .自动启动get请求黑客最容易实施的攻击方法是自动启动get请求。 关于具体的攻击方法，请参照以下代码。
这是黑客页面的HTML代码，在此代码中，黑客将转账请求接口隐藏在img标签中，欺骗浏览器，这是图像资源。 此页面加载后，浏览器会自动启动img资源请求。 如果服务器不确定该请求，服务器会将该请求识别为转移请求，并将用户帐户的100极客货币转移到黑客帐户中。
2 .自动提交POST请求除了自动提交Get请求外，有些服务器接口还使用POST方法，黑客需要在他的站点上伪造POST请求。 用户打开黑客网站时，会自动提交开机自检请求。 具体方法请参考以下示例代码。
在这段代码中，您可以看到黑客构建了隐藏在他页面上的表单。 本表格内容为极客时间转账界面。 当用户打开网站时，此表单将自动提交。 表单提交后，服务器将执行转移操作。 因此，通过构建自动提交表单，可以自动实现网站之间的POST数据发送。
3 .让用户单击链接的方法，除了自动启动Get和Post请求外，还有让用户单击黑客网站链接的方法。 这通常出现在论坛和恶意邮件中。 黑客用各种方法诱惑用户并点击链接。 示例代码如下所示。
这个黑客网站的代码，页面上有美女的照片，下面是图片的下载地址。 这个下载地址实际上是黑客用的接口，当用户单击时
了这个链接，那么他的极客币就被转到黑客账户上了。以上三种就是黑客经常采用的攻击方式。如果当用户登录了极客时间，以上三种 CSRF 攻击方式中的任何一种发生时，那么服务器都会将一定金额的极客币发送到黑客账户。
到这里，相信你已经知道什么是 CSRF 攻击了。和 XSS 不同的是，CSRF 攻击不需要将恶意代码注入用户的页面，仅仅是利用服务器的漏洞和用户的登录状态来实施攻击
如何防止 CSRF 攻击了解了 CSRF 攻击的一些手段之后，我们再来看看 CSRF 攻击的一些“特征”，然后根据这些“特征”分析下如何防止 CSRF 攻击。下面是我总结的发起 CSRF 攻击的三个必要条件：
第一个，目标站点一定要有 CSRF 漏洞；
第二个，用户要登录过目标站点，并且在浏览器上保持有该站点的登录状态；
第三个，需要用户打开一个第三方站点，可以是黑客的站点，也可以是一些论坛。
满足以上三个条件之后，黑客就可以对用户进行 CSRF 攻击了。这里还需要额外注意一点，与 XSS 攻击不同，CSRF 攻击不会往页面注入恶意脚本，因此黑客是无法通过 CSRF 攻击来获取用户页面数据的；其最关键的一点是要能找到服务器的漏洞，所以说对于 CSRF 攻击我们主要的防护手段是提升服务器的安全性。
要让服务器避免遭受到 CSRF 攻击，通常有以下几种途径。
1. 充分利用好 Cookie 的 SameSite 属性通过上面的介绍，相信你已经知道了黑客会利用用户的登录状态来发起 CSRF 攻击，而Cookie 正是浏览器和服务器之间维护登录状态的一个关键数据，因此要阻止 CSRF 攻击，我们首先就要考虑在 Cookie 上来做文章。
通常 CSRF 攻击都是从第三方站点发起的，要防止 CSRF 攻击，我们最好能实现从第三方站点发送请求时禁止 Cookie 的发送，因此在浏览器通过不同来源发送 HTTP 请求时，有如下区别：
如果是从第三方站点发起的请求，那么需要浏览器禁止发送某些关键 Cookie 数据到服务器；
如果是同一个站点发起的请求，那么就需要保证 Cookie 数据正常发送。
而我们要聊的 Cookie 中的 SameSite 属性正是为了解决这个问题的，通过使用 SameSite 可以有效地降低 CSRF 攻击的风险。
那 SameSite 是怎么防止 CSRF 攻击的呢？
在 HTTP 响应头中，通过 set-cookie 字段设置 Cookie 时，可以带上 SameSite 选项，如下：
SameSite 选项通常有 Strict、Lax 和 None 三个值。
Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方 Cookie。简言之，如果你从极客时间的页面中访问 InfoQ 的资源，而 InfoQ 的某些 Cookie 设置了 SameSite = Strict 的话，那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie。
Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
而如果使用 None 的话，在任何情况下都会发送 Cookie 数据。
对于防范 CSRF 攻击，我们可以针对实际情况将一些关键的 Cookie 设置为 Strict 或者 Lax 模式，这样在跨站点请求时，这些关键的 Cookie 就不会被发送到服务器，从而使得黑客的 CSRF 攻击失效。
2. 验证请求的来源站点接着我们再来了解另外一种防止 CSRF 攻击的策略，那就是在服务器端验证请求来源的站点。由于 CSRF 攻击大多来自于第三方站点，因此服务器可以禁止来自第三方站点的请求。那么该怎么判断请求是否来自第三方站点呢？
这就需要介绍 HTTP 请求头中的 Referer 和 Origin 属性了。
Referer 是 HTTP 请求头中的一个字段，记录了该 HTTP 请求的来源地址。比如我从极客时间的官网打开了 InfoQ 的站点，那么请求头中的 Referer 值是极客时间的 URL，如下图：
虽然可以通过 Referer 告诉服务器 HTTP 请求的来源，但是有一些场景是不适合将来源 URL 暴露给服务器的，因此浏览器提供给开发者一个选项，可以不用上传 Referer 值，具体可参考Referrer Policy
但在服务器端验证请求头中的 Referer 并不是太可靠，因此标准委员会又制定了Origin 属性，在一些重要的场合，比如通过 XMLHttpRequest、Fecth 发起跨站请求或者通过 Post 方法发送请求时，都会带上 Origin 属性，如下图：
从上图可以看出，Origin 属性只包含了域名信息，并没有包含具体的 URL 路径，这是 Origin 和 Referer 的一个主要区别。在这里需要补充一点，Origin 的值之所以不包含详细路径信息，是有些站点因为安全考虑，不想把源站点的详细路径暴露给服务器。
因此，服务器的策略是优先判断 Origin，如果请求头中没有包含 Origin 属性，再根据实际情况判断是否使用 Referer 值。
3. CSRF Token除了使用以上两种方式来防止 CSRF 攻击之外，还可以采用 CSRF Token 来验证，这个流程比较好理解，大致分为两步。
第一步，在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。你可以参考下面示例代码：
第二步，在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。
总结要发起 CSRF 攻击需要具备三个条件：目标站点存在漏洞、用户要登录过目标站点和黑客需要通过第三方站点发起攻击。
根据这三个必要条件，我们又介绍了该如何防止 CSRF 攻击，具体来讲主要有三种方式：充分利用好 Cookie 的 SameSite 属性、验证请求的来源站点和使用 CSRF Token。这三种方式需要合理搭配使用，这样才可以有效地防止 CSRF 攻击。
再结合前面两篇文章，我们可以得出页面安全问题的主要原因就是浏览器为同源策略开的两个“后门”：一个是在页面中可以任意引用第三方资源，另外一个是通过 CORS 策略让 XMLHttpRequest 和 Fetch 去跨域请求资源。
为了解决这些问题，我们引入了 CSP 来限制页面任意引入外部资源，引入了 HttpOnly 机制来禁止 XMLHttpRequest 或者 Fetch 发送一些关键 Cookie，引入了 SameSite 和 Origin 来防止 CSRF 攻击。
点个『在看』支持下