Python WAF 规则的正则与 Lua 脚本编写

re.search 更安全，因其扫描整个字符串匹配恶意模式，而 re.match 仅从开头匹配易漏掉中间或末尾的攻击载荷，且需配合 re.dotall 和 re.ignorecase 等标志确保跨行、大小写不敏感匹配。

python WAF 规则里写正则，为什么 re.search 比 re.match 更安全？

WAF 规则常要检测请求体或 header 里是否含恶意模式，比如 sql 注入特征 ' OR 1=1。用 re.match 容易漏掉——它只从字符串开头匹配，而攻击载荷可能藏在中间或末尾。

• re.search 扫描整个字符串，适合检测任意位置的关键词、编码绕过（如 %20OR%201%3D1）
• 注意默认不支持多行匹配，如果规则要跨 n 检查（比如 POST body），得加 re.DOTALL 标志
• 避免用 ^ 和 $ 锚定，除非你明确只关心整行内容；WAF 输入不是“一行一请求”
• 正则本身要加 re.IGNORECASE，否则 union select 和 UNION SELECT 就漏一个

if re.search(r"(?i)unions+select", payload, re.DOTALL):     block_request()

lua 脚本在 openresty WAF 中怎么访问原始请求体？

OpenResty 的 ngx.req.read_body() 不是自动触发的，很多规则写了 ngx.var.request_body 却返回空——因为 body 没被读取，或者被其他模块提前消费了（比如 lua_need_request_body on 没配，或用了 proxy_pass 后 body 被清空）。

• 必须在 access_by_lua_block 阶段调用 ngx.req.read_body()，不能只依赖配置项
• 读取后用 ngx.var.request_body 取值；若为空，检查是否被 client_max_body_size 截断，或是否超过 client_body_buffer_size 导致写入临时文件（此时要用 ngx.req.get_body_data() 或读文件）
• 请求体可能被编码（application/x-www-form-urlencoded 或 multipart/form-data），直接正则容易失效；简单场景可先用 ngx.unescape_uri 解码 URL 编码部分，复杂结构建议交给专用解析器

Python 和 Lua 规则共存时，URL 解码顺序不一致导致绕过

Python 规则通常在 WAF 入口层处理已解码的字符串（比如 flask/Werkzeug 自动解码），而 Lua 在 nginx 层看到的是原始字节流。同一段 payload %2527（即 %27 的二次编码），Python 可能解成 '，Lua 还是原样——规则如果只在 Lua 里写 %'%，就匹配不到。

• 统一在最外层做一次标准解码：Lua 用 ngx.unescape_uri(ngx.var.args) 或对 body 做类似处理；Python 侧确认框架没多解一次（比如 Werkzeug 默认解一次，但某些中间件会再解）
• 不要依赖“自动解码”，显式控制解码轮数；二次编码绕过很常见，规则应覆盖 %2527、%u0027 等变体
• 如果用正则匹配，把常见编码形式全列进 pattern，比如 r"(%27|%2527|%u0027|x27)"，别只写 '

性能敏感场景下，Lua 正则比 Python 快，但别滥用 ngx.re.match

OpenResty 的 ngx.re.match 是 PCRE 编译后复用的，确实比 Python 的 re 模块快；但它默认开启 JIT，遇到回溯型正则（比如 (a+)+b）可能卡住 worker 进程，引发超时或拒绝服务。

立即学习“Python免费学习笔记（深入）”；

• 写正则时禁用贪婪量词嵌套，用原子组或占有性量词（(?>...)）；实在不行，用字符串查找（String.find）代替复杂正则
• Python 规则若跑在独立进程（如用 subprocess 调外部脚本），IPC 开销远大于正则本身，不如把逻辑移到 Lua 层
• Lua 里不要在循环中反复编译正则，用 local re = require "resty.core.Regex" + regex.new(..., "j") 预编译并缓存

规则越靠近网络边缘越高效，但越靠近业务逻辑越准确——平衡点往往不在语言本身，而在你愿不愿意为一次误报多写两行解码逻辑。