CSRF全称是Cross site request forgery ,翻译过来就是跨站请求伪造。

CSRF是指利用受害者尚未失效的身份认证信息(cookie,会话信息),诱骗其点击恶意链接或者访问包含攻击代码的页面,

在受害人不知情的情况下,以受害人的身份向(身份信息所对应的)服务器发送请求,从而完成非法操作,比如转账,改密码。

CSRF和XSS攻击的区别

CSRF没有盗取用户的cookie信息,而是直接利用用户cookie;相比之下,XSS是盗取用户的cookie信息。

Low级别

DVWA之跨站请求伪造(CSRF)-LMLPHP

首先我用burp suite抓了一下这个改密码的数据包提交的参数有哪些。

DVWA之跨站请求伪造(CSRF)-LMLPHP

http://www.dvwa.com/vulnerabilities/csrf/?password_new=test&password_conf=test&Change=Change

可以发现,这个改密码的接口直接使用GET方法传参。我们在另一个网站(www.a.com)。伪造一个网页在网页中嵌入恶意链接。网页代码

index.html

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>恶意修改密码</title>
</head>
<body>
<h1>当你打开这个网页的时候,你在DVWA网站的密码可能已经修改了</h1>
<img src=" http://www.dvwa.com/vulnerabilities/csrf/?password_new=hack&password_conf=hack&Change=Change"/>
</body>
</html>

关闭DVWA的标签页后访问,www.a.com站点

DVWA之跨站请求伪造(CSRF)-LMLPHP

之后,打开DVWA的网站,退出登录(按照理论上讲,修改密码的接口应该清除之前的session会话,等待新密码重新建立会话,但是这里并没有)

重新使用之前的密码登陆,已经无法登陆

使用hack这个密码可以正常登陆。

分析一下,这个链接太过明显了,如果是我不小心打开了这个页面,我的密码被改了,那么很简单,我看一下这个网页的源码,

发现原来密码是hack,我再改回来不就行了,其实不是这样的,真正的CSRF攻击不会有这么明显的纰漏,可以伪造这个链接。

DVWA之跨站请求伪造(CSRF)-LMLPHP

我这里的长链是本地的,所以无法生成在线的短链。

大家可以使用上边的短网址生成工具。将链接伪造一下。实测一下。百度》输入关键字》百度云盘》回车》cp长链》生成新浪短网址

DVWA之跨站请求伪造(CSRF)-LMLPHP

访问新浪短网址,这个短链的效果和长链是一样的。

这样的话,就很难定位是哪个假链接修改了密码。

medium级别

在这个级别中检查了保留变量HTTP_REFERER(来源地址)中是否包含SERVER_NAME(包括HOST参数和访问的主机名)。

我抓了一下此级别下正常修改密码的报文和伪造的修改的密码报文做比较

正常的修改密码的数据包。

DVWA之跨站请求伪造(CSRF)-LMLPHP

伪造的修改密码的数据包。

DVWA之跨站请求伪造(CSRF)-LMLPHP

通过比较这俩个数据包,明显的referer不一样,Cookie信息也一样,由此可见,如果不检查referer这个信息,就会被当成合法的操作。

int eregi(string pattern, string string)

大家首先了解一下这个PHP函数,这个函数使用了匹配字符串的,如果在string这个字符中出现了字符串pattern,则返回true,否则返回false。

在这个级别中,就是通过这个函数检查cookie的。所以,我们只需要在我们的主机名中伪造这样一个字符串就可以了。

我在伪造网站上建立一个目录,并将我们伪造的网页放进去。

DVWA之跨站请求伪造(CSRF)-LMLPHP

现在我的伪造的网页地址是

www.a.com/httpwww.dvwa.comvulnerabilitiescsrf/index.html

密码被成功修改(这里就不截图了,大家可以自行测试)

High级别

在High级别中加入了Anti-CSRF token验证机制,用户每次访问一个页面,都会返回一个随机的token,向服务器提交修改密码请求需要提交token,

服务器收到请求会优先检测token,token通过才会执行修改密码。

要想在这一步中成功修改密码需要拿到用户的token,

按照正常的思路应该是,伪造一个页面,诱骗用户打开这个页面,在这个页面偷偷加载一个iframe到修改密码的页面,然后获取这个页面的token,然后执行修改密码的操作。

但其实这个涉及另一个问题,iframe属于跨域操作,所以这个页面没有权限获取iframe框架中的token。除非是iframe中主动发送token出来。

这种情况下只能使用别的方法了,查看其它页面的是否存在XSS注入,通过注入的XSS恶意代码,获取token之后再执行修改密码的操作(XSRF攻击)

impossible级别

修改密码需要提供原密码,在不知道原密码的情况下就放弃吧。

05-11 10:57