CSRF 原理
- 用户 A 登录并信任安全网站
- 通过网站认证，并在用户 A 的浏览器上产生安全网站的 Cookie
- 用户 A 在没有登出安全网站的情况下，访问危险网站
- 危险网站要求访问安全网站，发出一个请求
- 根据危险网站在 4 的请求，浏览器带着 2 产生的 Cookie 访问安全网站
- 安全网站并不知道请求是谁发出的，由于请求带着用户 A 的 Cookie，所以会根据用户 A 的权限处理该请求，这样危险网站就达到了模拟用户操作的目的了。
CSRF 攻击可以从站外和站内发起：
- 从站内发起 CSRF 攻击，需要利用网站本身的业务，比如“自定义头像”功能，恶意用户指定自己的头像 URL
是一个修改用户信息的链接，当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。 - 从站外发送请求，则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的 html 页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求（上图）。
可以看出，要完成一次 CSRF 攻击，受害者必须依次完成两个步骤：
- 登录受信任网站 A，并在本地生成 Cookie
- 在不登出 A 的情况下，访问危险网站 B（除了通过 img 的超链接，还可以通过表单）
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到 CSRF 的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
- 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
- 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
- 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
CSRF 防范
服务端的 CSRF 方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数
Cookies Hashing（所有表单都包含同一个伪随机值）
在用户登录时，设置一个随机的 Token 也就是令牌，同时种植在用户的 Cookie 中，当用户浏览器关闭、或用户再次登录时，清除 Token。在表单中生成一个隐藏域，它的值就是 Cookie 中随机 Token，通过 md5 加密将客户端 Cookie 中令牌值传递到服务器端。表单被提交后，就可以判断表单中的 Token 和用户cookie中的 Token 是否一致，如果不一致或没有这个值，就是 CSRF 攻击。但是当站点被 XSS 注入之后，隐藏框的防御 CSRF 功能将彻底失效。如果我们为用户的每一个表单请求中都加入随机的 Cookies，那么这种方法会变得更加安全，但是这并不是十分合适。HTTP 来路
检测访问来路是否可信的最简单方法是，获得 HTTP 请求中的来路信息（即名为 Referer 的 HTTP 头）并且检查它来自站内还是来自一个远程的恶意页面：这是一个很好的解决方法，但是由于可以对服务器获得的请求来路进行欺骗以使得他们看起来合法，这种方法不能够有效防止攻击。
因为攻击者可以伪造 HTTP 头并发送，从而骗过服务器。
由于 HTTP Referer 是由客户端浏览器发送的，而不是由服务器控制的，因此你不应当将该变量作为一个信任源。验证码
就是我们平时经常填的那种，这个方案可以完全解决 CSRFOne-Time Tokens（不同的表单包含一个不同的伪随机值）
在表单生成时生成令牌，在每次检测步骤结束后，令牌都会被销毁，并且仅仅在下一次表单页面时才会重新生成
在实现 One-Time Tokens 时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF 保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保 CSRF 保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。
XSS 与 CSRF
CSRF 攻击经常与 XSS 联合， 如果 XSS 防御失效，攻击者可以拿到用户页面所有信息，CSRF 就会失去效果。
XSS 甚至能直接拿到 Cookie（document.cookie），这个通过在写入客户端 Cookie 时带上 HttpOnly 可以防范。
案例
Node.js 中有些框架已经帮我们做了这件事，比如重用的 connect
它具体的实现：http://www.senchalabs.org/connect/csrf.html
