CSRF/XSRF 跨站请求伪造
CSRF（Cross Site Request Forgery, 跨站域请求伪造）也称 XSRF， 是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一。其他安全隐患，比如 SQL 脚本注入，跨站域脚本攻击等在近年来已经逐渐为众人熟知，很多网站也都针对他们进行了防御。然而，对于大多数人来说，CSRF 却依然是一个陌生的概念。即便是大名鼎鼎的 Gmail, 在 2007 年底也存在着 CSRF 漏洞，从而被黑客攻击而使 Gmail 的用户造成巨大的损失。
同源策略带来的安全隐患
回顾上一章节的内容我们有提到，在浏览器的同源策略的约束下，对于跨域资源交互进行处理时，【通常允许跨域资源嵌入（Cross-origin embedding）】。
下面是常见跨域资源嵌入示例：
标签嵌入跨域脚本。语法错误信息只能在同源脚本中捕捉到。和嵌入多媒体资源。
CSRF 攻击的原理，就是利用由于浏览器的同源策略对以上嵌入资源不做限制的行为进行跨站请求伪造的。
CSRF 攻击原理
- 用户浏览位于目标服务器 A 的网站。并通过登录验证。
- 获取到 cookie_session_id，保存到浏览器 cookie 中。
- 在未登出服务器 A ，并在 session_id 失效前用户浏览位于 hacked server B 上的网站。
- server B 网站中的
- 由于用户未登出服务器 A 并且 sessionId 未失效，请求通过验证，非法请求被执行。
如何防御 CSRF
- referer 验证解决方案。
最简单的方法依赖于浏览器引用页头部。大多数浏览器会告诉 Web 服务器，哪个页面发送了请求。如：
POST /bank/transfer.aspx HTTP/1.1 Referer: http://evilsite.com/myevilblog User-Agent: Mozilla/4.... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId=x3q2v0qpjc0n1c55mf35fxid; 不少站点通过 referer 验证来防止盗链本站图片资源。
不过由于 http 头在某些版本的浏览器上存在可被篡改的可能性，所以这个解决方案并不完善。
- Token 解决方案
令牌解决方案向表单添加一个参数，让表单在用户注销时或一个超时期限结束后过期
或者将服务端动态生成的 Token 加入到 自定义 http 请求头参数中
POST /bank/transfer.aspx HTTP/1.1 Referer: https://www.altoromutual.com/bank xsrftoken: JKBS38633jjhg0987PPll User-Agent: Mozilla/4.... Host: www.altoromutual.com Content-Length: 42 Cookie: SessionId=x3q2v0qpjc0n1c55mf35fxid; creditAccount=1001160141&transferAmount=10 token 解决方案的问题在于前后端代码的巨大变更。并且每一步都动态生成 token 并且对 token 进行验证的话，也会造成额外的资源开销。可以尝试在关键性操作的地方再加上 token 验证逻辑。但是，token 验证所带来的前后端代码的变动所带来的消耗，则需要慎重考虑。
- userId 解决方案
相对于 token 这样的需要前后端逻辑作出改动，以及造成额外资源开销的方式以外还有一种小巧的防范措施。就是用户每次请求关键性数据时，后端接口在设计时都需要用户提交相关的 userId。userId 可以存储到浏览器的 localStorage 中，这样便能进一步提高接口安全性，防止跨站请求伪造。
总结
要记住 CSRF 不是黑客唯一的攻击手段，无论你 CSRF 防范有多么严密，如果你系统有其他安全漏洞，比如跨站域脚本攻击 XSS，那么黑客就可以绕过你的安全防护，展开包括 CSRF 在内的各种攻击，你的防线将如同虚设。
CSRF 是一种危害非常大的攻击，又很难以防范。目前几种防御策略虽然可以很大程度上抵御 CSRF 的攻击，但并没有一种完美的解决方案。一些新的方案正在研究之中，比如对于每次请求都使用不同的动态口令，把 Referer 和 token 方案结合起来，甚至尝试修改 HTTP 规范，但是这些新的方案尚不成熟，要正式投入使用并被业界广为接受还需时日。在这之前，我们只有充分重视 CSRF，根据系统的实际情况选择最合适的策略，这样才能把 CSRF 的危害降到最低。