一、CSRF攻击的概念

CSRF（Cross Site Request Forgery, 跨站请求伪造）是一种网络攻击方式，该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在并未授权的情况下执行在权限保护之下的操作，对用户的安全及网站的安全具有很大的危害性。

一、CSRF攻击的原理

如下图所示，CSRF攻击的原理比较容易理解，其中Web A是存在CSRF漏洞的网站，Web B是攻击者构造的恶意网站，User为Web A的合法用户。

这里写图片描述

    用户打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

    在用户信息通过验证之后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

    用户未退出网站A之前，在同一浏览器中，打开一个Tab页访问网站B；

    网站B接收到用户请求后，返回一些带有攻击性的代码，并发出请求要求访问第三方站点A；

    浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户的Cookie信息以及用户的权限处理该请求，导致来自网站B的恶意代码被执行。

三、CSRF攻击和XSS攻击是同一个概念吗？

CSRF和XSS不是同一个概念，两者还是有一定的区别的，CSRF是对网站的恶意利用。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。CSRF攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

四、CSRF攻击的危害？

攻击者可以盗用了你的身份，以你的名义发送恶意请求。CSRF的危害包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括且不局限于：个人隐私泄露以及财产安全。

五、造成CSRF攻击的原因

跨站请求伪造能否成功，与以下几个方面有很大的关系：

1. 浏览器对会话的处理

Web浏览器对于Cookie和HTTP身份验证信息之类的会话信息的处理方式，目前，浏览器会自动地发送标识用户对话的信息，而无需用户干预，换句话说，当浏览器发送这些身份信息的时候，用户根本感觉不到。

假设站点A上有一个Web应用程序，并且受害者正好已经在该站点上通过了身份认证，这时，站点会向受害者发送一个cookie作为响应，这个cookie的作用是什么呢？主要是被站点作为用户会话的标志，即如果站点收到了带有受害者的cookie的请求，那么它就会把这个请求看作是已登录的受害者发来的。一般情况下，浏览器收到站点设置的cookie之后，每当向该站点发送请求的时候，浏览器都会“自动地”连同该cookie一起发出。

2. 攻击者对WEB应用有关URL的了解

如果应用程序没有在URL中使用跟会话有关的信息的话，那么通过代码分析或者通过访问该应用程序并查看嵌入HTML/JavaScript中的URL以及表单来了解应用程序有关的URL、参数和容许值。

3. 应用程序赖以管理会话的信息对浏览器的透明性以及各种能够引发资源请求HTML标签等

我们知道，为了提高Web应用的便利性，用来管理会话的信息，例如Cookie或者基于HTTP的身份验证（例如HTTP基本认证、非基于表单的认证）等敏感信息，都是由浏览器来存放的，并在每当向需要身份验证的应用程序发送请求时自动捎带上这些信息。也就是说，浏览器可以访问会话管理信息，如果Web应用程序完全依赖于这类信息来识别一个用户会话，这就为跨站请求伪造创造了条件。

4. 存在多种HTML标签

上面所说的三个因素，是跨站请求伪造攻击的必要的条件，而第四个因素，即使没有它也能发动跨站请求伪造攻击，但是有了它能使该攻击更加容易。这就是存在多种HTML标签，如果页面内出现这些标签，会立刻引起浏览器对http[s]资源的访问，例如图像标签img便是其中之一。（例如;(img src=”https://www.company.example/action” width=”0” height=”0”),这个img标签，因为其将width设置为0所以在页面上是显示不出来的，但是这个img所携带的命令仍然能够跟随页面的打开执行一些恶意代码。）

六、CSRF攻击的实例

注：实例来自：http://www.2cto.com/Article/201307/230742.html

小明如果遭受 CSRF 攻击严重的有如下现象，情景假设：

小明早上起来登录了 shopping.com 购物网站；

在登录后同时在新的标签中打开了一个恶意（malicious）网站，并点击了里面的一个按钮或者图片；

回到 shopping.com 的时候发现，他账户里的钱少了 ￥1000。

上面的只是情景假设，一般的购物网站不会这样单纯。

试着看看里面它是如何工作的：

小明成功登录了 shopping.com 网站，他的浏览器保存了浏览器产生的一个 cookie，注意此 cookie 中保存了某些登录信息或者授权信息。同时我们假设：shopping.com 服务器向账户 「123456」转账 ￥1000 的接口是：

http://shopping.cm/Transfer.html?toAccount=123456&money=1000

产生的 HTTP 请求可能是：

GET http://shopping.cm/Transfer.html?toAccount=123456&money=1000

...

Cookie:XXXXXXXXXX

...

未名攻击者特地写了个带图片的链接，可以是下面的形式：

<a href="daoluan.net"><img height="185" width="185" alt="" src="http://shopping.cm/Transfer.html?toAccount=123456&money=1000"></a>

    1

小明傻乎乎的点击打开，于是浏览器尝试装载图片的时候，同时提交了小明的 cookie。服务器收到此请求，验证 cookie 正确后，于是修改了数据，即给账户「123456」转账 ￥1000.没错，在装载图片过程中会产生上面形式的 HTTP 请求。

电商 shopping.com 不会简单的发送 HTTP GET 请求转账，HTTP GET 本身基因就决定他必须把参数暴露在链接中。那采用安全点的 POST 如何？编写一个 method 为 POST 的表单就达到目标。以上的情况严重点，CSRF 稍微好一点的情景是通由小明在某个站点上的登录，提交一个评论。