JS `Service Worker` `Cache Poisoning` (缓存投毒) 与 `Offline Attack`

嘿，大家好！今天咱们来聊聊Service Worker这玩意儿，以及它可能带来的两个“小惊喜”：Cache Poisoning（缓存投毒）和 Offline Attack（离线攻击）。别害怕，听起来吓人，其实原理很简单，就像给你的浏览器“喂错东西”一样。

Service Worker是个啥？

先来温习一下，Service Worker本质上就是一个运行在浏览器后台的JavaScript脚本。它就像一个代理，拦截你的网络请求，然后决定是去服务器拿数据，还是直接从缓存里拿。这玩意儿最酷的地方在于，即使你离线了，也能让网站继续工作，体验丝滑。

Cache Poisoning：给浏览器“喂毒药”

想象一下，你开了一家餐厅，Service Worker就是你的服务员。正常情况下，顾客（浏览器）点菜（请求），服务员要么去厨房（服务器）拿菜，要么从冰箱（缓存）里拿。

Cache Poisoning就相当于有人偷偷往冰箱里放了有毒的菜。下次服务员直接从冰箱里拿，顾客吃下去就中毒了。在Service Worker的世界里，这个“毒药”就是被恶意篡改的缓存数据。

怎么“投毒”？

HTTP响应头操纵：

最常见的“投毒”方式就是修改HTTP响应头。例如，把Cache-Control: max-age=0改成Cache-Control: max-age=31536000。这样，即使服务器说不缓存，Service Worker也会强行把这个“毒药”缓存一年！

例子：

假设你的网站有个JS文件app.js，正常情况下是这样的：

// app.js
console.log("Hello, world!");

攻击者通过某种方式（比如中间人攻击）拦截了对app.js的请求，并篡改了响应头和内容：

HTTP/1.1 200 OK
Cache-Control: max-age=31536000
Content-Type: application/javascript

console.log("You've been poisoned!");

Service Worker会把这个被篡改的app.js缓存起来，以后所有的用户都会运行这个“有毒”的版本。

代码示例（Service Worker）：

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        if (response) {
          console.log('Found in cache:', event.request.url);
          return response; // 直接从缓存返回
        }

        console.log('Fetching from network:', event.request.url);
        return fetch(event.request)
          .then(response => {
            // 检查响应状态码，只缓存200 OK的
            if (!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // 克隆一份response，因为response只能被使用一次
            const responseToCache = response.clone();

            caches.open('my-site-cache')
              .then(cache => {
                cache.put(event.request, responseToCache);
              });

            return response;
          });
      })
  );
});

在这个例子里，如果攻击者成功篡改了app.js并设置了超长的Cache-Control，Service Worker会傻乎乎地把“毒药”缓存起来。

利用不安全的缓存策略：

有些网站的缓存策略过于宽松，比如缓存所有GET请求，甚至包括包含敏感信息的请求。攻击者可以构造一个包含恶意payload的GET请求，然后让Service Worker把它缓存起来。

例子：

假设你的网站有个搜索功能，用户可以通过GET请求传递搜索关键词：
```
/search?q=敏感信息
```
如果你的Service Worker缓存了所有GET请求，那么攻击者可以构造一个包含恶意代码的GET请求：
```
/search?q=<script>alert('You are hacked!')</script>
```
下次有用户访问/search页面，Service Worker可能会直接从缓存里返回这个包含恶意代码的页面，导致XSS攻击。
依赖注入：
攻击者可以通过控制Service Worker注册时所依赖的脚本，从而间接控制缓存行为。

例子：
如果Service Worker的注册脚本是从一个CDN加载的，而攻击者控制了CDN，那么他就可以修改注册脚本，从而控制Service Worker的行为，包括缓存策略。

Offline Attack：离线也能搞事情

有了被“投毒”的缓存，即使你离线了，攻击者也能利用Service Worker搞事情，这就是Offline Attack。

怎么搞？

篡改页面内容：

如果你的网站依赖Service Worker缓存了一些核心的HTML、CSS和JS文件，攻击者可以通过Cache Poisoning篡改这些文件，然后在你离线时，Service Worker会加载这些被篡改的文件，从而改变网站的行为，显示恶意信息，甚至窃取用户数据。
钓鱼攻击：

攻击者可以篡改登录页面，当你离线时，Service Worker会加载这个被篡改的登录页面，诱骗你输入用户名和密码，然后把这些信息发送到攻击者的服务器。
拒绝服务（DoS）：

攻击者可以篡改Service Worker的逻辑，让它在离线时不断地执行某些耗费资源的操作，导致你的设备卡顿甚至崩溃。

代码示例（Offline Attack）：

假设攻击者成功篡改了index.html，添加了一段恶意代码：

<!DOCTYPE html>
<html>
<head>
  <title>My Website</title>
</head>
<body>
  <h1>Welcome to my website!</h1>
  <script>
    // Malicious code
    alert("You are under attack!");
  </script>
</body>
</html>

当你离线时，Service Worker会加载这个被篡改的index.html，然后执行其中的恶意代码。

防御手段：

说了这么多，是不是有点害怕？别慌，亡羊补牢，犹未晚也。以下是一些防御Cache Poisoning和Offline Attack的建议：

防御手段	描述	代码示例
使用HTTPS	使用HTTPS可以防止中间人攻击，从而避免攻击者篡改HTTP响应。	无，这是网络层面的配置，需要配置服务器和CDN。
设置合理的Cache-Control	谨慎设置`Cache-Control`，避免过度缓存。尽量使用`max-age`，而不是`immutable`。	`HTTP/1.1 200 OK Cache-Control: max-age=3600`
验证Service Worker的完整性	使用Subresource Integrity (SRI) 验证Service Worker脚本的完整性。	`html <script src="service-worker.js" integrity="sha384-hash" crossorigin="anonymous"></script>`
定期更新缓存	定期更新缓存，避免使用过期的缓存数据。	javascript self.addEventListener('activate', event => { const cacheWhitelist = ['my-site-cache']; event.waitUntil( caches.keys().then(cacheNames => { return Promise.all( cacheNames.map(cacheName => { if (cacheWhitelist.indexOf(cacheName) === -1) { return caches.delete(cacheName); } }) ); }) ); });
内容安全策略 (CSP)	使用CSP可以限制浏览器可以加载的资源，从而防止XSS攻击。	“` Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://example.com;
校验数据完整性	在Service Worker中校验缓存数据的完整性，例如使用哈希算法。	javascript self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request) .then(response => { if (response) { // 校验哈希值 return response.text().then(text => { const expectedHash = localStorage.getItem(event.request.url); const actualHash = calculateHash(text); // 自己实现的哈希算法 if (expectedHash === actualHash) { return new Response(text, { headers: response.headers }); } else { // 缓存被篡改，删除缓存 caches.delete(event.request); return fetch(event.request); } }); } return fetch(event.request); }) ); });
使用不可预测的缓存键	使用不可预测的缓存键可以防止攻击者猜测缓存内容。	在Service Worker中，可以使用随机字符串作为缓存键的一部分。
隔离敏感数据	避免将敏感数据存储在Service Worker的缓存中。	如果必须存储敏感数据，请使用加密算法进行加密。
监控和日志	监控Service Worker的行为，并记录异常事件。	使用Sentry、New Relic等工具进行监控和日志记录。
审查代码	定期审查Service Worker的代码，确保没有安全漏洞。	特别关注缓存策略、数据校验和错误处理。
用户权限控制	对于需要用户登录才能访问的资源，在Service Worker中进行权限验证。	在`fetch`事件中，检查用户的登录状态，如果用户未登录，则不要从缓存中返回资源。

总结：

Service Worker是个好东西，能提升用户体验，但也要注意安全。Cache Poisoning和Offline Attack是需要重视的潜在风险。通过合理的配置和安全措施，我们可以有效地防御这些攻击，让我们的网站更加安全可靠。

记住，安全是一个持续的过程，需要我们不断地学习和改进。希望今天的讲座对大家有所帮助！下次再见！

发表回复 取消回复

发表回复取消回复