探索权限提示中的源显示操纵
是安全漏洞还是有意设计？
自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元素确实会引起担忧。然而，这种权衡是为了应对欺骗性广告等问题而做出的。
最终，这种行为是安全漏洞还是有意的妥协，仍然有待讨论。