[原创][AI分析Web漏洞] 掰开揉碎讲解 CyberGame 难度Hard 477 分 — Web Cache Poisoning 完整 Writeup

做出来了之后，我发现不需要人类有比较高的专业知识，他可能只需要会打字，所以我突然就拔剑四顾心茫然了。AI 在嘲笑：整个武林在我面前都毫无意义，热武器面前人人平等。CTF: CyberGame 2026 (SK-CERT) | 难度: Hard | 477 分（一道题 477 分还挺高的）题目来源: ctf-world-platform-2.cybergame.sk/challenges 的 future.jsFlag: 需要你根据文档内容自行破解题目分类：Web 安全。本题属于 Web 类型 CTF，不是 PWN（二进制利用）。Web CTF 的攻击发生在 HTTP 协议层——伪造请求头、投毒缓存、利用应用逻辑漏洞；PWN CTF 的攻击发生在内存层——缓冲区溢出、ROP 链、堆利用。本题的攻击手段（HTTP 头注入 + 缓存投毒 + XSS）全部在 Web 应用层面完成，没有涉及二进制逆向或内存破坏。具体来说，本题考察的是 Web Cache Poisoning（Web 缓存投毒）+ XSS（跨站脚本攻击）的组合利用。这道题的完整分析过程是由 AI（OpenCode + 大语言模型）主导完成的，人类只提供了初始提示词和少量方向性回复。就这么多。没有告诉 AI 用什么攻击技术、没有暗示漏洞类型、没有给任何解题方向。这确实是一道很难的题。整个分析过程断断续续持续了一天半，AI 很多次陷入僵局——试了十几种方法全部失败后，会说"我没有灵感了，你能给我一些提示或方向吗？"。人类的回复始终是：我没啥想法，你自己探索。然后 AI 就换一个角度继续尝试。比如投毒 / 路径发现没缓存，换成 /_next/ 路径；RSC: 1 被 Vary 挡住，试了 HTTP 走私、路径注入等各种绕过方式全部失败后，最终去啃 node_modules 里的压缩代码，才找到 base-server.js 和 app-render.js 对 RSC 头判断不一致的关键突破。后面 Host 不匹配、AE 不匹配、Docker 无外网——每个坑都是 AI 自己撞墙、自己排查、自己解决的。AI 在完全自主的情况下完成了以下全部工作：最终，人类让 AI 把整个分析过程写成了你正在阅读的这份 writeup 文档，期间经过多轮人工调优，将知识掰开揉碎的讲解。破解证明： 在讲这道题之前，先理解几个概念。如果你已经懂了可以跳过。当你用浏览器访问一个网站时，浏览器会发送一个 HTTP 请求。比如访问 2b8K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4x3V1k6H3j5h3N6W2：XSS（Cross-Site Scripting，跨站脚本攻击）是让网页执行攻击者注入的 JavaScript 代码。关于"跨站"这个名称的误解：XSS 的英文原名 Cross-Site Scripting 容易造成歧义，让人以为攻击是"从一个网站攻击另一个网站"。但实际上，XSS 攻击发生在同一个网站内部——攻击者把恶意 JavaScript 注入到目标网站的页面中。当受害者用浏览器访问这个页面时，恶意代码在受害者的浏览器里执行，而且浏览器认为这段代码来自目标网站（因为它确实是目标网站返回的页面内容）。也就是说，XSS 的本质是同源攻击：恶意脚本和目标网站是同一个"源"（same-origin），所以浏览器赋予它完整的权限——能读取该网站的 Cookie、能操作该页面的 DOM、能以该网站的身份发送请求。"跨站"这个名字，指的是攻击者想要达到的效果（把数据从目标网站"跨"到攻击者手里），而不是说脚本运行在不同的网站上。正常情况下，网页内容是服务器控制的，用户无法往里插入代码。但如果服务器把关不严，攻击者可以构造恶意输入，让页面包含 <script>alert(1)</script> 这样的标签，浏览器会执行它。一旦 XSS 在受害者的浏览器里执行，这段 JavaScript 就拥有该网站的全部权限，可以做以下事情：你可能会有疑问：浏览器不是有跨域限制吗？从一个域名（比如 http://proxy:4000）发请求到另一个域名（比如 624K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6W2N6X3W2D9i4K6u0W2j5$3!0E0），不是会被浏览器拦截吗？这里有一个常见的误解需要澄清。浏览器的同源策略（Same-Origin Policy）确实有跨域限制，但这个限制是单向的：它禁止的是 JavaScript 读取跨域请求的响应内容，但不禁止发送跨域请求本身。换句话说：更简单的窃取方式甚至不需要 fetch，只需要一行代码：浏览器加载图片天然就是跨域的，没有任何限制。攻击者的服务器只要记录下请求中的参数就拿到 Cookie 了。所以跨域限制无法阻止 XSS 窃取数据。Cookie 是浏览器在本地存储的键值对数据。你可以把它理解为浏览器为每个域名维护的一个"小字典"。Cookie 是怎么写入的：服务器在 HTTP 响应中通过 Set-Cookie 响应头告诉浏览器"请存储这个 Cookie"：浏览器收到后，把这些键值对保存到本地存储中。注意一个响应可以设置多个 Cookie，每个 Set-Cookie 头设置一个。Cookie 是怎么发送的：之后浏览器每次请求同一域名下的任何 URL，都会自动在请求头中带上该域名下所有匹配的 Cookie（不需要 JavaScript 介入，浏览器自动完成）：这里的机制是：浏览器内部维护了一个"Cookie 存储"，按域名和路径组织。每次发请求时，浏览器自动查表，把匹配的 Cookie 全部塞进 Cookie 请求头。JavaScript 不需要（也不应该）手动添加 Cookie 到请求中——浏览器全自动处理。Cookie 的属性：每个 Cookie 除了 name=value，还有一些属性控制其行为。这些属性在 Set-Cookie 头中指定，格式为分号分隔的键值对：常见的属性包括：Path 属性详解：Path 决定了 Cookie 在哪些 URL 路径下会被浏览器自动附带。比如设置了 Path=/admin 的 Cookie，只有在浏览器访问 /admin、/admin/users、/admin/settings 等路径时才会被发送，访问 / 或 /about 时不会发送。这道题中 Path=/（根路径），意味着访问该域名下的所有 URL 都会带上这个 Cookie。如果同一个域名下有两个同名的 Cookie 但 Path 不同（比如 flag=x; Path=/ 和 flag=y; Path=/admin），浏览器会都存储。访问 /admin 时两个 Cookie 都会被发送（因为 /admin 同时匹配 / 和 /admin），访问 / 时只发送 Path=/ 的那个。浏览器按 Path 的具体程度排序——更具体的 Path（如 /admin）优先级更高，但两个 Cookie 都存在，不会互相覆盖。实际开发中应避免同名 Cookie + 不同 Path，这容易造成

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-291104.htm

谢谢分享

欲买桂花同载酒 终不似 少年游

欲买桂花同载酒 终不似 少年游

看看

感谢分享。。。