转义、黑名单、前端校验为什么这三样都挡不住注入网络安全实战 90 天 · Week 3 注入风险 | 难度 ★★★ 进阶 | 关键词输入转义 黑名单缺陷 前端校验 纵深防御 类型约束前面几篇的验证在低防护级别下全部成立。把防护级别调高再试payload 会大面积失效——但这不等于安全。这篇逐层拆解三类常见防护为什么失效以及真正应该落在哪一层。全程在自建靶场进行只做只读验证。一、三类防护的定位先说结论转义、黑名单、前端校验都属于「在错误的位置上做正确的事」。它们各自挡得住一部分输入但都挡不住「同一件事换一种表达」。防护手段作用位置典型失效原因输入转义应用代码层只对字符串生效数字型参数不受影响关键字黑名单应用或网关层规则基于字符串匹配语义等价写法数量无限前端校验浏览器层前端从来不是安全边界请求可以直接构造说明文中所有验证都在本机 Docker 中的 DVWA 靶场完成属代码审计与自查练习。真实系统上的同类验证必须在书面授权范围内进行并且只做只读判断不修改任何数据。二、第一层失效转义只对字符串生效把防护级别调高再跑一遍前面用过的写法。页面不再报错但这不是修好了而是字符被处理了。bash1 OR 11 $id mysqli_real_escape_string($GLOBALS[___mysqli_ston], $id);单引号前面被加了反斜杠引号再也闭合不了整段 payload 退化成普通字符串。字符型注入在这里确实被掐断了。2.1 但这不代表这个点安全转义函数处理的是「字符串里的特殊字符」。如果参数最终被当作数字使用字符串层的处理完全不参与——这就是下一节要看的入口。这是我这一周最大的认知转变看到页面不报错就以为没有漏洞是最容易犯的错。三、第二层失效前端限制不构成边界高防护级别下前端做成了一个下拉框只能从 1 到 5 里选。看着像限制但这层限制运行在浏览器里。请求是客户端发出的客户端可以任意构造。bash# 用拦截工具修改请求体后重放id1→id1OR11数字型参数不需要引号闭合转义对它完全没有作用。改完转发一次返回全部记录。前端校验的价值是改善体验——提前提示用户输入有误减少无效请求。前端校验的安全价值是零。任何依赖前端的校验等价于没有校验。后端必须独立做一遍完整校验且不假设前端已经做过。四、第三层失效黑名单的写法数量是无限的很多自研规则的本质是一张关键字黑名单用字符串匹配去拦。问题在于 SQL 语法本身对写法很宽容大小写不敏感、注释可插入、空白可替代、字符串有多个等价表示。这四条加起来等价写法的数量是无穷的。4.1 大小写bash1 uNiOn SeLeCt 1,2 --关键字本身不区分大小写规则如果只匹配全大写或全小写混写就能通过。4.2 注释插入bashUN/**/ION SEL/**/ECT 1,2 -- /*!UNION*/ /*!SELECT*/ 1,2 --把关键字从中间打断解析器会忽略注释、拼回完整关键字而字符串匹配看到的是一个不完整的词。第二行的内联注释更特殊——注释里的内容仍会被执行。4.3 编码层级bash → %27 一次编码 → %2527 两次编码 SELECT * FROM users WHERE name0x61646D696E编码的关键是「解码次数对齐」防护只看一次解码结果那就在原始请求里多编一层。十六进制是另一条路——数据库把 0x 开头的十六进制当作字符串字面量处理引号这个字符根本不会出现。4.4 空白替代bashUNION/**/SELECT UNION%09SELECT UNION%0aSELECT UNION(SELECT(1),(2))空格是最容易被过滤的字符但 SQL 对空白的要求很宽松注释、制表符、换行、乃至括号分组都能起到分隔作用。五、变形是有代价的看到这里容易产生一个误解变形越多越强。实际上每一次变形都在增加「应用自己解析不了」的风险——编码层数太多参数在业务逻辑里就变成了乱码tamper 规则挂太多请求形态已经不像正常流量触发拦截的概率反而上升。这条规律反过来也是防护思路只要把「同一语义的写法数量」压到很少变形就没得选。参数化查询之所以有效是因为它把「SQL 语法」和「数据」彻底分开了——数据变成数据之后无论怎么变形都只是字符串内容语法结构不会因为输入而改变。六、按投入产出比排的整改顺序优先级措施落地位置能挡住什么P0参数化查询 / 预编译绑定数据访问层从根上消除语法注入与输入写法无关P0参数类型强约束接口入参层数字型参数无论怎么变形都进不了 SQLP1数据库账号最小权限数据源配置即使注入成立影响半径被压缩P1错误信息统一处理全局异常层减少回显位抬高推断成本P2统一编码规范与规范化网关/框架层减少同一语义的多种字节表示P2基于语义的检测规则WAF比字符串黑名单更难被等价写法绕开七、踩坑记录坑点症状解决办法单引号被转义payload 全部失效但不报错换数字型入口或直接构造请求参数以为绕过了其实没通页面无变化可能存在多层过滤需要组合且要能稳定复现才算数变形规则挂太多请求被自身逻辑判为非法精准选一两个够用就停编码层数过多参数变成乱码逐层试确认服务端实际解码了几次请求被直接拒绝无业务响应降低速率、缩小改动幅度如实记录受阻情况「不报错」和「安全」是两件事混为一谈会直接漏掉漏洞。变形能否通过必须稳定复现才算结论。一次成功可能只是缓存或抖动。被拦截时如实记录受阻比强行变形更有价值——受阻本身就是一条防护到位的证据。八、小结转义、黑名单、前端校验三类防护失效原因各不相同但共同点是都在处理「输入的形状」而没处理「输入的身份」。SQL 语法的宽容度决定了等价写法的数量是无限的所以黑名单注定是军备竞赛。参数化查询把语法与数据彻底隔离是唯一从根上解决问题的做法其余都是纵深。变形有代价——越绕越容易被解析失败或触发拦截。这个代价是防守方可以主动利用的。下一篇把这一周的方法串起来在一个综合靶场里从识别走到验证最后落成一份可复现的记录。
转义、黑名单、前端校验为什么这三样都挡不住注入网络安全实战 90 天 · Week 3 注入风险 | 难度 ★★★ 进阶 | 关键词输入转义 黑名单缺陷 前端校验 纵深防御 类型约束前面几篇的验证在低防护级别下全部成立。把防护级别调高再试payload 会大面积失效——但这不等于安全。这篇逐层拆解三类常见防护为什么失效以及真正应该落在哪一层。全程在自建靶场进行只做只读验证。一、三类防护的定位先说结论转义、黑名单、前端校验都属于「在错误的位置上做正确的事」。它们各自挡得住一部分输入但都挡不住「同一件事换一种表达」。防护手段作用位置典型失效原因输入转义应用代码层只对字符串生效数字型参数不受影响关键字黑名单应用或网关层规则基于字符串匹配语义等价写法数量无限前端校验浏览器层前端从来不是安全边界请求可以直接构造说明文中所有验证都在本机 Docker 中的 DVWA 靶场完成属代码审计与自查练习。真实系统上的同类验证必须在书面授权范围内进行并且只做只读判断不修改任何数据。二、第一层失效转义只对字符串生效把防护级别调高再跑一遍前面用过的写法。页面不再报错但这不是修好了而是字符被处理了。bash1 OR 11 $id mysqli_real_escape_string($GLOBALS[___mysqli_ston], $id);单引号前面被加了反斜杠引号再也闭合不了整段 payload 退化成普通字符串。字符型注入在这里确实被掐断了。2.1 但这不代表这个点安全转义函数处理的是「字符串里的特殊字符」。如果参数最终被当作数字使用字符串层的处理完全不参与——这就是下一节要看的入口。这是我这一周最大的认知转变看到页面不报错就以为没有漏洞是最容易犯的错。三、第二层失效前端限制不构成边界高防护级别下前端做成了一个下拉框只能从 1 到 5 里选。看着像限制但这层限制运行在浏览器里。请求是客户端发出的客户端可以任意构造。bash# 用拦截工具修改请求体后重放id1→id1OR11数字型参数不需要引号闭合转义对它完全没有作用。改完转发一次返回全部记录。前端校验的价值是改善体验——提前提示用户输入有误减少无效请求。前端校验的安全价值是零。任何依赖前端的校验等价于没有校验。后端必须独立做一遍完整校验且不假设前端已经做过。四、第三层失效黑名单的写法数量是无限的很多自研规则的本质是一张关键字黑名单用字符串匹配去拦。问题在于 SQL 语法本身对写法很宽容大小写不敏感、注释可插入、空白可替代、字符串有多个等价表示。这四条加起来等价写法的数量是无穷的。4.1 大小写bash1 uNiOn SeLeCt 1,2 --关键字本身不区分大小写规则如果只匹配全大写或全小写混写就能通过。4.2 注释插入bashUN/**/ION SEL/**/ECT 1,2 -- /*!UNION*/ /*!SELECT*/ 1,2 --把关键字从中间打断解析器会忽略注释、拼回完整关键字而字符串匹配看到的是一个不完整的词。第二行的内联注释更特殊——注释里的内容仍会被执行。4.3 编码层级bash → %27 一次编码 → %2527 两次编码 SELECT * FROM users WHERE name0x61646D696E编码的关键是「解码次数对齐」防护只看一次解码结果那就在原始请求里多编一层。十六进制是另一条路——数据库把 0x 开头的十六进制当作字符串字面量处理引号这个字符根本不会出现。4.4 空白替代bashUNION/**/SELECT UNION%09SELECT UNION%0aSELECT UNION(SELECT(1),(2))空格是最容易被过滤的字符但 SQL 对空白的要求很宽松注释、制表符、换行、乃至括号分组都能起到分隔作用。五、变形是有代价的看到这里容易产生一个误解变形越多越强。实际上每一次变形都在增加「应用自己解析不了」的风险——编码层数太多参数在业务逻辑里就变成了乱码tamper 规则挂太多请求形态已经不像正常流量触发拦截的概率反而上升。这条规律反过来也是防护思路只要把「同一语义的写法数量」压到很少变形就没得选。参数化查询之所以有效是因为它把「SQL 语法」和「数据」彻底分开了——数据变成数据之后无论怎么变形都只是字符串内容语法结构不会因为输入而改变。六、按投入产出比排的整改顺序优先级措施落地位置能挡住什么P0参数化查询 / 预编译绑定数据访问层从根上消除语法注入与输入写法无关P0参数类型强约束接口入参层数字型参数无论怎么变形都进不了 SQLP1数据库账号最小权限数据源配置即使注入成立影响半径被压缩P1错误信息统一处理全局异常层减少回显位抬高推断成本P2统一编码规范与规范化网关/框架层减少同一语义的多种字节表示P2基于语义的检测规则WAF比字符串黑名单更难被等价写法绕开七、踩坑记录坑点症状解决办法单引号被转义payload 全部失效但不报错换数字型入口或直接构造请求参数以为绕过了其实没通页面无变化可能存在多层过滤需要组合且要能稳定复现才算数变形规则挂太多请求被自身逻辑判为非法精准选一两个够用就停编码层数过多参数变成乱码逐层试确认服务端实际解码了几次请求被直接拒绝无业务响应降低速率、缩小改动幅度如实记录受阻情况「不报错」和「安全」是两件事混为一谈会直接漏掉漏洞。变形能否通过必须稳定复现才算结论。一次成功可能只是缓存或抖动。被拦截时如实记录受阻比强行变形更有价值——受阻本身就是一条防护到位的证据。八、小结转义、黑名单、前端校验三类防护失效原因各不相同但共同点是都在处理「输入的形状」而没处理「输入的身份」。SQL 语法的宽容度决定了等价写法的数量是无限的所以黑名单注定是军备竞赛。参数化查询把语法与数据彻底隔离是唯一从根上解决问题的做法其余都是纵深。变形有代价——越绕越容易被解析失败或触发拦截。这个代价是防守方可以主动利用的。下一篇把这一周的方法串起来在一个综合靶场里从识别走到验证最后落成一份可复现的记录。
