绕过Uber的CSP防御实现XSS攻击的技术分析<\/h1>

漏洞背景<\/h2>
本案例研究了一个在Uber合作伙伴子域(partners.uber.com)上发现的XSS漏洞，攻击者成功绕过了严格的内容安全策略(CSP)防御机制。<\/p>

初始发现<\/h2>

开放重定向的起点<\/h3>

最初发现的可疑URL：https:\/\/partners.uber.com\/carrier-discounts\/att\/redirect?href=http:\/\/www.wireless.att.com\/<\/code><\/li>
确认存在开放重定向漏洞，但Uber不认为这是严重问题<\/li>

一周后该漏洞被修复，重定向功能被限制到固定目标<\/li>
<\/ul>
邀请链接分析<\/h3>

Uber常见邀请链接格式：https:\/\/www.uber.com\/a\/join?exp_hvp=1&invite_code=bq6ew1w9ue<\/code><\/li>
合作伙伴域上的类似链接：https:\/\/partners.uber.com\/p3\/referrals\/ms?i=bq6ew1w9ue<\/code><\/li>
通过Google dork发现带额外参数的变体：https:\/\/partners.uber.com\/p3\/referrals\/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1<\/code><\/li>
<\/ul>
XSS注入尝试<\/h2>
参数测试<\/h3>

测试"v"参数（表示司机工作年限）的XSS可能性<\/li>
注入payload："><\/code><\/li>
结果：payload未被过滤但未执行，因为有CSP保护<\/li>
<\/ul>
CSP分析<\/h3>
Uber的CSP策略关键部分（script-src部分）：<\/p>
script-src 'self' 'unsafe-inline' 'nonce-9f4b94bf-a195-4d8c-b474-879ae6d1d471' 
'self' 'unsafe-inline' 
https:\/\/pullo.uberinternal.com 
https:\/\/apis.google.com 
https:\/\/www.google.com 
https:\/\/d1a3f4spazzrp4.cloudfront.net 
https:\/\/*.uber.com 
https:\/\/rules.quantcount.com 
https:\/\/www.google-analytics.com 
https:\/\/ssl.google-analytics.com 
https:\/\/d3i4yxtzktqr9n.cloudfront.net 
https:\/\/d1a3f4spazzrp4.cloudfront.net;
<\/code><\/pre>
CSP绕过技术<\/h2>
关键发现<\/h3>

CSP白名单中包含https:\/\/*.uber.com<\/code>，这意味着任何uber.com子域都被信任<\/li>
发现mkto.uber.com<\/code>子域（Marketo营销自动化平台）<\/li>
该子域重定向到https:\/\/app-ab19.marketo.com\/index.php<\/code><\/li>
<\/ul>
利用方法<\/h3>
构造包含回调函数的JSONP端点：<\/p>
https:\/\/partners.uber.com\/p3\/referrals\/ms?i=bq6ew1w9ue&m=ANNIVERSARY&v=1"><script src="https:\/\/mkto.uber.com\/index.php\/form\/getKnownLead?callback=alert(document.domain);"><\/script>
<\/code><\/pre>
漏洞利用链<\/h2>

发现未过滤的HTML注入点（v参数）<\/li>
分析CSP策略，识别白名单中的潜在危险域<\/li>
找到白名单域中可接受回调函数的JSONP端点<\/li>
构造恶意脚本引用，通过回调函数执行任意代码<\/li>
<\/ol>
时间线<\/h2>

2018.8.3 提交漏洞报告<\/li>
2018.8.7 状态改为"Triaged"<\/li>
2018.8.27 漏洞修复<\/li>
2018.8.30 获得$2,000奖励<\/li>
<\/ul>
经验总结<\/h2>


常见URL也可能存在漏洞<\/strong>：不要因为URL看起来很常见或官方就假设它安全<\/p>
<\/li>

研究他人技术文章<\/strong>：参考其他研究人员的成果（如"DOM XSS - auth.uber.com"博客）可以提供绕过思路<\/p>
<\/li>

持续探索<\/strong>：当一条路被堵死时，尝试其他方法（从开放重定向转向XSS）<\/p>
<\/li>

CSP绕过技巧<\/strong>：<\/p>

仔细分析CSP白名单<\/li>
寻找白名单域中的JSONP端点<\/li>
利用回调函数执行恶意代码<\/li>
<\/ul>
<\/li>

工具使用<\/strong>：<\/p>

Google dorking发现隐藏参数和端点<\/li>
Virustotal用于发现子域信息<\/li>
<\/ul>
<\/li>
<\/ol>
防御建议<\/h2>

避免使用过于宽泛的CSP白名单（如*.domain.com<\/code>）<\/li>
对所有用户输入进行严格的输出编码<\/li>
禁用不必要的JSONP端点或实施严格的来源验证<\/li>
定期审计第三方集成和子域的安全性<\/li>
实施子域隔离策略，限制各子域间的权限<\/li>
<\/ol>

绕过Uber的CSP防御实现XSS攻击的技术分析<\/h1>

漏洞背景<\/h2> 本案例研究了一个在Uber合作伙伴子域(partners.uber.com)上发现的XSS漏洞，攻击者成功绕过了严格的内容安全策略(CSP)防御机制。<\/p>

初始发现<\/h2>

XSS注入尝试<\/h2>

CSP绕过技术<\/h2>

漏洞背景<\/h2>
本案例研究了一个在Uber合作伙伴子域(partners.uber.com)上发现的XSS漏洞，攻击者成功绕过了严格的内容安全策略(CSP)防御机制。<\/p>