考虑到“社交共享”徽章（“喜欢”按钮等）的普遍存在，您如何降低与第三方Javascript相关的风险？

Question

我的营销团队需要在我们的网站上使用社交分享按钮（Facebook，G +，SU等）。安全团队提出了一个我不好意思承认我之前没有考虑过的一点：因为第三方JS是一个攻击媒介，我们不应该直接从第三方服务器加载它。

风险

我将以Facebook为例。 FB的某个人可以添加一些偷偷摸摸的后门代码来观看用户或至少抓住他们的电子邮件和来自我们网站的名称。 DNS缓存中毒可用于提供恶意Javascript而不是预期的FB库。等等 - 这里可能还有更多的攻击向量。

可能的解决方案

- 在本地获取JS（在审查安全漏洞之后），并在cron上运行curl + diff来监视更新 - 在托管之前审核那些更新。这不是真的可行，因为FB和g +在加载主lib之后都会在异地加载额外的库，而我还没有找到解决方法。

- 不使用社交分享按钮？

这里有最受欢迎的最佳做法吗？我的第一反应是，来吧，这是谷歌和Facebook。如果他们的社交分享按钮发生恶意，整个互联网将在0.001秒内了解它。你说什么？

Answer 1

除此之外，确实没有任何普遍接受的解决方案：

1. 盲目信任Facebook / Google /等。
2. 不要使用他们的脚本。

Answer 2

如果您在SSL上加载了所有库（以及您的所有网站），则您很容易受到Facebook / Google中的恶意行为的攻击。<​​/ p>

您可以信任它们，也可以不使用这些库，并使用公开记录的URL或其服务器端API自行完成。

Answer 3

让我们在这里切合实际。虽然我知道任何可以发生的事情，但是你的网站更有可能被谷歌/ Facebook / Twitter通过心怀不满的员工或类似的东西注入恶意代码。 可以发生，但机会很小。

如果访问您网站的DNS的客户遭到入侵，那么注入他们自己的facebook.com A-Record，这样他们就可以将javascript注入您的网站，这是您最不担心的问题。如果我正在运行恶意DNS服务器并让人们使用它;我有恶意，我要么专门针对你的网站，我只是建立一个看起来像你的网站，并将所有用户数据带入我的数据库;或者我会追随银行和金融机构。注入facebook javascripts不是我的主要目标。

同样，它可能会发生，但在我看来，还有太多其他的，较低的悬念，使它值得真正担心。如果你有一些政府规定让你对这类事情负责，那么在更安全的方面玩它并且不使用它们或使用facebook API实现你自己的“喜欢”按钮可能是明智的。我敢肯定G +和Twitter有类似的非基于javascript的方法来做到这一点。