企业网站安全的“定时炸弹”

应用安全的工作有时候感觉就像在“和以往一样的工作”与“该死的一天来了”之间反复横跳。而当数字化转型在每个部门都在加速进行，远远超过安全控制的节奏的时候，平衡就更加困难了。

打断这个加速化进程的问题点基本都发生在网站开发和安全环境。二十年前，一个“典型”的网站都是为了发布信息的静态页面。而现在，则是由一个动态的网站应用处理极其敏感的数据，并执行关键操作。

敏感信息持续通过几乎每个网站，从而让攻击者有了窃取并贩卖这些私人信息的完美机会。事实上，这样的攻击已经相当成功了，而被泄漏数量的增长速度也在持续攀升。最近的数据显示，2020年第一季度泄露的记录相比2019年第一季度高出了273%。

现在，那些在应用安全工作的人已经知道传统安全系统（比如像WAF这种服务器端和网络安全的产品）无法防范针对网站的数据流出攻击。攻击者会利用客户端侧的安全盲点，将恶意代码注入公司的网站，而不需要先成功攻击他们的第一方服务器，这就引出“定时炸弹”——网站供应链。

代码相关性的收益和风险

现在典型的JavaScript开发流程总是依赖于开源组件，来加速发展。这意味着公司在他们的网站上会使用几百个外部源代码。这个情况下，公司对代码几乎完全没有管控能力，最终绝大部分会选择信任他们使用的代码模组可靠且安全。但问题是，这些模组可能也会依赖于第三方代码，导致代码相关性变得更为复杂。

代码的相关性越多，攻击面也就越大，也就使得攻击者更有机会控制相关性中的一部分，并对网站页面进行恶意代码注入。

如果这个网站供应链攻击看上去简直在复现SolarWinds事件，那是因为SolarWinds本身就是一个展示供应链攻击如何能达成爆炸效果的完美例子。

最近，攻击者在PHP Git的官方代码库里植入了远程执行后门。不过，这个恶意代码在本地代码检查中被发现，因此它没有进入官方的更新包中。然而，它显现出网站供应链当中的另一个安全缺陷：如果恶意代码被隐藏得更好，它们能否进入公开发布的更新包中？这种事情以前就发生过，比如Copay事件中，恶意代码影响了数个版本的产品（加密货币钱包），并且窃取了用户数据。

另一个事件能让我们意识到，事件更加糟糕。安全研究人员Alex Birsan通过利用相关性混淆的设计漏洞，成功攻击了35个科技公司，包括微软、苹果、PayPal等。尽管说Alex的行为只是出于道德安全研究的目的，但是攻击者们很快复制了这个攻击方式，并试图攻击其他还没开始防御的公司。

这些例子不过是冰山的上层。网站供应链广而且深，平均每个网站应用包含超过1,000个外部源代码组件。而且，最近的研究显示，安装其中的一个代码包意味着间接信任79个第三方代码包和39个维护人员——我们可以猜测一下现代网站应用的攻击面到底有多大。

减少潜在危险

那么，有那么多不确定的组件，同时越来越多的人认为网站供应链会是一个必然发生的灾难，能做些什么？

这个问题的答案可能是使用深度防御，在服务器端和网络安全管控之上，进一步部署更好的供应商管理能力，并加上一层客户端防御。用新的协议审查和管理第三方供应商在越来越重要，尽管说审查数百个第三方部件相当困难。另外，审查只能给出某个时间点上的代码状况，却无法识别突然被感染的原正常代码。因此，需要在客户端运行时额外加一层安全管控，检测和控制可疑的代码行为。在这个等级实现管控，能产生消耗的是数月，还是是实时，发现并解决因网站供应链产生的数据泄露。

这些都是组织能够采取的减少网站供应链暴露的措施。至少，希望组织和机构别到最后一秒才开始进行这些操作。

数世点评

开源安全今年来越来越受到人们重视。事实上，由于应用已经成为了整个互联网生态的主要组成部分，开源安全性问题几乎可以牵涉到每一个领域——包括网站的安全性。今年后，网站面临的安全可能不只是SQL注入、CSRF、XSS这类传统的攻击，而更多的会是从开源组件的漏洞发起的降维打击。因此，供应链安全的关注程度应该进一步加深、拓宽。