探索权限提示中的源显示操纵
自2025年以来，我一直在深入研究浏览器安全，最近观察到现代浏览器在通过iframe委托访问时显示权限提示的配置错误——我称之为“权限提示中的源显示操纵”。这一观察引发了一个关键问题：这种行为是否应被视为安全漏洞。
问题是什么？
在多个现代浏览器中，权限提示显示的是顶级源，而不是来自第三方iframe的实际请求源。这种设计决策意味着，如果攻击者通过HTML注入或XSS漏洞注入iframe，浏览器提示会误导性地显示受信任站点正在请求权限——尽管实际上是恶意域名在发出请求。因此，敏感权限（如麦克风、摄像头或地理位置访问）可能被授予攻击者控制的域名。
利用场景
想象一个控制恶意域名（例如attacker.com）的攻击者。通过利用受信任网站（例如target.xyz）上的HTML注入或XSS漏洞，攻击者可以注入请求权限的iframe。通用负载可能如下所示：
|
|
当用户访问该站点时，这些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目前不支持该头。这意味着，在不支持该头的浏览器中，误导性权限提示的潜力仍然存在。关于该头的进一步阅读，请参见MDN的Permissions-Policy文档。
这是安全漏洞吗？分解辩论
支持方：
- UI欺骗：注入缺陷让攻击者显示提示，显示受信任站点，欺骗用户授予权限。
- 风险放大：受损的顶级站点可能无意中将权限委托给恶意内容。
- 安全削弱：误导性提示可能导致未经授权的访问，挑战安全模型的可靠性。
反对方：
- 有意设计：浏览器遵循Permissions-Policy规范，显示顶级站点以减少混乱和混淆。
- 依赖其他漏洞：利用需要XSS或HTML注入；在安全环境中，风险最小。
- 可用性权衡：这种设计防止用户被多个权限请求淹没。
- 有限的缓解选项：虽然Chrome支持Permission-Policy头，但Firefox和Safari不支持。
最终思考
权限提示中的源显示操纵突显了可用性和安全性之间的细微界限。虽然现代浏览器有意显示顶级站点以避免用户混淆，但这种设计在与HTML注入/XSS等漏洞结合时可能被利用。
如果安全漏洞被定义为任何允许未经授权访问或数据泄漏的行为，那么误导性UI元素确实引起担忧。然而，这种权衡是为了对抗欺骗性广告等问题。
最终，这种行为是安全缺陷还是有意的妥协仍有待辩论。我欢迎您的想法——如果您认为我误解了这个问题，请告诉我。