通过IFRAME

Question

我们的申请概述如下。用户界面是从安全域https://aaa.com提供的，并托管来自同一域的脚本。

它将客户端站点https://client.com加载到IFRAME。此站点不可信，可能包含恶意XSS，因为它的代码质量通常可能低于我们的应用程序。

该网站从我们的第二个域https://bbb.com加载另一个受信任的脚本。如有必要，此脚本也可以来自https://aaa.com。 aaa和bbb脚本都从aaa.com调用REST API，并且需要安全令牌。通过从域aaa上的顶部窗口登录到UI获得安全令牌。

我们需要建立一个安全通道，以便将安全令牌从浏览器窗口中的私有闭包（scriptA.js）传递到IFRAME（scriptB.js）脚本中的私有闭包

由于客户端站点是不同的域，我们需要使用postMessage API来进行脚本的通信。理想情况下，我们希望传递可信消息，例如“嘿，我是scriptB，向我发送使用此密钥加密的令牌（为该单个事件生成的非对称加密公钥），并让scriptA发送恶意XSS无法读取的加密密钥”。

然而，恶意XSS也可能伪造为scriptB，因为它位于同一个域中，并且使用自己的密钥更早地发送此消息并从响应中侦听令牌。

问题是我们如何确保在scriptA中验证请求消息是从https://bbb.com加载的脚本发送的，而不是从client.com或其他域加载的XSS发送的，或者其他方式安全通信可用于将令牌从scriptA安全地传递给scriptB。

有什么建议吗？

Answer 1

只是为了让潜在的访客知道。我们没有找到解决此问题的方法，因为保护此类通信的任何方法都包括CORS，只有在您使用Cookie进行授权时才可以使用CORS。如果通信不涉及cookie，则攻击者服务器可以用作转发代理，以绕过所包含的任何CORS措施。

除非postMessage包含脚本的URL（而不是托管窗口），否则似乎无法保护此类通信并阻止XSS模仿目标脚本。

我们最终解决它的方式基于以下假设：

• 即使令牌受到保护，恶意XSS仍然可以发出键盘和鼠标事件，这样就可以按照用户在给定视图中的方式操作内容。

出于这个原因，我们已经选择将前一个更通用的令牌包装为另一个令牌，该令牌是由scriptA（受保护的）从父窗口上下文调用的服务器API生成的，并限制可能的用户操作仅限于可由用户操作完成的操作。此令牌在scriptB调用的服务器上验证。

这导致了这样一个事实：即使XSS从消息中窃取令牌，它也不能通过伪造键盘和鼠标事件来模拟用户操作。除此之外，令牌是有时间限制的，因此即使XSS窃取了令牌，攻击者也无法保留它以便以后在外部操纵相同的数据。

最后，客户端的安全漏洞只会破坏他自己的单页，而不是整个基础架构。