如何只允许列入白名单的资源(脚本,像素等)在沙盒iframe中运行？

Question

我正在寻找一种方法,只允许列入白名单的脚本在沙盒iframe中运行.我在想一个iframe-sandbox指令,它只允许列入白名单的脚本在iframe中运行.类比是内容安全策略中的script-src指令.

问题:

<iframe sandbox="allow-same-origin allow-scripts" src="https://app.thirdparty.com" width="100%" height="800" frameBorder="0"></iframe>

iframe中的应用程序为我的网站提供了有价值的功能.但是,它会吸引我想要控制的外部资源(即阻止),例如AnalyticsJavaScript.com和TrackingPixel.com.我想允许来自app.thirdparty.com的脚本,但阻止AnalyticsJavaScript.com和TrackingPixel.com.

任何帮助赞赏.

Answer 1

不幸的是,答案很复杂.随着iframe沙盒的出现,问题似乎很简单,但您正在寻找的规范是一项正在进行中的工作.因此,如果您需要合适的浏览器支持,问题将转变为如何修改iframe的内容,这通常涉及某种代理.

内容安全政策

您真正需要的规格是CSP.最简单的是,您将允许使用iframe属性的特定脚本csp="...".

<iframe ...
        src=""
        csp="script-src https://app.thirdparty.com/"
        ...></iframe>

来自未指定域的任何脚本(即问题中的跟踪脚本)将不允许在响应中.请注意,将脚本限制为来自指定源的脚本确实依赖于与第三方应用程序服务器的协作.如果服务器未通知用户代理它将遵守CSP限制,则响应将被阻止.

CSP仍然是一份工作草案,将来可能会发生变化.正如评论中所述,Chrome 61和Opera 48 已经实现了CSP规范,但是在这个阶段,Firefox,Edge或Safari没有任何迹象表明它们也会实现它.除非您可以保证您的用户只使用支持该规范的浏览器,否则跟踪脚本仍会出现在很大比例的用户中.

其余的建议都涉及修改iframe的内容以删除有问题的脚本.

反向代理

创建一个反向代理来阻止iframe中的几个跟踪脚本可能相当于使用核弹头点燃篝火,就像过度杀伤一样.但是,如果您能够在这种程度上配置服务器,那么它是我发现的iframe内容注入/修改/阻止的最可靠和最无缝的方法.

在维基百科页面状态:

反向代理是一种代理服务器,它代表客户端从一个或多个服务器检索资源.然后将这些资源返回给客户端,看起来好像它们来自代理服务器本身.

由于反向代理是第三方应用程序与您的站点之间的中介,因此它可以透明地修改响应以删除不需要的脚本.我将在此示例中使用Apache,但您的实现实际上取决于您已经使用的服务器.

您需要一个指向您的服务器IP的代理子域,例如proxywebapp.yourdomain.com.然后,在服务器上,您将在httpd.conf中创建一个使用Apache mod_proxy模块的虚拟主机.在虚拟主机配置中,您可以使用空白替换脚本调用到AnalyticsJavaScript.com和TrackingPixel.com.如果第三方应用程序必须使用HTTPS,则反向代理变得更加棘手,因为您需要SSL虚拟主机和代理的FQDN的SSL证书.

<VirtualHost *:*>
    ServerName        proxywebapp.yourdomain.com
    ProxyPreserveHost On
    ProxyPass         "/" "http://app.thirdparty.com/"
    ProxyPassReverse  "/" "http://app.thirdparty.com"

    # in case any URLs have the original domain hard coded
    Substitute        "s|app.thirdparty.com/|proxywebapp.yourdomain.com/|i"
    # replace the undesired scripts with blanks
    Substitute        "s|AnalyticsJavaScript/| /|i"
    Substitute        "s|TrackingPixel/| /|i"
</VirtualHost>

然后你的iframe指向proxywebapp.yourdomain.com.

<iframe ... src="proxywebapp.yourdomain.com" ...></iframe>

再次:完全矫枉过正,但应该透明地工作.

代理脚本

要考虑的第三个选项是在iframe和第三方应用之间的服务器上实现代理脚本.您可以在代理脚本中添加功能,在脚本到达iframe之前搜索并删除不需要的脚本.此外,代理意味着iframe的内容将验证同源策略,因此您可以在前端使用JavaScript删除不需要的内容,但这可能无法保证脚本在删除之前不会运行.在线提供了许多代理脚本,可用于各种后端(PHP,Node.js等).您可能会安装脚本并将其添加为iframe的src,例如<iframe ... src="proxy.php?https://app.thirdparty.com/" ...>.

除非为所有情况正确配置,否则代理可能无法在第三方应用程序与其父服务器之间正确传输数据.将需要进行测试.

编写自己的服务器端代理以从iframe中删除几个脚本可能有点过分.

如果您无法访问后端,可以使用JavaScript和CORS或JSONP Web应用程序刮Web应用程序的内容,并将其修改为删除脚本.基本上在JavaScript中创建自己的代理.此类网络应用程序(Any Origin,All Origins等)允许您绕过跨域策略限制,但由于它们是第三方,您不能再认为任何Web应用程序的数据是私有的.正确传达应用程序与其父服务器之间的任何数据传输的问题仍然存在.

摘要

目前,广泛支持的纯前端解决方案是不可行的.但是,无论跨域限制如何,都有许多方法可以为猫提供皮肤,甚至可能有更多方法来修改iframe的内容.

内容安全政策确实看起来很有前景,正是您所要求的,但目前缺乏广泛的支持意味着它只能在非常小的情况下使用.该修改内容可能需要配置的,在这种情况下很多反向代理是喜欢开着全尺寸半挂车在风火轮轨道,但很可能会无缝运行.来自转发代理的内容修改实现起来稍微简单一些,但可能会破坏与第三方应用程序的父服务器的通信.