DOMPurify中正则表达式全局标志导致的安全过滤问题分析

问题背景

DOMPurify是一个广泛使用的HTML净化库，用于防止XSS攻击。在最新使用过程中，开发者发现当配置ALLOWED_URI_REGEXP参数并使用全局匹配标志(g)时，会出现URI过滤结果不一致的问题。

问题现象

当开发者设置如下净化配置时：

DOMPurify.sanitize(str, {
    ALLOWED_URI_REGEXP: /^(blob|https|epub|filepos|kindle)/gi,
    ADD_URI_SAFE_ATTR: ['width', 'height'],
})

对于相同格式的URI字符串，有时会被允许通过，有时又会被过滤掉，导致净化结果出现随机性。

技术原理分析

这个问题本质上是由JavaScript正则表达式的全局匹配特性引起的。当正则表达式设置了g标志时：

1. 正则表达式对象会维护一个lastIndex属性，记录上次匹配结束的位置
2. 每次匹配都会从lastIndex开始，而不是从字符串开头
3. 匹配失败时，lastIndex会自动重置为0

在DOMPurify的实现中，净化过程会多次使用同一个正则表达式实例来检查不同的URI。由于lastIndex没有被手动重置，导致后续匹配的起始位置不正确，从而产生不一致的过滤结果。

问题定位

具体到代码层面，问题出现在以下关键点：

1. DOMPurify使用RegExp.prototype.test方法来检查URI是否匹配允许的模式
2. 通过unapply函数将方法调用转换为函数式调用
3. 在多次调用过程中，正则表达式对象的lastIndex状态被保留
4. 当连续检查相似URI时，可能出现第一次匹配成功，第二次因lastIndex位置不对而失败，第三次又成功的情况

解决方案

针对这个问题，开发者提出了两种可行的解决方案：

1. 每次使用新正则表达式实例：确保每次检查都使用全新的正则表达式对象，避免状态共享

2. 修改unapply函数：在函数调用前检查thisArg是否为RegExp实例，如果是则重置lastIndex为0

function unapply(func) {
    return (thisArg, ...args) => {
        if (thisArg instanceof RegExp) {
            thisArg.lastIndex = 0;
        }
        return apply(func, thisArg, args);
    }
}

安全影响评估

这个问题虽然看似是功能性问题，但从安全角度来看：

1. 可能导致应该被过滤的危险URI被错误放行
2. 也可能导致合法的URI被错误过滤
3. 行为的不确定性增加了安全风险
4. 在严格的XSS防护场景下可能造成安全隐患

最佳实践建议

基于此问题的分析，建议开发者在类似场景中：

1. 谨慎使用正则表达式的全局标志，特别是在安全敏感的过滤场景
2. 对于需要重用正则表达式的情况，确保在每次使用前重置lastIndex
3. 考虑使用无状态的字符串匹配方法替代正则表达式
4. 在安全过滤逻辑中避免依赖有状态的匹配机制

总结

这个案例展示了JavaScript语言特性在安全过滤场景中可能带来的隐患。DOMPurify作为安全防护库，其每个细节都可能影响最终的安全效果。开发者在使用类似工具时，不仅需要了解其配置方式，还应该深入理解底层实现机制，才能确保安全防护的可靠性。