从CRLF注入到XSS：评估苹果iTunes安全风险

描述

大约十八个月前，我发现了苹果iTunes中的一个重大漏洞，起源于回车换行（CRLF）问题。通过持续的努力，这一最初的发现被升级为一个跨站脚本（XSS）漏洞，展示了广泛利用的潜力。

此外，在调查的后期阶段，一位同事通过识别出位于发现CRLF的同一端点内的跨源资源共享（CORS）漏洞，进一步证实了我们发现的安全漏洞的严重性。

发现过程

一个类似于今天的星期五，当我运行我的bash脚本来收集子域和Wayback Machine的URL，并随后使用Dalfox和Nuclei等工具对它们进行分析时，我发现了一个漏洞。

尽管最初什么也没发现，但我的注意力转向了苹果的主域名（apple.com）。

在通过Burp Suite Proxy 监视流量时，我偶然发现了一个由主域用作API获取iTunes优惠数据的子域名。

这一发现是通过检查主域的源代码而引发的，我观察发现这个子域会接受某些参数。

攻击

我在iTunes.apple.com域名中确定了一个子域，在主网站的源代码中有引用。这个子域接受特定参数，成为了我的关注点。我使用Burp Suite的重放器，通过模糊测试开始检测诸如XSS和LFI之类的漏洞。当我注入%0d%0aSet-Cookie:%20attacker=exploit时取得了突破，成功将attacker=exploit cookie反射到响应页面中，这表明此处存在潜在的安全漏洞。

尽管发现了CRLF漏洞，但我遇到了一个问题，因为响应是以JSON内容类型返回的，这是我之前遇到过的一种情况，在JSON渲染的情况下，漏洞的影响力较小。

然而，经过一些研究和实验，我发现手动调整请求中的内容类型成功地绕过了这一限制，这标志着我探索中的一个重大突破。

注:

比如修改请求包的数据类型， 而不是application/json 就可能绕过 Content-Type

Content-Type: application/x-www-form-urlencoded

这种调整允许漏洞在JSON响应之外被显示出来，增强了其潜在影响力。

最终，在成功操纵内容类型后，我成功拦截并将Cookie反射回自己。

此外，由我的同事Zyead在同一端点上发现的CORS漏洞，我们能够通过第三方域捕获Cookie，展示了一个重大的安全漏洞，未经授权的实体可能利用它来获取敏感信息。

More

https://xelkomy.medium.com/from-crlf-injection-to-xss-elevating-the-stakes-in-apple-itunes-security-597dc435fd82

Thanks Khaled Mohamed work