1. 项目概述为什么正则表达式是XSS防护的“手术刀”在Web安全领域跨站脚本攻击XSS就像潜伏在用户输入里的隐形刺客它利用网站对用户提交数据的不充分过滤将恶意脚本注入到页面中从而窃取用户Cookie、会话令牌甚至进行钓鱼欺诈。面对这种威胁开发者需要一套精准、高效的防御工具。正则表达式正是这样一把“手术刀”——它不像某些重型安全框架那样大而全但能在特定的、需要精细处理的场景下实现快速、轻量且高度可控的过滤。很多新手一提到XSS防护可能首先想到的是使用现成的安全库这当然没错。但在实际开发中尤其是在处理遗留系统、性能敏感接口或者需要对特定格式如富文本编辑器中的部分HTML标签进行“外科手术式”清理时正则表达式展现出了不可替代的灵活性。它允许你精确地定义什么是“允许的”什么是“必须剔除的”这种控制力是通用库有时难以完全满足的。当然我必须强调正则表达式并非XSS防护的银弹它更适合作为深度防御体系中的一环与内容安全策略CSP、输出编码等策略协同工作。这篇文章我将结合自己十多年在前后端安全对抗中的经验拆解10个经过实战检验的正则表达式过滤技巧。这些技巧不是空中楼阁的理论而是可以直接嵌入到你代码中的实用模式。我会详细解释每个正则背后的设计思路、它针对的XSS攻击向量以及在实际使用中可能遇到的“坑”。无论你是前端工程师、后端开发者还是安全爱好者都能从中找到即拿即用的防御策略。2. 核心思路从“黑名单”到“白名单”的思维转变在深入具体技巧之前我们必须确立一个核心安全原则白名单优于黑名单。这是所有有效输入过滤的基石。黑名单过滤的思路是我定义一份“坏东西”的列表比如script,javascript:然后在用户输入中查找并删除或转义这些坏东西。这种方法的问题在于攻击者的创造力是无穷的。他们可以通过大小写变换、插入空白字符、编码、利用浏览器解析特性等无数种方式绕过你的黑名单。例如你过滤了script攻击者可能使用ScRiPt、scrscriptipt利用你的过滤逻辑自身或利用其他标签的事件属性如img srcx onerroralert(1)。白名单过滤则完全相反。它定义一份“允许的东西”的列表除此之外的一切都默认拒绝。在XSS防护的语境下这意味着我们只允许一组极其有限的、安全的HTML标签和属性其他所有内容要么被删除要么被转义成纯文本。这种方式的防御纵深要深得多。因为攻击者必须让他的载荷同时满足你白名单中的所有条件这极大地增加了攻击难度。我们接下来要讨论的10个正则技巧其核心思想都是服务于“白名单”策略。它们的目标是1识别出潜在的威胁模式2在允许的极小范围内进行精确的匹配和替换。记住我们的正则表达式更多是用来“找到危险并处理它”或者“只保留已知的安全部分”而不是试图穷举所有危险的可能。3. 10个高效正则过滤技巧深度解析下面我将逐一拆解这10个技巧每个技巧都会包含攻击示例、正则表达式、原理剖析、以及最重要的——注意事项和避坑指南。3.1 技巧一剥离script标签及其内容包括变体这是最直接但也最需要小心处理的一环。攻击示例直接注入scriptalert(XSS)/script大小写混淆ScRiPtalert(1)/ScRiPt加入无效属性script x’y’malicious code/script正则表达式\\s*script[^]*.*?\\s*/\\s*script\\s*让我们拆解这个正则\\s*script匹配左尖括号后跟零个或多个空白字符然后是script。\\s*处理了script和 script这种情况。[^]*匹配不是右尖括号的任何字符零次或多次直到遇到。这允许标签内存在属性。.*?非贪婪匹配匹配任意字符包括换行符如果使用了/s标志最少次数直到…\\s*/\\s*script\\s*匹配闭合标签同样允许标签名前后有空白。注意事项使用不区分大小写标志在大多数正则引擎中如JavaScript的/iPython的re.IGNORECASE确保匹配所有大小写变体。警惕嵌套与畸形标签上面的正则无法处理像scrscriptipt这样的嵌套攻击。攻击者可能利用你第一次过滤后剩余的字符重新组合成攻击载荷。更稳健的做法是进行循环过滤直到没有匹配项为止或者结合上下文进行更严格的解析。性能考虑.*?是非贪婪匹配通常性能优于贪婪匹配.*但在处理极长的畸形输入时仍需注意。对于服务端过滤应设置超时或长度限制。实操心得我通常会把这个匹配作为一个初步的、强力的清洗步骤。但在富文本场景它可能过于粗暴会误伤合法的script标签内容虽然极少见。因此它的使用场景主要是对纯文本或仅允许简单格式的输入进行预处理。3.2 技巧二过滤危险的HTML事件属性如onclick, onerrorXSS攻击常常不直接使用script标签而是利用HTML元素的事件处理器属性。攻击示例img srcx onerroralert(1)svg onloadalert(XSS)a href# onclickstealCookie()点击/a正则表达式\\son\\w\\s*\\s*([\]).*?\\1\\son匹配至少一个空白字符后接on这确保了匹配的是属性而不是标签名或内容中的字符。\\w匹配一个或多个单词字符字母、数字、下划线覆盖了onclick、onerror、onload等所有事件。\\s*\\s*匹配等号前后允许有空白。([\])捕获分组匹配单引号或双引号。.*?非贪婪匹配引号内的任何内容。\\1反向引用匹配与开头相同的引号确保匹配完整的属性值对。注意事项属性值内的引号转义这个正则无法完美处理属性值内包含转义引号的情况例如onclickalert(\hi\)。在复杂的HTML解析场景这可能导致匹配错误。对于高安全要求场景建议使用专门的HTML解析器如DOMPurify的配置来移除属性而不是依赖正则。空白字符变体除了空格制表符\\t、换行符\\n等也可能出现在on之前。\\s通常能覆盖但需确认你所用语言的正则引擎对\\s的定义。并非所有on开头都危险极少数情况下可能有自定义的非标准属性以on开头。但在XSS防护的白名单策略下我们应该默认所有on*属性都是危险的除非有非常明确的业务理由需要保留某个特定属性这极其罕见。避坑指南在实际替换时不要仅仅删除onclick“...”中的等号或值而应该删除整个属性键值对。否则可能留下畸形的onclick某些浏览器可能仍会执行。3.3 技巧三阻断javascript:伪协议链接这是另一种常见的XSS注入点常用于a标签的href属性、iframe的src等。攻击示例a hrefjavascript:alert(document.cookie)免费领取/aiframe srcjavascript:alert(1)大小写与编码a hrefJaVaScRiPt:alert(1)或javascript:%61%6c%65%72%74%28%31%29URL编码正则表达式\\b[jJ][aA][vV][aA][sS][cC][rR][iI][pP][tT]\\s*:这个正则通过每个字符的大小写选项来匹配所有大小写变体。\\b确保匹配的是单词边界避免匹配到myjavascript:book这样的文本。\\s*处理javascript:后面可能有空格的情况。更健壮的版本考虑编码 要应对简单的URL编码我们需要先解码再匹配。但直接在正则里处理所有编码很复杂。一个务实的做法是先对输入值进行URL解码然后再应用上述正则进行匹配。在很多Web框架中用户输入可能已经被部分解码所以确保你在正确的数据层级上进行检查。注意事项不要仅匹配javascript:攻击者可能使用data:、vbscript:旧IE等其它危险的伪协议。一个更全面的白名单是只允许http://、https://、mailto:、tel:等已知安全的协议。对应的正则可以是/^\\s*(?!(https?:|mailto:|tel:|ftp:|#|\\/))[a-z0-9.-]:/i这个负向前瞻匹配任何不是安全协议开头的协议字符串。上下文相关javascript:只有在允许URL的属性中才是危险的。如果你在过滤纯文本它可能只是一个无害的字符串。因此这个过滤最好在你知道上下文是URL属性时应用。3.4 技巧四清理style标签与内联样式中的表达式CSS也可以被利用来执行JavaScript在旧版IE中通过expression()或现代浏览器中通过CSS注入窃取数据。攻击示例stylebody { background-image: url(\javascript:alert(1)\); }/stylediv style\width: expression(alert(XSS));\(IE5-IE7)styleimport \http://evil.com/malicious.css\;/style正则表达式针对expression和url(javascript:)expression\\s*\\([^)]*\\\)|url\\s*\\(\\s*[\]?\\s*javascript:expression\\s*\\([^)]*\\)匹配expression(及其括号内的任何内容直到下一个)。这是一个简化可能无法处理嵌套括号。|或。url\\s*\\(\\s*[\]?\\s*javascript:匹配url(后跟可选空白和引号然后是javascript:。注意事项CSS的复杂性CSS语法复杂正则很难完美解析。例如url()中的内容可以是编码的注释可以绕过某些匹配。对于允许用户自定义完整样式如博客主题的高风险场景强烈建议不要使用正则而应使用专门的CSS安全解析器或沙箱。白名单样式属性对于内联样式style\...\更安全的做法是定义一个允许的CSS属性和值的白名单例如只允许color,font-size,margin等并且对值进行严格的验证如颜色值必须是hex或rgb尺寸必须是数字加单位。这超出了简单正则的范畴通常需要一个小型的解析器。实操心得在大多数用户生成内容场景我建议直接禁止style标签和style属性除非有强烈的产品需求。如果必须允许则将其限制在一个极其有限的白名单内并考虑使用像CSP style-src这样的浏览器级防护作为最后一道防线。3.5 技巧五过滤iframe,embed,object等外部资源标签这些标签可以直接引入外部资源是导致钓鱼、恶意软件分发和点击劫持的常见载体。攻击示例iframe src\http://evil.com/phish.html\ width\100%\ height\500\/iframeembed src\http://evil.com/flash.exp\object data\http://evil.com/data.pdf\param name\allowScriptAccess\ value\always\/object正则表达式匹配标签头\\s*(iframe|embed|object|frame|frameset|meta)[\\s]这个正则匹配这些危险标签的开始部分到第一个或空白后。匹配到之后常见的处理方式是直接删除整个标签对及其内容。对于iframe和object需要像处理script一样考虑匹配闭合标签。注意事项内容移除的挑战像iframe这样的标签有内容模型简单地匹配开始和结束标签来删除内容可能比较棘手因为其内部可能包含合法的HTML。如果决定删除最安全的方法是使用一个能理解HTML结构的解析器来提取和移除整个节点。并非绝对邪恶iframe常用于嵌入安全来源的内容如YouTube视频、地图。因此更精细的策略是如果允许这些标签则必须对src、data等属性进行严格的源白名单验证。例如只允许src属性以特定的可信域名开头。meta标签的重定向meta http-equiv\refresh\ content\0;urlhttp://evil.com\可以用于客户端重定向。通常也应禁止或严格过滤。3.6 技巧六中和HTML注释与CDATA段中的恶意代码HTML注释!-- --和CDATA段![CDATA[ ]]本身不执行脚本但攻击者可能利用它们来隐藏恶意载荷或者干扰后续过滤逻辑的解析。攻击示例!-- scriptalert(1)/script --可能被某些不严谨的过滤器忽略script!--\nalert(1)\n//--/script利用注释绕过对/script的检测![CDATA[scriptalert(1)/script]]在XHTML或SVG上下文中正则表达式移除注释!--.*?--注意标准的HTML注释是不允许嵌套的且--不能出现在注释内容中。但这个简单的正则足以应对大多数情况。正则表达式移除CDATA!\\[CDATA\\[[\\s\\S]*?\\]\\][\\s\\S]*?可以匹配包括换行符在内的任何字符确保匹配完整的CDATA段。注意事项性能与贪婪匹配使用非贪婪匹配.*?和[\\s\\S]*?以防止在包含多个注释/CDATA的大文本中匹配过多。移除 vs. 保留在清洗用户HTML时通常安全的选择是直接移除注释和CDATA段因为它们对内容的展示没有影响。但在处理XML格式如SVG时CDATA可能有其合法用途需要根据上下文判断。作为绕过手段永远不要依赖“先移除注释再过滤其他”这种顺序。攻击者可能精心构造输入使得在移除注释后之前被注释分隔开的字符组合成新的攻击载荷。最佳实践是将输入作为一个整体进行解析和清洗或者使用多次迭代过滤直到输入稳定。3.7 技巧七防御HTML实体编码绕过攻击者可能会对攻击载荷进行HTML实体编码以期绕过基于字符串匹配的过滤器因为浏览器在渲染前会解码这些实体。攻击示例lt;scriptgt;alert(1)lt;/scriptgt;解码后是scriptalert(1)/script#x3c;script#x3e;...十六进制实体#60;script#62;...十进制实体策略防御这种绕过的关键不是用更复杂的正则去匹配所有编码形式而是确保在正确的层级进行过滤。输入规范化在应用过滤逻辑之前先对输入进行一次标准的HTML实体解码。例如在Python中可以使用html.unescape()在JavaScript中可以用一个textareaDOM元素的innerHTML来解码。在解码后的文本上应用过滤规则这样你的正则表达式面对的就是“明文”的攻击载荷上面提到的技巧就能生效。输出编码过滤后的内容在输出到HTML上下文时必须根据上下文进行正确的编码如将转义为lt;。这才是防止XSS的根本。注意事项避免双重解码小心不要对同一段文本重复解码否则可能将正常的amp;表示符号错误地解码。编码的多样性除了常见的lt;、gt;、amp;还有数字形式#60;、十六进制形式#x3c;以及名称繁多的字符实体。使用标准库进行解码是最可靠的方式。一个错误示例试图写一个匹配所有可能编码形式的的正则会非常复杂且容易出错/(?:|lt;|#x3c;|#60;|#x003c;)/i。这绝非良策。3.8 技巧八利用正则进行最小化白名单属性过滤对于允许保留某些HTML标签如a、img、strong的场景我们必须对其属性进行白名单过滤。思路我们不直接匹配危险属性而是定义允许的属性并移除其他所有属性。这通常需要分步进行匹配出标签。对于每个标签匹配出所有属性。检查每个属性名是否在白名单内。对于白名单内的属性进一步验证其值例如href必须以http://或https://开头。重建标签。这个过程用单个正则难以完成通常需要结合编程逻辑。但正则在其中扮演关键角色步骤1匹配标签及其属性部分(\\w)(\\s[^]*)?(\\w)捕获标签名。(\\s[^]*)?捕获可选的属性部分空白字符开始直到。步骤2匹配单个属性(\\w)\\s*\\s*(\([^\]*)\|([^]*)|([^\\s]))这个正则可以匹配keyvalue、key\value\、keyvalue三种形式。实操示例Python伪代码import re def sanitize_tag(tag_html): # 白名单标签名 - [允许的属性列表] whitelist { a: [href, title, target], img: [src, alt, title, width, height], strong: [], em: [], } # 匹配标签名和属性串 tag_match re.match(r(\\w)(\\s[^]*)?, tag_html) if not tag_match: return # 不是合法标签开头返回空或转义 tag_name tag_match.group(1).lower() attr_string tag_match.group(2) or if tag_name not in whitelist: return # 标签不在白名单移除整个标签需处理内容这里简化 allowed_attrs whitelist[tag_name] # 用于收集合法的属性键值对 safe_attrs [] # 匹配所有属性 attr_pattern re.compile(r(\\w)\\s*\\s*(\([^\]*)\|\([^\]*)\|([^\\s]))) for match in attr_pattern.finditer(attr_string): attr_name match.group(1).lower() # 获取属性值来自三个捕获组之一 attr_value match.group(3) or match.group(4) or match.group(5) if attr_name in allowed_attrs: # 对特定属性进行值验证例如href的协议白名单 if attr_name href or attr_name src: if not re.match(r^(https?:|mailto:|tel:|#|\\/), attr_value, re.I): continue # 跳过不符合协议的属性 # 对值进行HTML编码防止属性内注入 attr_value_escaped html.escape(attr_value, quoteTrue) safe_attrs.append(f{attr_name}\{attr_value_escaped}\) # 重建标签 if safe_attrs: return f{tag_name} {\ \.join(safe_attrs)} else: return f{tag_name}注意事项属性值内的引号上述简单正则无法处理属性值内包含转义引号如onclick\alert(\\\hi\\\)\的复杂情况。对于生产环境建议使用成熟的HTML解析库如Python的lxml.html.clean或JavaScript的DOMPurify来完成白名单过滤它们能更准确地处理HTML语法。布尔属性像checked、disabled这样的布尔属性没有值其存在即表示真。我们的正则需要能匹配它们。可以添加一个匹配模式(\\w)(?![^]*)来匹配没有等号的属性名。性能对大量或复杂的HTML进行逐标签、逐属性的正则解析可能比较耗时。对于高性能需求场景成熟的解析库通常是优化过的。3.9 技巧九检测和阻止数据URI滥用数据URIdata:允许将小文件内嵌在文档中但恶意数据URI可以携带JavaScript或HTML。攻击示例img src\data:image/svgxml;base64,PHN2ZyBvbmxvYWQ9ImFsZXJ0KDEpIj48L3N2Zz4\一个包含onload事件的SVG图像iframe src\data:text/html,scriptalert(1)/script\/iframe正则表达式识别数据URI\\s*data:\\s*([^;]);[^,]*,[\\s\\S]*这个正则匹配以data:开头后跟MIME类型、可选参数;base64和实际数据。更严格的匹配可以限制MIME类型。防护策略上下文禁止在绝大多数用户可控制的URL属性src,href中直接禁止data:协议。这是最简单有效的白名单策略的一部分。MIME类型白名单如果业务必须允许数据URI例如头像上传后预览则必须严格限制MIME类型。例如只允许image/png,image/jpeg,image/gif。\\s*data:\\s*image\\/(png|jpeg|gif);base64,[a-zA-Z0-9/]{0,2}这个正则只匹配Base64编码的PNG、JPEG、GIF图片数据URI。注意事项Base64验证即使MIME类型是图片也要确保后面的数据是合法的Base64编码。一些解析库在解码无效Base64时可能会抛出异常需妥善处理。大小限制数据URI会增大文档体积应强制限制其长度。性能影响内嵌大型数据URI会严重影响页面加载性能。3.10 技巧十综合运用——构建一个简单的多层正则过滤器没有任何一个正则能解决所有问题。在实际中我们需要构建一个防御层。下面是一个在服务器端以Python为例进行防御性过滤的简化流程示例它综合运用了上述多个技巧import re import html def naive_xss_filter(user_input): 一个简单的、基于正则的多层XSS过滤器。 警告此方法并非绝对安全适用于中低风险场景或作为补充措施。 高风险场景必须使用专门的HTML清理库。 if not user_input: return user_input # 第1层解码HTML实体让隐藏的威胁显形 decoded_input html.unescape(user_input) # 第2层移除危险的标签及其内容脚本、样式、框架等 dangerous_tags r(?:script|style|iframe|embed|object|frameset|frame|meta|link)[^]*.*?\\/\\1\\s* filtered re.sub(dangerous_tags, , decoded_input, flagsre.IGNORECASE | re.DOTALL) # 第3层移除所有事件处理器属性 (on*) filtered re.sub(r\\son\\w\\s*\\s*([\\]).*?\\1, , filtered, flagsre.IGNORECASE) # 第4层移除javascript:等危险协议假设在href/src上下文这里全局处理需谨慎 # 更佳实践是在构建具体标签时针对href/src属性单独验证。 filtered re.sub(r\\b(javascript|data|vbscript):, blocked:, filtered, flagsre.IGNORECASE) # 第5层移除CSS表达式和危险的url() filtered re.sub(rexpression\\s*\\([^)]*\\), , filtered, flagsre.IGNORECASE) filtered re.sub(rurl\\s*\\(\\s*[\\]?\\s*javascript:, url(blocked:, filtered, flagsre.IGNORECASE) # 第6层移除HTML注释和CDATA避免干扰 filtered re.sub(r!--.*?--, , filtered, flagsre.DOTALL) filtered re.sub(r!\\[CDATA\\[[\\s\\S]*?\\]\\], , filtered) # 第7层最终输出前对保留的HTML字符进行编码如果最终输出上下文是HTML # 注意如果过滤后我们允许一些安全标签则不能对整个字符串进行html转义。 # 这里假设我们想要一个纯文本输出或者后续会由更安全的库处理。 # final_output html.escape(filtered) # 如果最终需要纯文本 return filtered # 使用示例 dirty_input 测试scriptalert(1)/script和img srcx onerroralert(2)以及a hrefjavascript:void(0)链接/a clean_output naive_xss_filter(dirty_input) print(clean_output) # 输出测试和img srcx 以及a hrefblocked:void(0)链接/a重要警告这个naive_xss_filter函数只是一个教学示例用于演示多层正则过滤的思路。它存在诸多缺陷正则无法完全理解HTML语法结构可能被复杂的标签嵌套、注释分割等方式绕过。全局替换javascript:可能会误伤文本内容。它没有实现真正的属性白名单img标签的src属性虽然移除了onerror但src\x\仍然存在可能引发404或用于其他探测。性能可能不是最优的。因此对于生产环境尤其是允许用户输入HTML的场景终极建议是使用业界久经考验的专用库例如JavaScript (浏览器/Node.js):DOMPurify是目前最受推荐的选择。它速度快配置灵活能处理各种边缘情况。Python: 可以使用lxml.html.clean模块的Cleaner类或者bleach库。Java: 考虑 OWASP Java HTML Sanitizer。PHP: 可以使用htmlpurifier库。这些库基于真正的HTML解析器构建能构建安全的DOM树然后根据白名单进行序列化其安全性和可靠性远非正则表达式可比。4. 正则表达式在XSS防护中的定位与最佳实践经过以上十个技巧的拆解我们应该对正则表达式在XSS防护中的作用有了更清醒的认识。它是一把锋利的“手术刀”但并非“万能钥匙”。下面总结一下它的正确使用姿势和最佳实践。4.1 正则的适用场景与局限适用场景预处理与快速拦截在请求入口处对明显的恶意模式如完整的script标签、javascript:协议进行快速匹配和拦截可以作为WAFWeb应用防火墙规则的一部分。特定字段的格式验证对于非HTML字段如用户名、邮箱、电话号码使用正则进行严格的格式白名单验证例如只允许字母数字和少数符号这本身就能消除很多注入风险。辅助性清洗在已经使用专业库进行主要清洗之后针对某些已知的、库可能未默认处理的非常规攻击向量使用正则进行补充过滤。日志分析与威胁检测在日志中扫描匹配XSS攻击模式的正则表达式用于安全审计和攻击发现。固有局限上下文无知正则不知道它匹配的字符串是在HTML标签内、属性值内、JavaScript字符串内还是CSS规则内。不同上下文的转义规则完全不同。语法复杂性HTML、CSS、JavaScript语法极其复杂存在大量边缘情况和浏览器怪异模式正则难以完美建模。绕过风险正如前文多次提到的有经验的攻击者可以通过编码、嵌套、利用解析差异等方式构造绕过正则过滤的载荷。维护成本一个复杂的正则表达式难以阅读、调试和维护。随着新攻击手法的出现规则集需要不断更新。4.2 构建纵深防御体系正则只是其中一环真正的XSS防护是一个体系正则可以扮演一个角色但绝不能孤军奋战。一个健壮的防御体系应包括输入验证白名单在业务逻辑层对输入数据的类型、长度、格式、范围进行严格检查。这是第一道防线。正则在这里用于格式验证非常合适。输出编码最关键根据数据将要放置的输出上下文HTML正文、HTML属性、JavaScript、CSS、URL进行正确的编码或转义。HTML正文将,,,\,转义为HTML实体。HTML属性同上尤其注意属性值要用引号括起来。JavaScript将数据放入JS字符串时转义\\,,\, 换行符并使用JSON.stringify()。CSS对非字母数字字符进行编码。URL参数使用encodeURIComponent()。永远不要相信“已过滤”的数据输出时编码是必须的。内容安全策略CSP这是一个重要的浏览器端缓解措施。通过HTTP头Content-Security-Policy你可以告诉浏览器只允许加载来自特定源的脚本、样式、图片等。即使攻击者成功注入了脚本如果源不在白名单内浏览器也不会执行。CSP能极大增加XSS攻击的难度。使用安全的框架和库现代Web框架如React, Vue, Angular通常提供自动的上下文相关输出编码。对于用户生成的HTML使用前面提到的专业消毒库如DOMPurify。HTTPOnly Cookie将敏感Cookie标记为HttpOnly这样JavaScript就无法通过document.cookie访问它即使发生XSS也能减轻会话被盗的损失。正则过滤作为补充在特定的、可控的环节使用精心设计的正则作为上述措施的补充。4.3 写给开发者的实操清单当你需要在项目中使用正则进行XSS防护时请遵循以下清单[ ]明确需求我到底要过滤什么是纯文本中的片段还是允许有限HTML目标输出上下文是什么[ ]选择策略优先考虑输出编码。如果必须允许部分HTML优先选择成熟的白名单消毒库如DOMPurify。[ ]如果必须用正则[ ]采用白名单思维思考“我只允许什么”而不是“我要阻止什么”。[ ]测试绕过用以下模式测试你的正则大小写变化 (ScRiPt)插入空白/换行 (script\\n)HTML实体编码 (lt;)注释分割 (scr!--test--ipt)无效属性 (script x\y\)非常规引号或无需引号 (onclickalert(1))利用正则引擎特性如.是否匹配换行[ ]进行规范化在过滤前先对输入进行标准的HTML解码和URL解码。[ ]多次迭代考虑循环应用过滤规则直到输入不再变化以防嵌套绕过。[ ]记录与监控记录被过滤掉的输入样本用于安全分析和规则改进。[ ]绝不拼接永远不要用字符串拼接的方式将用户输入和HTML/JS代码组合。始终使用框架的模板引擎或安全的DOM操作方法。[ ]设置CSP即使你觉得前端万无一失也请配置一个严格的CSP作为最后的安全网。正则表达式在XSS防护中是一把双刃剑。它强大而灵活能快速解决特定问题但过度依赖或使用不当会带来虚假的安全感。理解其原理明确其边界将它放在纵深防御体系中正确的位置才能让它真正为你的Web应用保驾护航。记住安全没有银弹唯有持续的学习、谨慎的设计和深度的防御。
