CSRF 跨站请求伪造

CSRF是什么

跨站请求伪造（Cross-site request forgery）,也被称为one-click attack或者session riding，通常缩写为CSRF或XSRF。

CSRF简单的说，攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求来自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

举个简单的例子，假如一家银行执行转账操作的URL地址如下：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

你登录了这家银行的网站（以前在这家银行网站查账，转账），这时你打开某个经常访问的论坛，有人在论坛中发了一张图片

你的银行账户的钱就没了1000块。

为什么会这样呢？原因是银行网站违反了HTTP规范，使用GET请求更新资源。在访问论坛的之前，你已经登录了银行网站，而论坛中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站的Cookie发出Get请求，去获取资源，结果银行网站服务器收到请求后，认为这是转账操作，所以就立刻进行转账操作。

如果银行网站更新了提交方式，改用POST提交，但是攻击者仍然可以伪造一个表单页面，向银行网站POST提交数据，设置自动提交，只要你点击了他发的链接，你的银行账户又少了1000块。

为什么又是这样呢？因为你点击了伪页面的链接，等于你通过这个伪页面向银行网站提交了一个请求，结果银行网站受到请求，还是认为这是转账操作，所以就立刻执行转账操作。

通过这个例子可以看出，攻击者并不能通过CSRF攻击来直接获取用户的账户控制权，也不能直接窃取用户的任何信息。他们能做的，是欺骗用户浏览器，让其以用户的名义执行操作

攻击者不需要控制放置恶意代码的网站，他可以将恶意代码藏在论坛，博客等任何用户发布内容的网站中，也可以通过聊天工具或者短信方式推送这种恶意链接，诱导你去点击访问，目的也很简单，千方百计的让这个恶意链接在你的浏览器中执行，以达到不可告人的目的。

如何防御

1.验证 HTTP Referer 字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName，用户必须先登录examplebank.com，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，通常是以 examplebank.com 域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站或者第三方网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站或者第三方网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以examplebank.com 开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。

2.添加 token 并验证

CSRF攻击之所以能够成功，是因为攻击者欺骗用户去访问自己设置的地址，伪造用户的请求，该请求中所有的用户验证信息都是存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。

如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在Cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法进行CSRF攻击了。这种数据通常是表单中的一个数据项，服务器将其生成并附加在表单中，其内容是一个伪乱数。当客户端通过表单提交请求时，这个伪乱数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪乱数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪乱数的值，服务器端就会因为校验token的值为空或者错误，拒绝这个可疑请求。

文章版权归作者和饥人谷所有，转载须说明来源

`