ThinkPHP 6 的 validate 拦不住正则绕过，因其仅校验输入值是否匹配正则，不校验正则本身安全性；攻击者可提交含 (*COMMIT) 等恶意 PCRE 指令的正则，导致 preg_match 注入。
ThinkPHP 6 的 validate 为什么拦不住正则绕过？
因为默认的 validate 规则只校验格式，不阻止恶意模式本身。比如你写 regex:/<script>.*?<\/script>/i</script>，TP 不会报错——它只管传入的值是否匹配这个正则，而不管这个正则是不是在主动诱导 XSS 或 SSRF。
真正危险的是：攻击者把恶意正则当参数传进来，再被你的代码动态拼进 preg_match，造成 PCRE 注入（如 (*COMMIT)、(*EXEC) 等控制指令执行）。
- 常见错误现象：
preg_match($user_input_regex, $data)直接执行，报错PREG_BAD_PATTERN反而是好事；更糟的是静默执行非预期逻辑 - 使用场景：后台允许用户自定义搜索规则、导出字段过滤、日志关键词高亮等需运行时编译正则的地方
- 必须禁止的元字符组合：
(*...、??（非贪婪修饰符在某些上下文可触发回溯爆炸）、\K、(?{...})、(??{...}) - 推荐做法：用白名单预检正则字符串，而非尝试“修复”用户输入
如何安全地校验用户提交的正则表达式？
别自己写正则去“过滤”正则——那是在正则里写正则，极易漏判。直接用 PHP 原生函数做语法预检最可靠。
- 先调用
preg_last_error()清空错误状态 - 用
@preg_match($user_regex, '')尝试空匹配（加@抑制警告，但必须后续检查preg_last_error()） - 只接受返回值为
false且preg_last_error() === PREG_NO_ERROR的表达式 - 额外排除含
\x00、换行符、不可见控制字符的字符串（这些可能干扰 PCRE 解析器）
示例片段：
立即学习“PHP免费学习笔记（深入）”；
if (strpos($user_regex, "\x00") !== false || preg_match('/[\r\n\x01-\x08\x0b\x0c\x0e-\x1f]/', $user_regex)) {
throw new InvalidArgumentException('Invalid regex pattern');
}
@preg_match($user_regex, '');
if (preg_last_error() !== PREG_NO_ERROR) {
throw new InvalidArgumentException('Unsafe or malformed regex');
}
ThinkPHP 自定义验证规则中怎么嵌入正则安全校验？
不要在 rule 数组里硬写 regex => $userInput，而应把校验逻辑收口到独立方法中，确保每次执行前都走预检。
- 在验证器类里定义一个方法，比如
checkSafeRegex，里面完成上述预检流程 - 在
rule中引用为：['safe_regex' => 'checkSafeRegex'] - 注意：TP 的
regex内置规则不支持传入变量，它只认字面量字符串，所以必须绕开内置规则，走自定义方法 - 如果用了
scene切换规则，请确认该 scene 下没有意外启用原始regex规则
为什么不能依赖中间件或全局过滤做正则注入防护？
因为正则注入只发生在你显式调用 preg_match、preg_replace 等函数时，不是所有请求参数都会走到那里。中间件无差别处理反而容易误杀正常业务数据（比如合法的 Markdown 正则、数学公式符号）。
- 防护点必须紧贴实际使用位置：哪个控制器方法调用了
preg_*，就在哪做预检 - 全局
input过滤无法识别“这段字符串即将被当成正则用”，它只能按字段名粗筛，不可靠 - TP 的
filter参数机制对正则无意义——htmlspecialchars对(*COMMIT)完全无效
最易被忽略的一点：正则字符串可能来自数据库、缓存或第三方 API，不只是 HTTP 请求参数。只要来源不可信，就得过一遍预检。
