DVWA之CSRF

时间 2019-11-17

标签 dvwa csrf 栏目系统安全繁體版

原文原文链接

CSRF：跨站请求伪造攻击

Security：Low 级别分析javascript

核心代码html

输入数据，以便Burp代理得到请求参数java

这里能够将第一行拿出来进行构造连接，浏览器

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

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

当用户触发这个请求后，函数

密码就会被修改为111，固然，这样子用户能看到的话，用户就知道了本身的密码被修改，明显很不现实。那么如何在用户不知情的状况下进行修改密码的攻击呢？ui

咱们能够采起构造攻击页面的方式：spa

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

没有公网服务器的状况下，能够在本地环境假设这个攻击页面的服务器，这里采用Kali做为这个攻击页面的服务器。

启动Apache服务

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

当用户退出后，下次再登陆的时候就会发现已经没法登陆了。由于此时密码已经被修改了。

Security：Medium级别分析

核心代码:

相关函数说明

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的后面

预览能够看到，密码已经在用户不知情的状况下被修改

方法二：

将攻击页面名称改成用户主机名202.100.10.129.html （攻击页面放在攻击者本身的服务器里，202.100.10.130/202.100.10.129html），当用户不当心点到这个页面时，会自动执行如下脚本，用途就是更改密码。

用户通常看到404就会关掉，固然地址是能够换成比较隐蔽的形式。

Burpsuite截到的包

Security：High级别分析

核心代码

能够看到，该级别加入了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 onload="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服务器上的攻击脚本，这怎么能够，吃着本身碗里的还想吃别人碗里的，浏览器不容许这种行为，除非别人主动从他碗里给你夹肉过来。。。。。

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

Security：Impossible级别

核心代码：

能够看到， Impossible 级别的代码利用PDO 技术防护SQL 注入，至于防御CSRF ，则要求用户输入原始密码（简单粗暴），攻击者在不知道原始密码的状况下，不管如何都没法进行CSRF 攻击。

注意：CSRF最关键的是利用受害者的cookie向服务器发送伪造请求，因此若是受害者以前用Chrome浏览器登陆的这个系统，而用搜狗浏览器点击这个连接，攻击是不会触发的，由于搜狗浏览器并不能利用Chrome浏览器的cookie。