隔离结束后，我经历了一个多月的迷你倦怠，我什至懒得去尝试寻找错误。经过一个半月的尝试再次找到我的动力后，我发现了一个XSS，它比典型的XSS 需要更多的思考 javascript:alert(1) 案例。
重新审视我在BB 程序中的旧笔记，我观察到了我上次尝试利用的一个端点，然后我才经历了那种倦怠。当时我无法利用它，所以现在我想给它第二次机会。终点是 https://example.com/dir/legacy-browser?redir=/。有一个按钮，您可以在其中重定向到参数redir 指向的端点。分析源代码，我可以看到该网站以这种方式重定向用户：
起初，我认为这应该很容易。我尝试通过注入来转义括号 ') 在里面 redir 范围。结果是非法字符被删除。实际上，如果有任何非法字符，应用程序会默认将您重定向到 /。
我试图注入一个空字节 %00，只是为了看看应用程序会如何反应。应用程序将空字节转换为 NULL。所以有效载荷 redir=/%00/ 将反映到源代码中 javascript:redirect('/NULL/')。我想“太好了，url 编码的字符正在被解码”。我点击了按钮……我被重定向到 /NULL/。此外，任何其他非法url 编码字符都将被删除，正如我之前所述。
所以，显然，URL 正在被解码并发送到 javascript:redirect()。但我想注入一些非法字符来转义括号。经过一番思考，我得出的结论是，为了发送非法字符到 javascript:redirect()，这些字符在从URL 栏中解码后必须进行URL 编码。因此需要双重URL 编码！
我发送了第二个有效负载 https://www.example.com/dir/legacy-browser?redir=/%2500/test， 在哪里 %2500 是双URL 编码的空字节。结果是为了 javascript:redirect('/%00/test') 得到反映。点击按钮后，我被重定向到 https://example.com/，这意味着空字节 javascript:redirect() 实际上正在被解码。所以我实际上可以发送工作双URL 编码的有效负载。
考虑到这一点，我为这个端点制作了一个有效负载（通过制作，我的意思是从 野蛮逻辑 在 有效负载AllTheThings 并添加一个 ') 在前）。我对它进行了双重URL 编码并将其注入到参数中。点击按钮后，XSS 就在用户被重定向到之前被触发 /。
最终利用： https://example.com/enpoint?redir=/%2527)%253B%2520alert(document.cookies)%253B%252F%252F