Cross Site Request Forgery
CSRF(Cross-site request forgery)，中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。CSRF与XSS在打击手段上有点类似，都是在客户端执行恶意代码，有些文章中认为CSRF与XSS的区别在于CSRF不注重于获取用户Cookie，笔者认为可能还有区别在于CSRF不只可以在源站倡议打击，还可以引导用户访谒其他危险网站的同时倡议打击。XSS全程是跨站脚本打击，即打击者向某个Web页面中插入恶意的JavaScript脚本，而当普通用户访谒时，该恶意脚本自动执行而从偷取用户的Cookie等信息。对付XSS的防御手段主要就是输入查抄与输出查抄，譬如对用户输入的文本框内容进行<、>这样的特殊字符查抄。而输出查抄则是指对付输出到网页的内容进行过滤或者编解码，譬如使用HTML编码将<转义。CSRF为跨站请求伪造，其与XSS有点类似，不过区别在于CSRF不必然依赖于JavaScript，并且不只可以在源站倡议打击，还有可能当用户访谒恶意网站时引导其访谒原网站。CSRF打击是源于WEB的隐式身份验证机制，WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。对付CSRF的防御也分为处事端防御与客户端防御两种，处事端防御范例的譬如给某个页面添加随机数，使得无法从第三方页面直接提交。在客户端防御的话可以操作譬如Firefox供给的一些查抄工具。注意，CSRF并没有冲破同源计谋。 以下面的这个例子来说：银行网站A，它以GET请求来完成银行转账的操纵，如：?toBankId=11&money=1000危险网站B，它里面有一段HTML的代码如下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

银行网站A违反了HTTP规范，使用GET请求更新资源。在访谒危险网站B的之前，你已经登录了银行网站A，而B中的<img>以GET的方 式请求第三方资源(这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被非法分子操作了)，所以你的浏览器会带上你的银行网站A的 Cookie发出Get请求，去获取资源“ money=1000”，功效银行网站处事器收到请求后，认为这是一个更新资源操纵(转账操纵)，所以就立刻进行转账操纵。参考深入解析跨站请求伪造缝隙：道理分解(中所述，XSS与CSRF的区别在于：

XSS打击需要JavaScript，而CSRF打击不需要。

XSS打击要求站点接受恶意代码，而对付CSRF打击来说，恶意代码位于第三方站点上。过滤用户的输入可以防备恶意代码注入到某个站点，但是它无阻止法恶意代码在第三方站点上运行。

原因浅析
CSRF打击是源于WEB的隐式身份验证机制，WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。假设Alice访谒了一个恶意站点M，该站点供给的内容中的JavaScript代码或者图像标签会导致Alice的浏览器向站点T发送一个HTTP请 求。由于该请求是发给站点T的，所以Alice的浏览器自动地给该请求附上与站点T对应的该会话cookie的sid。站点T看到该请求时，它就能通过该 cookie的揣度出：该请求来自Alice，所以站点T就会对Alice的帐户执行所请求的操纵。这样，CSRF打击就能得逞了。其他大大都Web认证机制也面临同样的问题。例如，HTTP BasicAuth机制会要求Alice报告浏览器她在站点T上的用户名和口令，于是浏览器将用户名和口令附加到之后发给站点T的请求中。固然，站点T也 可能使用客户端SSL证书，但这也面临同样的问题，因为浏览器也会将证书附加到发给站点T的请求中。类似的，如果站点T通过IP地点来验证Alice的身 份的话，照样面临CSRF打击的威胁。总之，只要身份认证是隐式进行的，就会存在CSRF打击的危险，因为浏览器发出请求这一行动未必是受用户的指使。原则上，这种威胁可以通过对每个发送至该 站点的请求都要求用户进行显式的、不成欺骗的行动(诸如从头输入用户名和口令)来消除，但实际上这会导致严重的易用性问题。大部分标准和广泛应用的认证机 制都无法防备CSRF打击，所以我们只好此外根究一个实用的解决方案。
Reference

从零开始学CSRF

Preventing CSRF

Security Corner: Cross-Site Request Forgeries

《深入解析跨站请求伪造缝隙：道理分解》

《Web安适测试之跨站请求伪造(CSRF)》

《深入解析跨站请求伪造缝隙：实例讲解》

Exploits