密码学系列之:csrf 跨站点请求伪造
简介
CSRF 的全称是 Cross-site request forgery 跨站点请求伪造，也称为一键攻击或会话劫持，它是对网站的一种恶意利用，主要利用的是已授权用户对于站点的信任，无辜的最终用户被攻击者诱骗提交了他们不希望的 Web 请求。 恶意网站可以通过多种方式来发送此类命令。 例如，特制的图像标签，隐藏的表单和 JavaScript XMLHttpRequests 都可以在用户不交互甚至不知情的情况下工作。
如果发生了 CSRF 攻击，可能导致客户端或服务器数据意外泄漏，会话状态更改或者修改用户的信息。
CSRF 的特点
在 CSRF 的恶意攻击中，攻击者的目标是让被攻击者在不知不觉中向有权限访问的网站提交恶意的 web 请求。通过对该请求进行精心的设计，使其包含 URL 参数，Cookie 和其他对处理该请求的 Web 服务器而言正常显示的数据。通过保存在用户 Web 浏览器中的 cookie 进行身份验证的用户可能会在不知不觉中将 HTTP 请求发送到信任该用户的站点，从而导致不必要的操作。
为什么会有这样的攻击呢？因为对于 web 浏览器来说，它们将在发送给该域的任何 Web 请求中自动且无形地包含给定域使用的任何 cookie。 CSRF 攻击利用了此属性，因为浏览器发出的任何 Web 请求都将自动包含受害者登录网站时创建的任何 cookie（包括会话 cookie 和其他 cookie）。如果用户被诱骗通过浏览器无意中提交了请求，这些自动包含的 cookie 将使伪造也能够通过目标服务器的认证，从而产生恶意攻击。
为了生成这样的攻击 URL，恶意攻击者需要构造一个可以被执行的 web 请求，比如在目标页面上更改帐户密码。攻击者可以将该链接嵌入攻击者控制范围内的页面上。比如它可以嵌入到发送给受害者的电子邮件中的 html 图像标签中，当受害者打开其电子邮件时，该图像会自动加载。一旦受害者单击了链接，他们的浏览器将自动包含该网站使用的所有 cookie，并将请求提交到 Web 服务器。 Web 服务器将会执行该恶意请求。
CSRF 的历史
早在 2001 年，就有人开始使用它来进行攻击了。不过因为攻击使用的是用户自己的 IP 地址，看起来就像是用户自己的一个正常的请求，所以很少有直接的攻击证据。目前知道的比较有名的 CSRF 攻击如下：
2006 年 Netflix 爆出了众多 CSRF 漏洞，攻击者可以更改受害者的账户收货地址，从而为攻击者自己来购买商品。
YouTube 在 2008 年也受到了 CSRF 的攻击，这使得任何攻击者都几乎可以执行任何用户的所有操作。
McAfee Secure 也曾经受到过 CSRF 的攻击，它允许攻击者更改公司系统。
2018 年，一些路由器也受到了 CSRF 的攻击，从而能够修改路由器的 DNS 设置。
CSRF 攻击的限制
要想达成 CSRF 攻击是需要一定的条件的，事实上 CSRF 攻击也并不是一个很简单的事情,必须满足下面的条件：
目标 web 服务没有检查请求的 referrer header，如果只允许同源请求的话，则无法使用 CSRF。
攻击者必须在目标站点上找到表单提交文件，或者发现具有攻击属性的 URL，该 URL 会执行某些操作（例如，转账或更改受害者的电子邮件地址或密码）。
攻击者必须为所有表单或 URL 输入确定正确的值；如果要求它们中的任何一个是攻击者无法猜到的秘密身份验证值或 ID，则攻击很可能会失败（除非攻击者在他们的猜测中非常幸运）。
当受害者登录到目标站点时，攻击者必须诱使受害者进入带有恶意代码的网页。
攻击者只能发出请求，但是无法看到目标站点响应攻击请求发回给用户的内容，如果操作具有连续性的话，后续的 CSRF 攻击将无法完成。
CSRF 攻击的防范
因为 web 浏览器对不同的 HTTP 请求处理方式是不同的，所以针对 CSRF 攻击的防范跟 HTTP 请求的方法相关。
在 HTTP GET 中，使用 CSRF 攻击非常简单，比如将攻击 URL 带入 IMG 标签就会自动加载。但是，根据 HTTP 规范，GET 方法不应该被用于修改数据。使用 GET 进行更新数据操作的应用程序应切换到 HTTP POST 或使用反 CSRF 保护。
CSRF 的 HTTP POST 漏洞取决于使用情况：
在最简单的 POST 形式中，数据编码为查询字符串（field1 = value1＆field2 = value2），可以使用简单的 HTML 形式轻松实现 CSRF 攻击，这就意味着必须采取反 CSRF 措施。
如果以其他任何格式（JSON，XML）发送数据，标准方法是使用 XMLHttpRequest 发出 POST 请求，并通过同源策略（SOP）和跨域资源共享（CORS）防止 CSRF 攻击。
其他 HTTP 方法（PUT，DELETE 等）只能使用具有同源策略（SOP）和跨域资源共享（CORS）来防止 CSRF 的 XMLHttpRequest 请求；但是，在使用 Access-Control-Allow-Origin：*标头明确禁用它们的网站上，这些措施将无效。
下面我们来具体讲解几个防范 CSRF 的技巧
STP 技术
STP 的全称是 Synchronizer token pattern。也就是说在所有的 HTML 表单上包含一个隐藏的 token 字段，token 是可以由很多种方法来生成，只要保证其随机性就行了。因为攻击者无法预测到这个 token 的值，所以无法进行 CSRF 攻击。比如下面的代码：
STP 是兼容性最好的，因为它仅依赖 HTML，但是每个请求都带上 token 会增加程序的复杂性， 由于 token 是唯一且不可预测的，因此还会强制执行适当的事件顺序，这会引发一些可用性的问题（例如用户打开多个选项卡）。 可以通过使用每个会话 CSRF 令牌而不是每个请求 CSRF 令牌来放宽它。
Cookie-to-header token
如果 web 应用程序主要使用 javascript 来进行交互的话，可以考虑使用这种方式。
在初次访问 web 服务的时候，会在 cookie 中设置一个随机令牌，该 cookie 无法在跨域请求中访问：
在客户端运行 javascript 的时候，从 cookie 中读取这个 token 值，并将其复制到随每个事务请求发送的自定义 HTTP 标头中
服务器验证令牌的存在和完整性。因为从恶意文件或电子邮件运行的 JavaScript 无法成功读取 cookie 值以复制到自定义标头中。即使将 csrf token cookie 与恶意请求一起自动发送，服务器任然需要有效的 X-Csrf-Token 头。
这项技术已经被很多框架实现了，比如 Django 和 AngularJS，因为令牌在整个用户会话中保持不变，所以它可以与 AJAX 应用程序很好地协同工作。
注意，使用这项技术，必须确保同源政策。
Double Submit Cookie
这个方法与 cookie-to-header 方法类似，但不涉及 JavaScript，站点可以将 CSRF 令牌设置为 cookie，也可以将其作为每个 HTML 表单中的隐藏字段插入。 提交表单后，站点可以检查 cookie 令牌是否与表单令牌匹配。 同源策略可防止攻击者在目标域上读取或设置 Cookie，因此他们无法以其精心设计的形式放置有效令牌。
与同步器模式相比，此技术的优势在于不需要将令牌存储在服务器上。
SameSite cookie attribute
当服务器设置 cookie 时，可以包含一个附加的“ SameSite”属性，指示浏览器是否将 cookie 附加到跨站点请求。 如果将此属性设置为“strict”，则 cookie 仅在相同来源的请求中发送，从而使 CSRF 无效。 但是，这需要浏览器识别并正确实现属性，并且还要求 cookie 具有“Secure”标志。
Client-side safeguards
浏览器本身可以通过为跨站点请求提供默认拒绝策略，来阻止 CSRF。比如 Mozilla Firefox 的 RequestPolicy 或者 Firefox 和 Google Chrome / Chromium 的 uMatrix 之类。但是，这可能会严重干扰许多网站的正常运行。
有些浏览器扩展程序如 CsFire 扩展（也适用于 Firefox）可以通过从跨站点请求中删除身份验证信息，从而减少对正常浏览的影响。
本文已收录于 http://www.flydean.com/csrf/
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！
欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！
版权声明: 本文为 InfoQ 作者【程序那些事】的原创文章。
原文链接:【http://xie.infoq.cn/article/dae27f57595270ea902a23c66】。文章转载请联系作者。
关注公众号：程序那些事，更多精彩等着你！ 2020.06.07 加入
最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧，尽在公众号：程序那些事！
评论