diff --git a/data.json b/data.json index 9ef9d2e5..70552b32 100644 --- a/data.json +++ b/data.json @@ -21440,5 +21440,6 @@ "https://mp.weixin.qq.com/s/rqb5G7wrtgdmwCAvbIvqKA": "CVE-2026-25860 - OpenClinic GA 反射型 XSS 漏洞导致远程代码执行", "https://mp.weixin.qq.com/s/3uepeUGGnQMGIHTggkhw6w": "CISA警告:思科统一配置管理(Cisco Unified CM)漏洞已被攻击者利用", "https://mp.weixin.qq.com/s/nKWR5Sypju9tNsac5zPGgw": "GeoLocate CVE-2025-52465 - GeoServer漏洞利用", - "https://mp.weixin.qq.com/s/I0klN0JtPqeTGVs1zJd9Sg": "AI 生成 | Gogs CVE-2026-52813:从组织名路径穿越到 RCE 的复现全记录" + "https://mp.weixin.qq.com/s/I0klN0JtPqeTGVs1zJd9Sg": "AI 生成 | Gogs CVE-2026-52813:从组织名路径穿越到 RCE 的复现全记录", + "https://mp.weixin.qq.com/s/p6rGDIcUDb56xsw3-a9tfw": "挖洞思路|CORS配置漏洞背后的信任陷阱,赏金猎人如何靠逻辑链破防?" } \ No newline at end of file diff --git a/doc/2026-06/挖洞思路|CORS配置漏洞背后的信任陷阱,赏金猎人如何靠逻辑链破防?.md b/doc/2026-06/挖洞思路|CORS配置漏洞背后的信任陷阱,赏金猎人如何靠逻辑链破防?.md new file mode 100644 index 00000000..e88d3a05 --- /dev/null +++ b/doc/2026-06/挖洞思路|CORS配置漏洞背后的信任陷阱,赏金猎人如何靠逻辑链破防?.md @@ -0,0 +1,114 @@ +# 挖洞思路|CORS配置漏洞背后的信任陷阱,赏金猎人如何靠逻辑链破防? +原创 升斗安全XiuXiu + 升斗安全XiuXiu 升斗安全 2026-06-26 17:40 + +**【文章说明】** +- **目的** +:本文内容仅为网络安全**技术研究与教育** +目的而创作。 + +- **红线** +:严禁将本文知识用于任何**未授权** +的非法活动。使用者必须遵守《网络安全法》等相关法律。 + +- **责任** +:任何对本文技术的滥用所引发的**后果自负** +,与本公众号及作者无关。 + +- **免责** +:内容仅供参考,作者不对其准确性、完整性作任何担保。 + +**阅读即代表您同意以上条款。** + +**** +各位老铁,今天咱们聊一个在挖洞时很容易被忽略,但杀伤力极强的逻辑链: +CORS配置的“信任陷阱”。很多人以为只要把 +允许的源写对了就算完事,但实际上,这种信任关系恰恰是击穿整个防线的突破口。下面我把它拆成两个实战中常见的场景,思路保证通俗连贯,一看就懂。 + +![](https://mmbiz.qpic.cn/mmbiz_png/qg1MKHx3jGGWtA9QxM2PiaO2Zcp9z4MFI3sNwWaiaP7F5kLH7MHKoTtbMFTWh2ZXCHSjXiaD8KlhKiaKZuKqvuv1OsMqnxkO2TXY8L1KwlmWgFc/640?wx_fmt=png&from=appmsg "") + +一、被信任的“队友”背后捅刀 + +即使 +CORS配置得看似滴水不漏,它本质上也是在两个源之间签下了一纸“兄弟协议”。问题在于,你信任的那个兄弟,自己家里可能门户大开。 + +打个比方:主站放心地把资源访问权开放给子域名,结果这个子域名偏偏存在一个 +反射型XSS。这时候,攻击者根本不用正面硬刚主站,只需要在这位“二五仔”身上打主意就行。 + +看下面这个请求,主站收到来自受信子域名的跨域调用: +``` +GET /api/requestApiKey HTTP/1.1 +Host: vulnerable-website.com +Origin: https://subdomain.vulnerable-website.com +Cookie: sessionid=... +``` + +服务器一看是自家兄弟,大方回应: +``` +HTTP/1.1 200 OK +Access-Control-Allow-Origin: https://subdomain.vulnerable-website.com +Access-Control-Allow-Credentials: true +``` + +如果攻击者在 + subdomain.vulnerable-website.com 上找到了一处 +反射型XSS,就可以直接构造这样的链接,把恶意脚本嵌入进去: +``` +https://subdomain.vulnerable-website.com/?xss= +``` + +用这段JS,就能在受害者浏览器里,以子域名的身份向主站发起带凭证的跨域请求,再偷偷把拿到的敏感数据传走。你看,CORS本身配置没错,但一条XSS直接让这种“信任”成了单向透视玻璃——外面看不清里面,里面却看得一清二楚,任由攻击者窥探。 + +二、HTTPS的高墙,被HTTP的下水道渗透 + +![](https://mmbiz.qpic.cn/sz_mmbiz_png/qg1MKHx3jGHwFuJDTWV2fFPLXMfMk4DRicxSKkCZGcQLoicteDt86XxibQnBKk5RPCTUW9S7HiaTcPlzkpuTNWbgAKOm3WW5Duvx2dV1miar0Cibs/640?wx_fmt=png&from=appmsg "") + +再聊一个更隐蔽的情况。有些应用自己的安全做得相当严格,全站 +HTTPS,cookie加了一堆安全属性,感觉固若金汤。然而,它却悄悄把一个跑在 +明文HTTP上的子域,写进了 +CORS白名单。 + +这相当于给一座全封闭堡垒,留了一条通向菜市场的地道。攻击者只要能在双方通信的中间节点(比如同一咖啡店的Wi-Fi)作个梗,就能顺着这条地道长驱直入。 + +比如,主站处理了这样一个请求: +``` +GET /api/requestApiKey HTTP/1.1 +Host: vulnerable-website.com +Origin: http://trusted-subdomain.vulnerable-website.com +Cookie: sessionid=... +``` + +服务器依然很大方: +``` +HTTP/1.1 200 OK +Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com +Access-Control-Allow-Credentials: true +``` + +注意到了吗?源里那个赤裸裸的 http:// 就是整个链路唯一的命门。 + +对于攻击者来说,玩法就变得很灵活了:你只需蹲在受害者同网段的某个节点,拦截并篡改他去往那个HTTP子域的流量,注入恶意脚本;或者直接利用这个HTTP子域本身的弱点,伪造请求。一旦得手,就可以像场景一那样,以受信源的身份,轻松把 +主站通过TLS加密保护的机密数据窃取到手。 +TLS保护了传输通道的链路安全,却管不了信任来源那头的“脏东西”。 + +划重点: + +挖这类漏洞,眼睛不能只盯着单个点,而要看整个“ +信任网络”的构成。 +CORS白名单里的每一个源,包括它的传输协议、防护状况,都决定了整条船会不会被一块朽木凿沉。前者是信任源自身的漏洞利用,后者是信任链路的降维打击。 + +觉得有收获的老铁,动动手指 +点赞、 +在看、 +转发三连走起,别让这些藏在逻辑链里的高危漏洞从指缝溜走。还没关注的小伙伴赶紧点上 +关注,后续更多硬核实战经验,第一时间推给你!咱们下期见! + + +往期推荐: + +[别只看书了!CTF免费资源+在线靶场福利,这才是赏金猎人的训练营](https://mp.weixin.qq.com/s?__biz=MjM5MzM0MTY4OQ==&mid=2447798624&idx=1&sn=1291eb2c49b2fa9f78bdd9b6d457eade&scene=21#wechat_redirect) + + +[免费打造你的渗透测试 AI助手:Burpsuite+Ollama+本地大模型 → AI辅助分析,赏金猎人高效挖洞(脚本已打包)](https://mp.weixin.qq.com/s?__biz=MjM5MzM0MTY4OQ==&mid=2447798575&idx=1&sn=0636ff98027e96c2dbbec867b59ba8ff&scene=21#wechat_redirect) + +