探索权限提示中的源显示操纵
是安全漏洞还是有意设计选择？
自2025年以来，我一直在深入研究浏览器安全，最近观察到现代浏览器在显示权限提示时存在配置错误——当顶级站点通过iframe委托访问时，浏览器显示的是顶级源而非实际请求源。我将这种现象称为"权限提示中的源显示操纵"。这一观察引发了一个关键问题：这种行为是否应被视为安全漏洞。
问题所在
在多个现代浏览器中，权限提示显示的是顶级源，而不是来自第三方iframe的实际请求源。这种设计决策意味着，如果攻击者通过HTML注入或XSS漏洞注入iframe，浏览器提示会误导性地显示受信任站点正在请求权限——即使实际上是恶意域名在发出请求。因此，麦克风、摄像头或地理位置等敏感权限可能被授予攻击者控制的域名。
利用场景
假设攻击者控制一个恶意域名（例如attacker.com）。通过利用受信任网站（比如target.xyz）上的HTML注入或XSS漏洞，攻击者可以注入请求权限的iframe。通用payload可能如下所示：
|
|
当用户访问该网站时，这些iframe会静默加载。虽然实际的权限请求来自attacker.com，但浏览器的提示显示的是顶级站点（如target.xyz）作为请求者。如果用户点击"允许"，恶意内容将获得权限访问权——但仅限于该内容仍被受信任站点框架包裹期间。
（浏览器提示显示受害网站是请求权限的一方）
（浏览器授权攻击者控制的域名访问摄像头、位置和麦克风）
行业响应：主流浏览器的立场
Chrome的观点
Chrome的文档确认，在权限提示中显示顶级源是有意的设计决策。其理由是通过一致显示用户正在交互的站点来减少用户混淆。
Firefox的观点
Firefox遵循Permissions-Policy规范，正确显示被授予权限的源。正如他们在错误报告（bug 1945848）中解释的那样，Firefox的方法与其他主流浏览器一致，以确保清晰度并防止出现欺骗性广告中的误导提示。
Apple（Safari）的观点
Apple已审查此问题并确认Safari的行为符合设计。根据他们的回应，权限提示中显示的URL准确反映了哪个站点正在请求访问，确认观察到的行为是有意的。值得注意的是，尽管利用场景可能看起来令人担忧，但该攻击不会授予"持久"访问权——权限仅在框架内容显示期间处于活动状态。
通过Permission-Policy头进行缓解
一个常见的建议是，正确配置的Permission-Policy头可能通过限制哪些域名可以请求某些权限来缓解此问题。例如，如果站点使用仅授予自身源（即’self’）权限的头，则注入的第三方iframe将被阻止接收这些权限。
然而，重要的是要注意，虽然Chrome支持Permission-Policy头并可以强制执行此类限制，但Firefox和Safari目前不支持该头。这意味着，在不支持该头的浏览器中，误导性权限提示的可能性仍然存在。
这是安全漏洞吗？辩论分析
支持方观点：
- UI欺骗：注入漏洞让攻击者能够显示提示，展示受信任站点，欺骗用户授予权限
- 风险放大：受损的顶级站点可能无意中将权限委托给恶意内容
- 安全削弱：误导性提示可能导致未经授权的访问，挑战安全模型的可靠性
反对方观点：
- 有意设计：浏览器遵循Permissions-Policy规范，显示顶级站点以减少混乱和混淆
- 依赖其他漏洞：利用需要XSS或HTML注入；在安全环境中，风险很小
- 可用性权衡：这种设计防止用户被多个权限请求淹没
- 缓解选项有限：虽然Chrome支持Permission-Policy头，但Firefox和Safari不支持
最终思考
权限提示中的源显示操纵凸显了可用性和安全性之间的微妙平衡。虽然现代浏览器有意显示顶级站点以避免用户混淆，但当与HTML注入/XSS等漏洞结合时，这种设计可能被利用。
如果将安全漏洞定义为任何能够实现未经授权访问或数据泄漏的行为，那么误导性UI元素确实会引起担忧。然而，这种权衡是为了应对欺骗性广告等问题而做出的。
最终，这种行为是安全漏洞还是有意的妥协，仍然存在争议。