1、CSRF 是什么？
咱们简直每天都要用到浏览器，咱们的信息也会被浏览器“保留”。那咱们首先来看一下，浏览器是如何保留你的身份信息的。
当咱们在拜访一个 Web 页面的时候，并不是咱们本人去获取页面信息，而是浏览器去获取了这些信息，并将它们进行了展现。这就阐明，你容许浏览器代表你去和 Web 的服务端进行交互。为了可能精确地代表你的身份，浏览器通常会在 Cookie 中存储一些必要的身份信息。所以，在咱们应用一个网页的时候，只须要在首次拜访的时候登录就能够了。
从用户体验上来说，这当然是十分不便的。然而，黑客正是利用这一点，来编写带有歹意 JavaScript 脚本的网页，通过“钓鱼”的形式诱导你拜访 （诱导你拜访到他的网站）。而后，黑客会 通过这些 JavaScript 脚本窃取你保留在网页中的身份信息，通过仿冒你，让你的浏览器发动伪造的申请，最终执行黑客定义的操作。而这所有对于你本人而言都是无感知的。这就是 CSRF（Cross-Site Request Forgery，跨站申请伪造）攻打。
CSRF 攻打攻打原理及过程如下：
- 用户 C 关上浏览器，拜访受信赖网站 A，输出用户名和明码申请登录网站 A；
- 在用户信息通过验证后，网站 A 产生 Cookie 信息并返回给浏览器，此时用户登录网站 A 胜利，能够失常发送申请到网站 A；
- 用户未退出网站 A 之前，在同一浏览器中，关上一个 TAB 页拜访网站 B；
- 网站 B 接管到用户申请后，返回一些攻击性代码，并收回一个申请要求拜访第三方站点 A；
- 浏览器在接管到这些攻击性代码后，依据网站 B 的申请，在用户不知情的状况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该申请其实是由 B 发动的，所以会依据用户 C 的 Cookie 信息以 C 的权限解决该申请，导致来自网站 B 的恶意代码被执行。
举一个栗子
受害者 Bob 在银行有一笔贷款，通过对银行的网站发送申请 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 能够使 Bob 把 1000000 的贷款转到 bob2 的账号下。通常状况下，该申请发送到网站后，服务器会先验证该申请是否来自一个非法的 session，并且该 session 的用户 Bob 曾经胜利登陆。
黑客 Mallory 本人在该银行也有账户，他晓得上文中的 URL 能够把钱进行转帐操作。Mallory 能够本人发送一个申请给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。然而这个申请来自 Mallory 而非 Bob，他不能通过平安认证，因而该申请不会起作用。
这时，Mallory 想到应用 CSRF 的攻击方式，他先本人做一个网站，在网站中放入如下代码：src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory”，并且通过广告等诱使 Bob 来拜访他的网站。当 Bob 拜访该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个申请会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数状况下，该申请会失败，因为他要求 Bob 的认证信息。然而，如果 Bob 过后凑巧刚拜访他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，喜剧产生了，这个 url 申请就会失去响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 过后毫不知情。等当前 Bob 发现账户钱少了，即便他去银行查问日志，他也只能发现的确有一个来自于他自己的非法申请转移了资金，没有任何被攻打的痕迹。而 Mallory 则能够拿到钱后绳之以法。
CSRF 破绽检测：
检测 CSRF 破绽是一项比拟繁琐的工作，最简略的办法就是抓取一个失常申请的数据包，去掉 Referer 字段后再从新提交，如果该提交还无效，那么基本上能够确定存在 CSRF 破绽。
随着对 CSRF 破绽钻研的不断深入，不断涌现出一些专门针对 CSRF 破绽进行检测的工具，如 CSRFTester，CSRF Request Builder 等。
以 CSRFTester 工具为例，CSRF 破绽检测工具的测试原理如下：应用 CSRFTester 进行测试时，首先须要抓取咱们在浏览器中拜访过的所有链接以及所有的表单等信息，而后通过在 CSRFTester 中批改相应的表单等信息，从新提交，这相当于一次伪造客户端申请。如果批改后的测试申请胜利被网站服务器承受，则阐明存在 CSRF 破绽，当然此款工具也能够被用来进行 CSRF 攻打。
2、如何进攻 CSRF 攻打？
目前进攻 CSRF 攻打次要有三种策略：验证 HTTP Referer 字段；在申请地址中增加 token 并验证；在 HTTP 头中自定义属性并验证。
（1）验证 HTTP Referer 字段
依据 HTTP 协定，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 申请的起源地址。在通常状况下，拜访一个平安受限页面的申请来自于同一个网站，比方须要拜访 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用户必须先登陆 bank.example，而后通过点击页面上的按钮来触发转账事件。这时，该转帐申请的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 bank.example 域名结尾的地址。而如果黑客要对银行网站施行 CSRF 攻打，他只能在他本人的网站结构申请，当用户通过黑客的网站发送申请到银行时，该申请的 Referer 是指向黑客本人的网站。因而，要进攻 CSRF 攻打，银行网站只须要对于每一个转账申请验证其 Referer 值，如果是以 bank.example 结尾的域名，则阐明该申请是来自银行网站本人的申请，是非法的。如果 Referer 是其余网站的话，则有可能是黑客的 CSRF 攻打，回绝该申请。
这种办法的不言而喻的益处就是简单易行，网站的一般开发人员不须要操心 CSRF 的破绽，只须要在最初给所有平安敏感的申请对立减少一个拦截器来查看 Referer 的值就能够。特地是对于以后现有的零碎，不须要扭转以后零碎的任何已有代码和逻辑，没有危险，十分便捷。
然而，这种办法并非十拿九稳。Referer 的值是由浏览器提供的，尽管 HTTP 协定上有明确的要求，然而每个浏览器对于 Referer 的具体实现可能有差异，并不能保障浏览器本身没有安全漏洞。应用验证 Referer 值的办法，就是把安全性都依赖于第三方（即浏览器）来保障，从实践上来讲，这样并不平安。事实上，对于某些浏览器，比方 IE6 或 FF2，目前曾经有一些办法能够篡改 Referer 值。如果 bank.example 网站反对 IE6 浏览器，黑客齐全能够把用户浏览器的 Referer 值设为以 bank.example 域名结尾的地址，这样就能够通过验证，从而进行 CSRF 攻打。
即使是应用最新的浏览器，黑客无奈篡改 Referer 值，这种办法依然有问题。因为 Referer 值会记录下用户的拜访起源，有些用户认为这样会进犯到他们本人的隐私权，特地是有些组织放心 Referer 值会把组织内网中的某些信息泄露到外网中。因而，用户本人能够设置浏览器使其在发送申请时不再提供 Referer。当他们失常拜访银行网站时，网站会因为申请没有 Referer 值而认为是 CSRF 攻打，回绝非法用户的拜访。
（2）在申请地址中增加 token 并验证
CSRF 攻打之所以可能胜利，是因为黑客能够齐全伪造用户的申请，该申请中所有的用户验证信息都是存在于 cookie 中，因而黑客能够在不晓得这些验证信息的状况下间接利用用户本人的 cookie 来通过平安验证。要抵挡 CSRF，关键在于在申请中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。能够在 HTTP 申请中以参数的模式退出一个随机产生的 token，并在服务器端建设一个拦截器来验证这个 token，如果申请中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻打而回绝该申请。
这种办法要比查看 Referer 要平安一些，token 能够在用户登陆后产生并放于 session 之中，而后在每次申请时把 token 从 session 中拿出，与申请中的 token 进行比对，但这种办法的难点在于如何把 token 以参数的模式退出申请。对于 GET 申请，token 将附在申请地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。而对于 POST 申请来说，要在 form 的最初加上 <input type=”hidden”name=”csrftoken”value=”tokenvalue”/>，这样就把 token 以参数的模式退出申请了。然而，在一个网站中，能够承受申请的中央十分多，要对于每一个申请都加上 token 是很麻烦的，并且很容易漏掉，通常应用的办法就是在每次页面加载时，应用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后退出 token。这样能够解决大部分的申请，然而对于在页面加载之后动静生成的 html 代码，这种办法就没有作用，还须要程序员在编码时手动增加 token。
该办法还有一个毛病是难以保障 token 自身的平安。特地是在一些论坛之类反对用户本人发表内容的网站，黑客能够在下面公布本人集体网站的地址。因为零碎也会在这个地址前面加上 token，黑客能够在本人的网站上失去这个 token，并马上就能够动员 CSRF 攻打。为了防止这一点，零碎能够在增加 token 的时候减少一个判断，如果这个链接是链到本人本站的，就在前面增加 token，如果是通向外网则不加。不过，即便这个 csrftoken 不以参数的模式附加在申请之中，黑客的网站也同样能够通过 Referer 来失去这个 token 值以动员 CSRF 攻打。这也是一些用户喜爱手动敞开浏览器 Referer 性能的起因。
（3）在 HTTP 头中自定义属性并验证
这种办法也是应用 token 并进行验证，和上一种办法不同的是，这里并不是把 token 以参数的模式置于 HTTP 申请之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，能够一次性给所有该类申请加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种办法在申请中退出 token 的不便，同时，通过 XMLHttpRequest 申请的地址不会被记录到浏览器的地址栏，也不必放心 token 会透过 Referer 泄露到其余网站中去。
然而这种办法的局限性十分大。XMLHttpRequest 申请通常用于 Ajax 办法中对于页面部分的异步刷新，并非所有的申请都适宜用这个类来发动，而且通过该类申请失去的页面不能被浏览器所记录下，从而进行后退，后退，刷新，珍藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留零碎来说，要采纳这种办法来进行防护，要把所有申请都改为 XMLHttpRequest 申请，这样简直是要重写整个网站，这代价无疑是不能承受的。