背景说明
今天来详细介绍国外白帽如何使 DOM XSS 升级为持久的存储型 XSS。
白帽小哥一般会先打开Burp Suite Pro，然后运行Burp Browser，然后提前对H1、BugCrowd和Intigriti上的所有项目做了一些侦察，还会使用BBRF Server将这些数据保存在CouchDB上。
https://github.com/honoki/bbrf-server
侦察
侦查阶段白帽小哥喜欢保持简洁快速，通常在目标域中使用Subfinder和chaos进行探测，一旦有了目标站点的子域列表，就会配合httpx进行进一步探测。
#domains.txt has the target domain
cat domains.txt | subfinder | bbrf domain add - -s subfinder
chaos -d targetdomain.tld | bbrf domain add - -s chaos
#The bbrf command adds the data to my bbrf server.手动‘狩猎’
完成侦查后，白帽小哥比较喜欢手动‘狩猎’，方法就是访问Web应用程序，然后四处点击以了解该Web应用程序的各项功能。
在单击并查看搜索字段时，白帽小哥喜欢使用 DOM Invader 字符串，这能够测试 DOM XSS 和 RXSS。https://portswigger.net/burp/documentation/desktop/tools/dom-invader
将 DOM Invader Canary 放入 Web 应用程序搜索字段后，DOM Invader 变为了红色，每当它变红时，就是你需要进一步查看的时候了。
该应用程序运行的是Akamai WAF，所以点击Exploit按钮是没有用的，因为会被WAF阻止，并可能导致 IP 被Ban。
一旦识别了某些参数，白帽小哥就开始尝试使用简单的Payloads来查看哪些字符被编码，通常他会从一个简单的”>”开始。
再次查看DOM Invader，可以看到URL正在被解码：
“>”被传递到 InnerHTML，表示可能存在 XSS，但是当寻找网页中显示 HTML 的位置时，却看到Payload已被编码。
由于 insideHTML 没有反映在 Web 应用程序中，因此无法使用简单的测试以查看 HTML 是否正在呈现，所以在这个例子中，白帽小哥使用了一个简单的<img/src=//evil.com> ，然后通过检查 Burp 历史记录来寻找对evil.com的回调。
虽然插入了HTML代码，也可能存在XSS，然而绕过Akamai WAF是很困难的。是不是意味着要放弃了？
重回侦察
目标Web应用程序有多个子域，对应于不同的世界区域，例如：https://us.vulnerableapplication.tld 会把你带到该网站的美国版，在该子结构域中可以找到相同的代码库。
使用之前获得的侦察数据，尝试寻找了一个不受Akamai保护的子域。
内部WAF绕过
尝试了其它子域后，似乎还有一个WAF，不过这个WAF不是Akamai，绕过就容易多了。对于绕过WAF，白帽小哥喜欢找出WAF触发的确切点，并使用该点来计算将绕过触发器的不同字符。
一开始，我们知道需要利用 onerror ，因此可以从一个简单的Payload开始：
<img/src/onerror>然后试着加入一个等号：
<img/src/onerror=>Payload被阻拦！这意味着需要想办法在 r 和 = 符号之间来绕过WAF，有几个字符可以尝试，首先在中间加入一个空格：
<img/src/onerror =>同样也被阻拦了，继续添加其它字符，例如 %00，同样被 WAF 阻拦，使用 %09 (\t)：
<img/src/onerror %09=>终于奏效！一旦可以顺利到达onerror的右侧，其余部分就变得容易多了。
右侧bypass
参考左侧Payload的技巧，尝试输入右侧部分Payload：
<img src onerror %09=alert>被成功阻拦，所以只要有“alert”这个词就会被阻拦，然而，alert 是 JavaScript 中 Window 和 Top 对象上的函数，所以可以尝试使用这些小工具来进行弹窗：
<img src onerror %09=window>同样被阻拦。
<img src onerror %09=top>成功！但这似乎有点过于简单了，因为 DOM XSS 位于非常明显的位置，相信大多数赏金猎人现在已经找到了。
寻找存储型XSS
为了不被OOS漏洞吓倒，白帽小哥决定寻找一种方法将DOM XSS升级为存储型XSS，有许多输入点需要测试，首先检查基于Cookie的存储型XSS。
白帽小哥使用相同的方法使用 Burp 的 DOM Invader 来查找 DOM XSS，并将 DOM Invader Canary粘贴到浏览器中的所有 Cookie 中，当重新加载页面时，发现 DOM Invader 再次变为红色。
一个 Cookie 确实反映在了 DOM 中！这意味着可以将 DOM XSS 转换为存储 Cookie XSS，我们所需要做的就是使用 DOM XSS 向 Cookie 中注入 XSS，并在每次用户导航到该位置时执行它。
最终Payload
为了更容易地修改Payload，白帽小哥使用了Location.hash值，这可以让代码留在客户端，绕过WAF，以下是最终完整的Payload：
DOM XSS Payload：
<img/src/onerror %09=testing%3dtop['ev'+'al'];foundit=top['loca'+'tion']['hash']><img/src/onerror
=testing(decodeURI(foundit.substr(1)))>在URL中的#之后：
document.cookie='vulnerablecookie=\'><img/src/onerror %09=newpal%3dtop[\'ev\' \'al\'];newpal(atob("YWxlcnQoZG9jdW1lbnQuY29va2llKQ=="))>;expires=Sun, 10 Dec 2024 08:48:11 GMT;path=/;domain=.vulnerabledomain.tld'将该Payload传递给受害者后，他们每次访问Web应用程序上的任何页面时都会收到一个document.cookie的弹窗窗口。
经验总结
1、只有通过手动创建并计算出如何绕过WAF的Payloads，才是最有效的Payloads。这正是手动‘狩猎’和‘人工’Payloads制作的重要性。
2、由于 XSS 发生在整个站点范围内，因此可以生成一个键盘记录器的PoC，通过显示在键盘记录器中记录的用户名和密码并将其发送到攻击者控制的服务器来增加漏洞危害的影响。
https://github.com/JohnHoder/Javascript-Keylogger
3、相信很多赏金猎人已经发现了这个DOM XSS漏洞，但由于该漏洞不在赏金范围，很多赏金猎人就会在此止步，不再深入，但通过不断的努力与深入研究，有时可以将超出范围的DOM XSS和Self-XSS提升漏洞等级，从而获得赏金奖励。
4、生成一个 CSRF 令牌并发送一个POST请求，将用户名设置为 XSS，从而将 Self-XSS 转变为存储型XSS。
你学会了么？文章白帽：@rodriguezjorgex
以上内容由骨哥翻译并整理。
