权限提示中的源显示操控探索
是安全漏洞还是有意设计选择？
自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元素确实会引起担忧。然而，这种权衡是为了应对欺骗性广告等问题而做出的。
最终，这种行为是安全缺陷还是有意的妥协仍然存在争议。欢迎您分享想法——如果您认为我误解了这个问题，请告诉我。