文章目录

    • 通配符+URL解析器混淆攻击实现ChatGPT账户接管
    • 通配符+URL解析器混淆攻击实现Glassdoor服务器缓存XSS

本文不承担任何由于传播、利用本文所发布内容而造成的任何后果及法律责任。

本文将基于ChatGPT及Glassdoor两个实例阐发URL解析器混淆攻击。

开始本文前，推荐阅读：【网络安全】Web缓存欺骗攻击原理及攻防实战

通配符+URL解析器混淆攻击实现ChatGPT账户接管

ChatGPT新增了”分享”功能，该功能允许用户与其他人公开分享聊天内容：

ChatGPT会生成一个对话链接，用户复制后发送给好友即可：

然而，存在一现象：ice发送对话链接给A后，A看到了对话内容。ice再与ChatGPT对话，此时A访问对话链接，却看不到新的对话内容。

这个现象可能意味着：原先的对话内容已被缓存，其在缓存条目消失前并不会更新。

对该猜测进行验证：打开网络标签页来检查响应头，看到Cf-Cache-Status: HIT，说明请求的资源在Cloudflare的CDN缓存中已经存在。

通常，只有静态文件（如图片、CSS、JS文件等）会被CDN缓存，但在这个情况中，一个动态内容的生成（即ChatGPT的对话分享）也被缓存，这反映出Cloudflare的缓存机制并不仅限于传统意义上的静态文件，而是可以根据配置规则对各种类型的内容进行缓存。

同时可以看到对话链接URL中并不存在文件扩展名：

这意味着在处理缓存时，使用的规则并不是基于请求的资源文件的扩展名（如.jpg、.html、.css等）来决定是否对该资源进行缓存。相反，它是根据URL中资源所在的路径位置来决定的。

综上，ChatGPT的缓存规则配置为/share/*，表示所有位于/share/路径下的内容都会被CDN缓存，不管这些内容是什么类型的文件或者是否根本就不是文件（例如动态生成的内容）。

在实施攻击实现ChatGPT账户接管前，先了解一下什么是URL解析器混淆攻击。

由于历史原因和标准实现的差异，不同的解析器对某些特殊字符或编码方式的处理可能会有所不同。使用缓存的网站中，请求必须先经过CDN，然后才到达Web服务器。如果这两者的解析器处理不一致，利用这些差异，通过精心设计的URL来迷惑解析器，使其误解URL的真正意图，即可实现URL解析器混淆攻击。

在此案例中，Cloudflare的CDN并不会对URL进行解码，也并不会规范化URL路径，但Web解析器却会。

当构造https://chat.openai.com/share/%2F..%2Fapi/auth/session" />通配符+URL解析器混淆攻击实现Glassdoor服务器缓存XSS

Glassdoor是一个面向职业人士的在线平台，旨在提供有关公司、工作岗位、薪资、面试经验和员工评价的信息。[以下附图环境为已修复环境]

其Job页面提供了有关职位的详细信息：

在 https://www.glassdoor.com/Job/" />

optimizelyEndUserId cookie的值会在页面中反映，位于URL参数之后。故可将负载分割为两部分，通过绕过WAF来执行任意JavaScript，然而这只是个反射型XSS。

要实现危害扩大，可以考虑服务器缓存XSS。

在https://www.glassdoor.com/Job和https://www.glassdoor.com/Award/下的页面中打开网络标签页来检查响应头，后者看到Cf-Cache-Status: HIT，说明页面被缓存。

经测试，发现通配符 /…/在缓存服务器上得到规范化，但后端Web应用程序没有规范化。故对于路径https://www.glassdoor.com/Job/../Award/blah?xss=，缓存服务器将其解释为https://www.glassdoor.com/Award/blah?xss=，导致响应被缓存。该过程与上一个案例相似，不再详述。

在后续中，任意用户访问https://www.glassdoor.com/Award/blah?xss=时，XSS将被触发。

经测试，也可在https://www.glassdoor.com/mz-survey/interview/collectQuestions_input.htm/../../../Award/blah的请求包标头和 cookie 中包含 XSS：