从事应用程序安全工作有时感觉就像在“照常工作”和“这该死的一天”之间来回跳转。当每个部门都在加速数字化转型，远远超过安全控制的节奏时，平衡就更加困难了。中断这个加速过程的问题点，基本都出现在网站开发和安全环境中。二十年前，一个“典型”的网站是专门用于发布信息的静态页面。现在，动态Web应用程序处理极其敏感的数据并执行关键操作。敏感信息继续流经几乎每个网站，为攻击者提供了窃取和出售这些私人信息的绝好机会。事实上，此类攻击已经相当成功，并且泄漏数量的增加速度还在不断攀升。最近的数据显示，2020年第一季度的泄露记录数量比2019年第一季度增加了273%。现在，从事应用安全的人已经知道，传统的安全系统（如服务器端和网络）WAF等安全产品）无法阻止针对网站的数据外出攻击。攻击者会利用客户端安全盲点，在未成功攻击企业第一方服务器的情况下，将恶意代码注入企业网站，从而产生“定时炸弹”——网站供应链。代码依赖的好处和风险今天典型的JavaScript开发过程总是依赖开源组件来加速开发。这意味着公司在其网站上使用数百个外部资源。在这种情况下，公司几乎无法控制代码，最终大多数人会选择相信他们使用的代码模块是可靠和安全的。但问题是这些mod可能还依赖第三方代码，使得代码依赖变得更加复杂。代码的依赖项越多，攻击面就越大，这使得攻击者更有可能控制部分依赖项，向网站页面注入恶意代码。如果此网站供应链攻击看起来像是SolarWinds事件的翻版，那是因为SolarWinds本身就是供应链攻击如何取得爆炸性结果的完美例子。近日，攻击者在官方PHPGit仓库中植入了一个远程执行后门。但该恶意代码是在一次本地代码检查中发现的，因此并未进入官方更新包。然而，这也暴露了网站供应链的另一个安全漏洞：如果恶意代码隐藏得更好，是否能进入公开发布的更新包中？这种事情之前就发生过，比如在Copay事件中，恶意代码影响了产品（加密货币钱包）的多个版本，并窃取了用户数据。另一个事件可以让我们意识到事件更糟。安全研究员AlexBirsan利用关联混淆的设计漏洞，成功攻击了微软、苹果、PayPal等35家科技公司。虽然Alex的行为据说是出于道德安全研究的目的，但攻击者很快复制了这种攻击方式，并试图攻击其他尚未开始防御的公司。这些例子只是冰山的顶层。网站供应链广而深，平均一个网站应用包含超过1000个外部源代码组件。而且，最近的研究表明，安装其中一个软件包意味着间接信任79个第三方软件包和39个维护者——我们可以猜测现代Web应用程序的攻击面到底有多大。减少潜在危险那么，有这么多不确定因素，而且越来越多的人认为网站供应链是一场不可避免的灾难，我们能做些什么呢？这个问题的答案可能是采用纵深防御，在服务器端除了网络安全管控之外，进一步部署更好的供应商管理能力，增加一层客户端防御。使用新协议审计和管理第三方供应商变得越来越重要，尽管审计数百个第三方组件很困难。另外，review只能给出代码在某个时间点的状态，而不能识别出突然被感染的原始正常代码。因此，需要在客户端运行时额外增加一层安全控制，以检测和控制可疑代码行为。要做到这一层的管控，可能要耗费数月甚至实时的时间来发现和解决网站供应链造成的数据泄露。这些都是组织可以采取的减少网站供应链风险的所有步骤。至少，我们希望组织和机构不要等到最后一秒才开始做这些事情。
