Enterprise JavaScript: Opportunities, Threats, Solutions

如果你正在使用 JavaScript,那你应该熟悉它的历史。这个有着 24 年历史的编程语言在过去几年里发生了巨大的变化,特别是随着 Node.js 和 JS 框架的出现。

如果当初 JavaScript 只是成为一种使网站变得动态且更有趣的噱头,那么今天的情况就完全不同了。 JavaScript 是使今天的如此 Web 强大的主要原因

97%的现代 Web 应用使用了 JavaScript,几乎每一家 500 强公司都依赖 Node.js 和 JavaScript 来创建 Web 和移动应用应对激烈的竞争。

随着渐进式 Web 应用作为本机应用的可行替代方案而被快速采用,这种增长似乎确实会加速。 JavaScript 不仅适用于 Web,也适用于移动端和可以跨平台的桌面端。

尽管其有着众多优势和商业价值,但是我们仍然必须考虑另一面:使用 JavaScript 所涉及到相当大的安全威胁

威胁

JavaScript 需要由浏览器处理才能工作。这意味着它无法以可行的方式进行加密。任何人都可以访问、阅读和修改 JavaScript 代码。虽然看上去可以认为只要公司不在客户端存储重要的业务逻辑,这就不会成为问题。但是服务器调用需要时间,而在性能至关重要的服务中,例如流媒体、电子商务或游戏,这不是很好的选择。因此出于性能考虑,专有算法需要被放置在客户端。

当我们将专有算法和暴露环境这两样结合起来时,会引发一个灾难。长期以来,恶意攻击者一直在利用暴露的 JavaScript 窃此代码并重新分发山寨应用,而且这只是冰山一角。

暴露的 JavaScript 打开了自动化滥用的大门。例如,云提供商可以为新帐户免费提供1个月的服务,这可能会被恶意参与者通过自动创建帐户的脚本滥用。这在不适用验证码的用例中尤其重要。

为了控制帐户滥用并打击欺诈行为,一些公司部署了 JavaScript agents 以抵御僵尸程序或提供设备指纹识别。但是因为这些 agents 的代码也暴露了,攻击者也可以对其进行逆向工程来完全绕过它们。

还有作弊和盗版的情况。攻击者可以利用暴露的 JavaScript 来绕过程序的限制,在不付费的情况下解锁新功能或违反许可协议 —— 这些都会对公司的业务模式构成威胁。

通过逆向工程游戏源码来绕过付费

通过逆向工程游戏源码来绕过付费

许可协议和版权对于视频或音频流等数字内容尤为重要。通过访问 HTML5 网络播放器的底层 JavaScript,攻击者可以捕获并重新分发流,从而导致流媒体提供商的巨大商业损失

企业依靠 JavaScript 来开发应用,这些应用程序是其业务的核心,却将其核心逻辑和专有算法置于攻击之下。同样他们也无法加密这些代码。但他们可以做的是通过一系列防止所有上述攻击行为的安全层来保护 JavaScript。

解决方案

当我们解决代码盗窃和逆向工程的威胁时,保护 JavaScript 的唯一可行方法是隐藏其逻辑。这是 OWASP 关于其移动应用十大安全风险的推荐,M9-逆向工程

为了防止逆向工程,你必须使用混淆工具。

JavaScript 混淆是保护 JavaScript 源代码的核心步骤。混淆的 JavaScript 对于阅读、理解和逆向工程来说极其复杂。但是不同的 JavaScript 混淆器提供了不同的保护级别,开发团队通常很难决定应该使用哪种工具。免费的混淆器只能提供基本的转换,而且可以使用自动化工具轻松反转。在决定使用哪种混淆工具时,除了考虑工具的成本之外,你还应该问自己:

如果攻击者要重新分发、篡改我的代码或绕过我们的许可协议,那我的业务成本是多少?

而且我们仍然必须考虑更高级的程序被滥用、作弊和盗版的威胁。免费的混淆器并不能提供真正的保护。同样,企业级的问题需要企业级解决方案。

面向企业市场的 JavaScript 保护解决方案。它不仅要提供最先进的混淆技术,还需要从以下三个面层来缓解调试和尝试篡改的威胁:

  • 代码锁 — 通过不同的程序锁来限制 JavaScript 应用的执行时间、地点和人员。
  • 自我防护 — 当受保护的代码面临调试或受到篡改时,完整性检查会破坏掉程序或触发你所指定的对策。
  • 自我修复 — 运行时完整性检查,自动将篡改后的代码恢复为原始、干净的代码,而不会对程序进行破坏或影响用户体验。

这些技术的结合能够有效地缓解滥用、欺骗、盗版、代码盗窃以及通过客户端进行逆向工程的尝试。

展望

JavaScript 未来的前景非常不错。企业可以通过利用 JavaScript 的通用性、灵活性和极其活跃的社区,在 Web 和移动设备上提供高级的用户体验,并不断提高服务标准。

虽然我们不希望恶意行为者为了自己的利益而盯上自己的应用,但公司可以(并且应该)采取行动来隐藏其代码逻辑并积极的阻止调试和篡改的企图。与某些人的观点不同,这不是传统的安全问题 —— 而是需要添加新的安全层来进一步保护公司的关键业务资产。