waf怎样添加强制类型转换
-
上一篇
-
下一篇
- 最近发表
- 随机阅读
- 搜索
-
- 友情链接
-
waf怎样添加强制类型转换
WAF的添加规则引擎，本质上是强制个“类型敏感”的家伙。你给它传个字符串“1”，类型它可能当成数字1处理；传个数组，转换它可能只取第一个元素。添加这种隐式转换，强制正是类型绕过漏洞的温床。所以，转换强制类型转换不是添加可选项，是强制安全基线。 拿最常见的类型SQL注入防护举例。你写规则匹配`id=1 AND 1=1`，转换攻击者改成`id=1a AND 1=1`——如果WAF把`1a`当字符串，添加正则可能漏掉，强制但数据库却会把它转成数字1继续执行。类型这时候，强制转换就派上用场了。你得在规则里明确告诉WAF：这个参数必须是整数，不是就拒绝。 具体怎么加？看你的WAF平台。如果是ModSecurity，用`@validate`指令配合类型检查。比如： ``` SecRule ARGS:id "@validate @int" "id:100,deny,msg:'ID必须为整数'" ``` 这行规则强制`id`参数必须通过整数验证，带字母的直接拦截。别小看这个`@int`——它背后是严格的正则加范围检查，比你自己写`^\d+$`可靠得多。 OpenResty系的WAF更灵活，直接在Lua代码里用`tonumber()`。但注意，`tonumber("0x1A")`能返回26，这就有风险了。你得再加一层校验： ```lua local raw_id = ngx.var.arg_id local num_id = tonumber(raw_id) if not num_id or tostring(num_id) ~= raw_id then ngx.exit(400) end ``` 这段代码够狠——它要求原始字符串和转换后的字符串完全一致，`1a`、`0x1A`、`1.0`全过不了。代价是性能，每次请求多两次类型转换，但值得。 商业WAF的配置界面通常有“参数类型”下拉框，选“整数”或“字符串”就行。但这里有个坑：很多团队只给`id`、`page`这类明显数字的字段加，却忘了`sort`、`order`这类同样会被拼进SQL的字段。我见过某电商平台被拖库，就是因为`order=desc`被改成`order=(SELECT...)`——WAF没强制它是字符串，数据库却把它当成了列名。 强制类型转换还有个隐藏好处：能防缓存投毒。攻击者构造`?id=1`和`?id=1.0`，如果WAF不强制类型，CDN可能缓存两个不同版本，但后端SQL却都查询id=1，导致数据错乱。强制转换后，`1.0`直接400，缓存键就干净了。 别过度设计。有些字段天生就是“任意字符串”，比如搜索关键词、留言内容。这时候强制类型转换反而会误伤。你得区分“必须严格的”和“可以宽松的”——前者用白名单类型，后者用黑名单字符过滤。但记住，黑名单永远有漏网之鱼，能转类型的尽量转。 最后说个实战细节。强制类型转换的报错页面别返回详细原因，统一返回400。否则攻击者能从错误信息里推断出WAF规则结构。我见过一个团队把“类型不匹配”详细到`expected integer, got string`，结果对方用这个信息精准构造了绕过payload。返回`Bad Request`就好，简单粗暴。 规则上线前，拿Burp Suite跑一遍边界值：空字符串、超长数字、负数、浮点数、Unicode数字（比如阿拉伯文数字）。大多数WAF的`@int`验证对Unicode数字会放行，但后端数据库不一定认——这又是新的绕过点。所以，自己写正则时，别用`\d`，用`[0-9]`，前者在PCRE里默认就匹配Unicode数字。 强制类型转换不是银弹。它解决的是“类型混淆”类攻击，但SQL注入还有编码绕过、注释符绕过等手法。但作为第一道防线，它至少把最基础的攻击面堵死了。剩下的，交给参数化查询和数据库权限控制——那是另一篇文章的事了。
上一篇
下一篇