网站遭遇SQL注入攻击，如何检测拦截恶意请求并有效防御？

你遇到的是自动化漏洞扫描机器人的批量注入探测，这类攻击用开源SQL注入工具批量生成payload，靠传统黑名单式输入清洗无法100%覆盖变种，需要从入口拦截、应用加固、权限管控多层设置防护，具体方案如下：

入口层前置拦截（查询执行前直接拦截恶意请求） #

这层逻辑部署在业务服务之前，命中恶意特征的请求直接拦截，根本不会到达业务代码和数据库：

• 配置WAF拦截规则：针对注入特征配置匹配规则，命中以下任意特征的请求直接返回403拦截：
  • 时间盲注关键字：sleep(、PG_SLEEP(、DBMS_PIPE.RECEIVE_MESSAGE(、sysdate()等注入常用的延时执行、时间判断函数
  • 布尔盲注特征：拼接形式的逻辑判断语句，比如OR [数字等式]、XOR(if(这类将恶意逻辑拼接到SQL语句中的结构
  • SQL语法特征：SQL语句注释符--、/* */，以及非必要场景下单引号、双引号和SQL关键字的异常组合
• 拦截自动化bot流量：所有表单接口前置人机校验（滑动验证、点选验证均可，不要用容易被绕过的字符验证码），同时配置接口频率限制：单IP1分钟内提交表单超过5次直接临时拉黑，从源头挡住自动化批量提交的扫描请求。
• 严格参数白名单校验：每个表单字段提前设定合法格式规则，比如年龄字段只允许1-3位数字、用户名只允许4-16位字母/数字/下划线，不符合格式规则的请求直接拒绝，不进入后续处理流程。注意白名单校验的可靠性远高于黑名单式的输入清洗，不存在绕过空间

应用层核心加固（从根源杜绝注入风险） #

入口拦截是兜底手段，要彻底杜绝SQL注入，必须在应用代码层做对配置：

• 全量使用参数化查询（预编译语句）：所有数据库操作彻底废弃字符串拼接SQL的写法，这是防范SQL注入的黄金标准。参数化查询会将SQL语句的结构和传入参数严格分离，无论参数里携带什么注入payload，都只会被当做普通字符串处理，永远不会被解析为SQL指令执行，从逻辑上彻底堵死注入路径。
• 最小化数据库账号权限：给业务服务分配的数据库账号只授予必要的最小权限，比如普通表单业务只给对应业务表的INSERT、SELECT权限，绝不授予DROP、ALTER、系统函数调用等高风险权限。你日志里看到的PG_SLEEP、DBMS_PIPE.RECEIVE_MESSAGE这类函数，只要业务账号没有调用权限，就算payload绕过了前面的防护，也无法执行成功。
• 关闭数据库错误回显：不要把数据库的原生报错信息直接返回给前端，统一返回通用的“请求异常，请稍后重试”提示，避免攻击者通过报错信息判断注入点是否存在。

兜底监控措施 #

• 开启数据库审计日志，配置异常语句告警：对执行时间超过1秒、包含高危函数关键字、涉及多表联合查询的异常语句实时告警，出现攻击行为可以第一时间处置。
• 定期巡检数据库存量数据，清理已经写入的恶意测试payload，避免残留内容被后续逻辑误触发。

内容的提问来源于stack exchange，提问作者Paolo De Feo