mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
【登录背后的秘密-第五章】2FA 绕过漏洞详解：半登录状态的致命缺陷、干货 | HOST碰撞漏洞挖掘技巧、权限收了，功能还在漏洞、
This commit is contained in:
test committed
1 parent
320138c349
commit
77d63df347
4 files changed
+248
-1
No files matched your search
@@ -19522,5 +19522,8 @@
|
||||
"https://mp.weixin.qq.com/s/bfHI4LsGicJiSJKGVq9RrA": "【在野利用】Google Chrome Dawn 释放后重用漏洞(CVE-2026-5281)安全风险通告",
|
||||
"https://mp.weixin.qq.com/s/VdSos730ImjZLFc25x-ucQ": "【安全圈】请升级：技嘉控制中心曝 9.2 分高危漏洞，黑客可远程接管电脑",
|
||||
"https://mp.weixin.qq.com/s/44s-ls6WCYqzm36akr3wYw": "【附POC及复现环境】Vim 1-click代码执行漏洞复现 (CVE-2026-34714)",
|
||||
"https://mp.weixin.qq.com/s/Y8lidlMnLlL1uwsEUGaxzw": "Smart Slider 3 WordPress 插件任意文件读取漏洞 | CVE-2026-3098复现&研究"
|
||||
"https://mp.weixin.qq.com/s/Y8lidlMnLlL1uwsEUGaxzw": "Smart Slider 3 WordPress 插件任意文件读取漏洞 | CVE-2026-3098复现&研究",
|
||||
"https://mp.weixin.qq.com/s/336CcmNzC50-mYvAxppZGA": "【登录背后的秘密-第五章】2FA 绕过漏洞详解：半登录状态的致命缺陷",
|
||||
"https://mp.weixin.qq.com/s/LZ_9OruWH0AVSQjLVX6wZQ": "干货 | HOST碰撞漏洞挖掘技巧",
|
||||
"https://mp.weixin.qq.com/s/DrUecwWUSW-A0WTg7vWggw": "权限收了，功能还在漏洞"
|
||||
}
|
||||
@@ -0,0 +1,115 @@
|
||||
# 【登录背后的秘密-第五章】2FA 绕过漏洞详解：半登录状态的致命缺陷
|
||||
原创 升斗安全XiuXiu
|
||||
升斗安全XiuXiu 升斗安全 2026-04-01 23:55
|
||||
|
||||
**【文章说明】**
|
||||
- **目的**
|
||||
：本文内容仅为网络安全**技术研究与教育**
|
||||
目的而创作。
|
||||
|
||||
- **红线**
|
||||
：严禁将本文知识用于任何**未授权**
|
||||
的非法活动。使用者必须遵守《网络安全法》等相关法律。
|
||||
|
||||
- **责任**
|
||||
：任何对本文技术的滥用所引发的**后果自负**
|
||||
，与本公众号及作者无关。
|
||||
|
||||
- **免责**
|
||||
：内容仅供参考，作者不对其准确性、完整性作任何担保。
|
||||
|
||||
**阅读即代表您同意以上条款。**
|
||||
|
||||
****
|
||||
很多人都觉得“
|
||||
密码+验证码”就等于安全了，但今天我要告诉你一个扎心的事实：不少网站的“
|
||||
双因素认证”，其实压根没你想的那么结实。有的能被绕过，有的甚至能被直接“跳过”。这篇文章就用最白话的方式，聊聊这些漏洞到底长啥样。
|
||||
|
||||
|
||||
|
||||
咱们先来个灵魂拷问：
|
||||
|
||||
你有没有遇到过这种情况——登录一个网站，输完密码，然后跳到一个新页面让你填短信验证码。
|
||||
|
||||
这时候，如果你不填验证码，而是直接在地址栏里敲一个“个人中心”的链接，会怎么样？
|
||||
|
||||
我告诉你，在有些网站上，你会发现——
|
||||
进去了。
|
||||
|
||||
是不是有点细思极恐？
|
||||
|
||||
这就是今天要聊的核心：很多所谓的“双因素认证”，看着像加了把锁，实际上只是挂了个牌子说“此处有锁”，攻击者稍微绕个路，门就自己开了。
|
||||
|
||||
第一步：先搞明白什么是“真·双因素”
|
||||
|
||||
双因素认证，说白了就是两道关：
|
||||
|
||||
第一关：你知道什么（比如密码）
|
||||
|
||||
第二关：你有什么（比如手机、U盾）
|
||||
|
||||
这两关必须是不同种类的。如果第二关还是“你知道什么”，那就等于换汤不换药。
|
||||
|
||||
举个反面教材：有些网站让你输完密码之后，往你邮箱发个验证码。
|
||||
|
||||
你想想，登录邮箱靠什么？还是密码。
|
||||
|
||||
所以这根本不是“双因素”，这是“同一因素验证了两遍”，相当于把同一个锁锁了两下——黑客只要开一次锁，两道门全废。
|
||||
|
||||
那为什么短信验证码也不一定靠谱？
|
||||
|
||||
短信验证码看着挺美——毕竟手机是我的，码发到我手机上，总该没问题了吧？
|
||||
|
||||
理论上是的，但现实中有两种常见的“翻车方式”：
|
||||
|
||||
验证码被截胡
|
||||
|
||||
如果你连的是公共Wi-Fi，或者手机被植入了恶意软件，短信在传输过程中就有可能被“半路截走”。
|
||||
|
||||
|
||||
|
||||
不是说天天都会发生，但确实有这个风险。
|
||||
|
||||
更骚的操作：SIM卡被“偷”了
|
||||
|
||||
你没看错，不是偷你手机，是偷你的手机号。
|
||||
|
||||
攻击者可以假装是你，去运营商那里补办一张新SIM卡。一旦成功，你的手机号就归他了，所有发给你手机的短信——包括验证码——都会发到他那里。
|
||||
|
||||
而你这边，手机突然没信号，还以为只是欠费了。
|
||||
|
||||
再来说说“跳过验证码”这件事
|
||||
|
||||
回到开头那个例子。
|
||||
|
||||
很多网站的登录流程是这样的：
|
||||
|
||||
第一步：输密码
|
||||
|
||||
第二步：跳到一个新页面，让你输验证码
|
||||
|
||||
但关键是，在你输完密码的那一刻，网站其实已经给你生成了一个“半登录状态”。
|
||||
|
||||
只不过页面上拦着你，不让你点进去。
|
||||
|
||||
那如果这时候，攻击者在浏览器里直接输入一个“只有登录后才能看”的页面地址——比如后台管理、账户设置——会发生什么？
|
||||
|
||||
在一些实现不严谨的网站上，你会发现：页面正常打开了。
|
||||
|
||||
这就相当于你家的门明明有两道锁，结果第一道锁一拧开，第二道锁自动失效了。
|
||||
|
||||
黑客根本不需要去破解验证码，直接绕路进门。
|
||||
|
||||
多因素认证不是不能用，而是不能只看“有没有”，要看“怎么实现的”。
|
||||
|
||||
真正安全的设计，是那种“少一步都不行”的类型——哪怕你输对了密码，只要没完成第二道验证，就哪儿都去不了。
|
||||
|
||||
而那些流程上有漏洞的，哪怕又是短信又是扫码又是问题，关键时刻一样可能被轻松绕过。
|
||||
|
||||
觉得今天的内容对你有一些帮助？点个
|
||||
赞 或者
|
||||
在看，就是对我最大的鼓励。
|
||||
|
||||
关注我，更多网络安全知识，咱们一起从脚本小子做起~
|
||||
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
# 干货 | HOST碰撞漏洞挖掘技巧
|
||||
HACK学习君
|
||||
HACK学习君 HACK之道 2026-04-02 00:45
|
||||
|
||||
**文章来源：转载来源语雀文档，非**
|
||||
**P喵呜****作者本人投稿。****如有侵权，请联系删除**
|
||||
|
||||
**0x01 前言**
|
||||
|
||||
****在实战中,我们总会对一个企业进行资产收集,在这个过程中会收集到许多资产,有域名有 ip但有的时候打开的域名指向的是一个内网 ip 非常无奈 :(而打开的 ip 状态码更是直接显示 400,403,404 禁止我们访问还有一种状态码显示 200 但是输入啥都没啥变化的同时对它们进行目录扫描,也是常常没有结果那么这种情况下, HOST 碰撞技术就可以尝试使用了
|
||||
|
||||
**0x02 host 碰撞原理**
|
||||
|
||||
****当数据包的 host 头替换为某个域名时在访问该反代服务器的 ip, 如果 nginx/Apache 的反向代理的 host 配置没删除,就会把请求转发到内网对应的 host 业务服务器上, 接着返回该业务的信息, 实现本该隐藏的业务访问
|
||||
|
||||
简单点就是: 当数据包的 host 头替换为某个域名时在访问时该反代服务器的 ip, 如果页面发生了变化,返回了对应的资源, 即可判断为存在 host 碰撞
|
||||
|
||||
**0x03 host 碰撞什么时候存在?**
|
||||
|
||||
****1业务通过 DNS 解析到外网，后面删除了 A 记录(但是 nginx/Apache 的反向代理还没删除)2测试业务(不对外开放的业务,只流传于开发或是测试使用)
|
||||
|
||||
**0x04 什么样的 ip 能进行 host 碰撞?**
|
||||
|
||||
****这里我看网上很多人写文章都是写 ip 状态码为 40X 的时候,在进行 host 碰撞但是我想说,这不一定正确!!!实际上,我认为应该改为任何一个 ip 都有 host 碰撞的价值!!!这个点的问题在于,现在很多较大的公司比较流行,资产统一把控,也就是自己所有的资产全部收缩进内网然后整个 nginx 或是 Apache 服务器,想对外网开放某个资产的时候就通过这个反代服务器新添加个配置映射出去这就导致了一个问题, 那就是如果配置不当了, 忘记删除这台 nginx 或是 Apache 服务器的域名指向了那么我们通过修改 host 就可以重新访问这些以前在外网后面被收缩进内网的资产了
|
||||
```
|
||||
```
|
||||
|
||||
这种情况, 我对大公司进行测试时, 已经发现不下于三次因此我认为只要是个 ip 能够访问,那么它就有进行 host 碰撞的价值当然这个是我自己个人实战经验,读者们看个乐乎就好了 :)
|
||||
|
||||
**0x05 host 碰撞检测方法-思路**
|
||||
|
||||
****网上大佬是遇到 40X,或是收集到了内网域名在进行 host 碰撞这里我的检测方法对比网上那些大佬的比较泛~~
|
||||
```
|
||||
```
|
||||
|
||||
**0x06 host 碰撞检测方法-实际**
|
||||
|
||||
****测试方法的话,我这里提供两种比较高效的测试方法
|
||||
|
||||
**0x06.1 测试数据**
|
||||
```
|
||||
```
|
||||
|
||||
**0x06.2 方法一 - 使用工具 HostCollision**
|
||||
```
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**0x06.3 方法二 - 使用 burp**但是这个方法,只能一个 ip 一个 ip 的测试,无法批量 host 爆破第一步: 找一个你认为有漏洞 ip 我拿的测试数据的 42.xxx.xxx.xxx第二步: 将找到的 host 保存成一个 hostList.txt 分别填写进对应的数据(一行一个)第三步: 构造数据包如下图
|
||||
|
||||
有了这个包以后,发送到测试器里面进行 host 爆破
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**0x06.4 浏览器访问的方法**
|
||||
|
||||
|
||||
**0x06.4.1 方法一 - 系统 hosts 文件修改**这里就教如何利用 windows 访问对应的站点
|
||||
```
|
||||
```
|
||||
|
||||
打开文件: C:\Windows\System32\Drivers\etc\hosts
|
||||
|
||||
|
||||
**0x06.4.1 方法二 - 使用 burp**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
如果还看不明白,这里也有中文版的可以看一眼
|
||||
|
||||
|
||||
|
||||
|
||||
**0x07 总结**
|
||||
|
||||
```
|
||||
```
|
||||
|
||||
要是前面的文章还看不是很懂的话,可以看看这张网站访问流程的图会更加清晰
|
||||
|
||||
|
||||
|
||||
多试试总会成功的 :)
|
||||
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
# 权限收了，功能还在漏洞
|
||||
原创 游山玩水
|
||||
游山玩水 山水SRC 2026-04-02 00:48
|
||||
|
||||
## 免责声明
|
||||
|
||||
**本公众号分享的所有渗透测试技术文章仅面向合法授权的安全测试、学习交流与研究用途。读者必须确保自身行为符合《网络安全法》等相关法律法规，严禁将其用于任何未授权攻击等非法活动。因不当使用或传播相关内容所引发的任何法律责任与风险，由行为人自行承担，本公众号（或本人）概不负责**
|
||||
|
||||
## 流程
|
||||
|
||||
1.用户A给用户B高权限
|
||||
|
||||
2.用户A取消用户B权限
|
||||
|
||||
3.用户B不刷新页面就不会失去高权限，仍然能在该页面进行高权操作
|
||||
|
||||
|
||||
|
||||
当管理员（用户A）取消用户B的高权限后，后端数据库已更新。但用户B的浏览器页面未刷新，其前端JS代码中缓存的仍是旧的“高权限”状态，因此仍能看到并触发高权限操作按钮。**关键在于，如果后端API在响应用户B后续的操作请求时，没有严格校验其最新权限，而仅信任了前端传递的令牌或会话中过期的权限信息，攻击就成功了。**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user