一转眼，汶川大地震过去15年了，你可还记得对当年很多“豆腐渣”校舍的问责？我们今天要关注的是互联网世界上的JavaScript代码，从2023年WWW会议上选择一篇论文 The More Things Change, the More They Stay the Same: Integrity of Modern JavaScript 介绍给大家。
我们往往会有一种错觉，认为网页可以是动态的，但是网页上加载的那些JavaScript代码（特别是一些第三方的JS库）可能是很少更新的。这篇论文的作者就从纠正这种认识的偏差开始，讨论了在JavaScript代码经常变动的情况下，我们应该如何去重新设计JavaScript代码完整性机制。
先来看一张我们编辑部制作的胶片（误），在当前JavaScript应用的生态中，和安全高度相关的是网页从远端（remote origin）加载的JS代码。作为软件供应链中的重要组成，这些代码要么有可能被污染或篡改，要么可能主动制造攻击。例如2022年1月的新闻中，我们看到 color.js 和 faker.js 的作者故意制造的混乱：
一位开源开发者的故意破坏再次引发了企业依赖靠维护者义务工作的开源库的争议。Marak Squires 的开源库 color 和 faker 被广泛使用，其中不乏企业和商业客户。在包管理器 NPM 上，colors 的周下载量超过 2000 万次，有近 19000 个项目依赖它；faker 的周下载量超过 280 万次，有超过 2500 个项目依赖它。开发者在 color.js 库的 v1.4.44-liberty-2 版本中给新的美国国旗模块加入了无限循环，依赖 color.js 的项目会在控制台看到不停打印的非 ASCII 字符。faker v6.6.6 版本的情况类似，他将这两个搞破坏的版本推送到 GitHub 和 npm。受影响的项目包括亚马逊 AWS 的 Cloud Development Kit。开发者此前曾批评企业没有回馈社区，他在 2020 年 11 月警告说，他将不再用义务工作支持大企业，商业客户应该考虑创建分支，或者用每年六位数的薪水补偿开发者。安全专家批评这种行为不负责任，每一个依赖这些库的项目都受到影响，而不仅仅是大企业。GitHub 平台暂时封禁了 Marak Squires 的账号（已解封），此举也引发了对 GitHub 如何控制开源项目的争议。
https://www.solidot.org/story?sid=70299
和传统的安装在用户机器上的软件代码不同，JS代码基本上每次都是从网络上加载后在浏览器中执行，所以用户也好，网页的开发者也好，都会关注JS代码的变动情况。本文作者针对Tranco list上排名前100万的网站所依赖的JS代码进行了持续的追踪，把所有这些JS代码的变化情况进行了分类，如下表所示。我们注意到，除了内容上的变化以外，作者也关注了很多和JS代码相关的因素（例如一个远程JS代码的URL地址发生了变化，这也是一种变化）
经过分析，本文作者给出了下表的数据——将JS代码的URL和内容按照“从来不变”（static）、“每天动态变化”（dynamic）或者介入两者之间进行了统计。我们发现，动态变化的JS代码实际上才是互联网上的主流！
作者进一步追问，JS代码究竟为何而变？为此，作者设计了一个实验，首先请求一个网页，然后对这个网页依赖的所有JS代码再重复请求两次（但是都不再使用浏览器，而是换成用request库去请求，因此会有不同的User-Agent）。结果可以分为4种不同的情况：
-
每次都相同（Same）
-
第一次和后面两次不同（UA，即因为User-Agent不同而产生了差异）
-
每次都不同（Time，即时间不同，返回结果就不同）
-
无法确定（第一次请求的结果可能和后面两次请求结果中的某一次相同，因此无法确定，Indeterminate）
下表列出的数据中，作者发现一份JS代码可能同时属于上述4种情况中的多个类别——在某些网页中，请求一个JS代码可能是每次都相同的，但是在另一些网页中，请求这个JS代码返回的结果却不一定。
总之，这种复杂的动态特性决定了当前很多JS代码完整性检查机制的缺陷：因为JS代码总是在变化（内容也好，来源地址也好），你甚至无法通过对其提前进行hash，然后每次检查hash是否变化来判断它是否可信（一句话，下图的方法不靠谱）。
作者因此对（国际象棋爱好者发表的）2015年CCS论文 The SICILIAN defense: Signature-based whitelisting of web JavaScript 和2016年发表在 ACM Transactions on Privacy and Security 期刊上的论文 How to train your browser: Preventing XSS attacks using contextual script fingerprints 提出 Strict Integrity (SRI) 机制（下图）的稳定性表示了担忧。
那你问，究竟我们应该怎么去判定JS代码的可靠性呢？其实作者提出的建议有点让人哭笑不得，那就是从判定JS代码本身的完整性改为判定JS代码来源地址是否可靠，也就是说，如果来自一个“可靠”的地址，那么这份JS代码就是安全的。可是，到底什么地址算是可靠的呢？
论文：https://dl.acm.org/doi/10.1145/3543507.3583395
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-05-12
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论