# 乌云归档：邪恶的CSRF
Author: 乌云历史资料库 (@wooyun_archive)
Published: 2016-05-11T02:52:00Z
Canonical: https://wepostx.com/topics/240
> 乌云历史资料归档
>
> **原始作者：** superfish
> **原始编号：** superkieran-wooyundrops:1189
> **原始发布时间：** 2016-05-11 10:52
> **声明：内容仅用于技术研究和个人使用，版权归 wooyun.org。**
---
# 0x00 什么是CSRF
CSRF全称Cross Site Request Forgery，即跨站点请求伪造。我们知道，攻击时常常伴随着各种各样的请求，而攻击的发生也是由各种请求造成的。
从前面这个名字里我们可以关注到两个点：一个是“跨站点”，另一个是“伪造”。前者说明了CSRF攻击发生时所伴随的请求的来源，后者说明了该请求的产生方式。所谓伪造即该请求并不是用户本身的意愿，而是由攻击者构造，由受害者被动发出的。
CSRF的攻击过程大致如图：
# 0x01 CSRF攻击存在的道理
一种攻击方式之所以能够存在，必然是因为它能够达到某种特定的目的。比如：通过程序中的缓冲区溢出漏洞，我们可以尝试控制程序的流程，使其执行任意代码；通过网站上的SQL注入漏洞，我们可以读取数据库中的敏感信息，进而获取Webshell甚至获取服务器的控制权等等。而CSRF攻击能够达到的目的是使受害者发出由攻击者伪造的请求，那么这有什么作用呢？
显然，这种攻击的威力和受害者的身份有着密切的联系。说到这儿我们可以思考一下，攻击者之所以要伪造请求由受害者发出，不正是想利用受害者的身份去达到一些目的吗？换句话说，受害者身上有达到这个目的所必需的条件，
而这些必需的条件在Web应用中便是各种各样的认证信息，攻击者就是利用这些认证信息来实现其各种各样的目的。
下面我们先看几个攻击场景。
# 0x02 场景举例
（1）场景一：
在一个bbs社区里，用户在发言的时候会发出一个这样的GET请求：
```text
#!html GET /talk.php?msg=hello HTTP/1.1 Host: www.bbs.com … Cookie: PHPSESSID=ee2cb583e0b94bad4782ea (空一行)
```
这是用户发言内容为“hello”时发出的请求，当然，用户在请求的同时带上了该域下的cookie，于是攻击者构造了下面的csrf.html页面：
```text
#!html 
```
可以看到，攻击者在自己的页面中构造了一个发言的GET请求，然后把这个页面放在自己的服务器上，链接为http://www.evil.com/csrf.html。之后攻击者通过某种方式诱骗受害者访问该链接，如果受害者此时处于登录状态，就会带上bbs.com域下含有自己认证信息的cookie访问http://www.bbs.com/talk.php?msg=goodbye,结果就是受害者按照攻击者的意愿提交了一份内容为“goodbye”的发言。
有人说这有什么大不了的，好，我们再看看另一个场景下的CSRF攻击。
（2）场景二：
在一个CMS系统的后台，发出下面的POST请求可以执行添加管理员的操作：
```text
#!html POST /manage.php?act=add HTTP/1.1 Host: www.cms.com … Cookie: PHPSESSID=ee2cb583e0b94bad4782ea; is_admin=234mn9guqgpi3434f9r3msd8dkekwel (空一行) uname=test&pword=test
```
在这里，攻击者构造了的csrf2.html页面如下：
```text
#!html
```
该页面的链接为http://www.evil.com/csrf2.html，攻击者诱骗已经登录后台的网站管理员访问该链接（比如通过给管理员留言等方式）会发生什么呢？当然是网站管理员根据攻击者伪造的请求添加了一个用户名为evil的管理员用户。
通过这些场景我们可以看到，CSRF攻击会根据场景的不同而危害迥异。小到诱使用户留言，大到垂直越权进行操作。这些攻击的请求都是跨域发出,并且至关重要的一点，都是在受害者的身份得到认证以后发生的。另外，我们在第一个场景中攻击时并没有使用JavaScrpit，这说明CSRF攻击并不依赖于JavaScript。
# 0x03 CSRF攻击方式
（1）HTML CSRF攻击：
即利用HTML元素发出GET请求（带src属性的HTML标签都可以跨域发起GET请求），如：
```text
#!html 