使用 SRI 增强 localStorage 代码安全

发表于 5年以前 | 总阅读数：4124 次

在上篇介绍 Subresource Integrity（SRI）的文章最后，我提出一个问题：现在广泛被大家使用的「将 JS 代码缓存在本地 localStorage」方案有很大的安全隐患。网站出现任何 XSS，都有可能被用来篡改缓存在 localStorage 中的代码。之后即使 XSS 被修复，localStorage 中的代码依然是被篡改过的，持续发挥作用。本文接着讨论这个话题。

将 JS/CSS 代码缓存在本地的用途，本博客反复讲过，这里不再啰嗦。这个安全隐患的根源在于：大部分 Web 应用从 localStorage 中获取缓存代码后，没有任何检测机制，直接执行。而 localStorage 是跨页面的，同域下任何页面有 XSS 漏洞，就可以被攻击者用来往 localStorage 写入恶意代码。

以下几段示意代码，可以帮大家更清楚地看出问题所在：


<!-- 首次访问 -->

    <script id="code">/*一大段正常代码*/</script>

    <script>html2ls('my_code', document.getElementById('code').innerHTML)</script>

    <script>
    function html2ls(ls_name, code) {
        localStorage[ls_name] = code;
    }
    </script>


<!-- 第二次访问 -->

    <script>ls2html('my_code')</script>

    <script>
    function ls2html(ls_name) {
        var script = document.createElement('script');
        script.innerHTML = localStorage[ls_name]; // 取到：/*一大段正常代码*/
        document.head.appendChild(script);
    }
    </script>


<!-- 访问有 XSS 的页面 -->

    <img src="" onerror="localStorage['my_code']+=';alert(0);'" />


<!-- 第 N 次访问 -->

    <script>ls2html('my_code')</script>

    <script>
    function ls2html(ls_name) {
        var script = document.createElement('script');
        script.innerHTML = localStorage[ls_name]; // 取到：/*一大段正常代码*/;alert(0)
        document.head.appendChild(script);
    }
    </script>

很多 Web 应用会使用 loader 来加载资源，如果 loader 里有从 localStorage 读取并执行代码的逻辑，也有相同的安全隐患，原理都一样。

要解决这个问题，很容易想到的方案是：在页面中输出缓存资源的摘要签名，并在 ls2html 函数中校验。但在浏览器中计算签名，需要额外引入一大段 JS。而为了让 ls2html 尽快可用（因为从 localStorage 中读取 CSS 也依赖于它），这段 JS 必须在页面最开头引入，这对页面性能影响很大。另外，自己实现的摘要算法，在处理大段文本时效率也不会太高。

在上篇文章中，我们知道了利用 SRI 策略，可以让浏览器自动计算外链资源的签名与内容是否匹配。不需要额外引入新的代码，浏览器内置的算法也会有更高的效率。

由于 SRI 只能作用于外链资源，还需要将从 localStorage 获取到的代码转为外链形式。有两个方案可以实现这一需求：data URIs 和 Blob URL。

将代码转为 data URIs 形式的外链并启用 SRI：


var code = 'alert("hello world!");';


    var script = document.createElement('script');
    script.crossOrigin = 'anonymous';
    script.integrity = 'sha256-0URT8NZXh/hI7oaypQXNjC07bwnLB52GAjvNiCaN7Gc=';
    script.src = 'data:application/x-javascript,' + encodeURIComponent(code);

    document.head.appendChild(script);

将代码转为 Blob URL 形式的外链并启用 SRI：


var code = 'alert("hello world!");';


    var blob = new Blob([code], {type: "application/x-javascript"});
    var blobUrl = URL.createObjectURL(blob);

    var script = document.createElement('script');
    script.crossOrigin = 'anonymous';
    script.integrity = 'sha256-0URT8NZXh/hI7oaypQXNjC07bwnLB52GAjvNiCaN7Gc=';
    script.src = blobUrl;

    document.head.appendChild(script);

分别在支持 SRI 的 Chrome 和 Firefox 中测试，结果如下：

测试用例 Chrome 46.0.2490.33 beta Firefox 44.0a1 (2015-09-23)

data URIs（无 SRI）

正常执行

Blob URL（无 SRI）

正常执行

data URIs（SRI + 正确摘要）

CORS 报错

不执行、不报错

Blob URL（SRI + 正确摘要）

正常执行

不执行、不报错

data URIs（SRI + 错误摘要）

CORS 报错

不执行、不报错

Blob URL（SRI + 错误摘要）

Integrity 不匹配报错

不执行、不报错

上面的测试结果表明：

没有 SRI 策略时，这两种方式都可以把字符串转为外链形式加载并执行；
Firefox 中，启用 SRI 后，data URIs 和 Blob URL 两种形式的外链都不执行；
Chrome 中，启用 SRI 后，data URIs 形式的外链始终会报 CORS 跨域错误；
Chrome 中，启用 SRI 后，Blob URL 形式的外链会校验 integrity 属性；

可以看到，最后一种情况是我想要的。改造前面的代码，在第二次访问时输出签名，并增加校验机制：


<!-- 第二次访问 -->

    <script>ls2html('my_code', 'sha256-xxxx')</script>

    <script>
    function ls2html(ls_name, integrity) {
        var script = document.createElement('script');
        var code = localStorage[ls_name];

        //计算 chrome 版本号
        var chromeVersion = -1;
        var match = /chrome\/(\d+)/i.exec(navigator.userAgent);
        if(match) {
            chromeVersion = match[1] | 0;
        }

        //chrome 45 才开始支持 SRI
        if (integrity && chromeVersion > 44) {
            var blob = new Blob([code], {type: "application/x-javascript"});
            var blobUrl = URL.createObjectURL(blob);

            script.crossOrigin = 'anonymous';
            script.integrity = integrity;
            script.src = blobUrl;

            script.onerror = function() { alert('localStorage 代码被修改！') };
        } else {
            script.innerHTML = code;
        }

        document.head.appendChild(script);
    }
    </script>

核心逻辑就是这样，细节上还有一些地方要考虑。例如如果启用了 CSP 策略，需要在 script-src 配置中加上 blob:；另外这样改写之后，之前同步加载的代码变成了异步。我的博客已经用上了本文这个 localStorage 代码安全增强方案，在本博客任意页面打开浏览器控制台，执行以下代码并刷新页面：


localStorage.all_js += ';alert(0);'

如果你的浏览器是 Chrome 45+，会发现 alert(0) 并不会执行。我会检测出 localStorage 代码被修改，从而自动修复。

关于 Chrome 和 Firefox 实现上的差异，我咨询了 public-webappsec@w3.org 邮件组，得到的答复是 Chrome 符合预期。Mozilla 的 Bugzilla 中已经有关于本问题的讨论。

在 NodeJS 中，计算符合 SRI 要求的 integrity 值很简单，使用 crypto 模块就可以：


var crypto = require('crypto');


    function getIntegrity(content, algorithm) {
        algorithm = algorithm || 'sha256';

        var result = algorithm + '-' + crypto
                .createHash(algorithm)
                .update(content)
                .digest("base64");

        return result;
    }

最后，使用 Content Security Policy Level 2（CSP2）策略，也可以校验内联代码是否被修改过，支持度更好一些，但使用起来也更麻烦。这部分内容留给以后有时间再写。