大型门户网站需构建代码层、网关层、数据库层协同防御体系防SQL注入；参数化查询为底线且须全覆盖所有外部输入，WAF需按路径差异化配置规则，数据库权限须按功能粒度隔离，二阶注入依赖代码审计与SQL日志分析发现。
大型门户网站不能靠单一手段防 SQL 注入，必须构建代码层、网关层、数据库层协同响应的防御体系。参数化查询是底线，不是全部；WAF 规则能拦住 90% 的已知攻击变种，但绕过手段每天都在进化；真正致命的往往是二阶注入和盲注——它们不触发明显错误，却能持续窃取数据。
参数化查询必须覆盖所有用户输入入口
只要涉及 $_GET、$_POST、$_COOKIE、$_SERVER['HTTP_REFERER'] 等任何外部输入参与 SQL 拼接的地方，就必须用预编译语句。不是“尽量用”，是“一处不用，全站失守”。
- PHP 中禁用
mysql_query()，强制使用$pdo->prepare()或$mysqli->prepare()，且bind_param()类型标识（如"s"、"i"）必须匹配实际数据类型 - Python 使用
mysql-connector时，只接受%s占位符，严禁用.format()或 f-string 拼接 SQL 字符串 - Node.js 的
mysql2库中，connection.execute()支持数组或对象传参，但若手动拼接WHERE id IN (${ids.join(',')})，就等于开门揖盗 - ORM 不等于绝对安全：Django 的
extra()、SQLAlchemy 的text()都会绕过参数化机制，这类接口需单独审计
WAF 规则必须区分业务路径与攻击特征
通用 WAF 规则（如拦截含 UNION SELECT 的请求）对登录页有效，但对搜索接口可能误杀。大型站点必须按路径配置差异化策略。
- 管理后台路径（如
/admin/、/api/v1/users）启用严格模式：拦截所有含' OR 1=1、sleep(、benchmark(的请求，并记录完整 payload - 前端搜索接口（如
/search?q=）允许部分特殊字符，但需限制长度（如q参数 ≤ 128 字符）、校验 UTF-8 编码完整性，防止宽字节注入 - 腾讯云 WAF 的自定义规则中，避免只匹配关键字，应组合使用：正则匹配 + 参数值熵值检测（高熵值字符串更可能是编码绕过）+ 请求频率突增识别
- 注意 WAF 日志中的
[2025-12-03 14:30:00] 拦截SQL注入攻击攻击特征:' OR 1=1 --这类记录，要定期回溯是否出现新型变形（如'%20OR%201%3D1%23）
数据库账号权限必须按功能粒度隔离
一个连接池账号通吃所有表，等于把保险柜钥匙挂在入侵者必经之路上。权限不是“够用就行”，而是“刚好够本次操作”。
- 读取用户资料的接口，数据库账号只能执行
SELECT，且仅限users表的id、nickname、avatar字段（通过视图限制） - 日志写入服务账号禁止拥有
SELECT权限，只开放INSERT到operation_log表 - 禁用
information_schema访问——盲注常靠它枚举表名字段名，关闭后攻击者无法自动探测结构 - 连接字符串中的账号密码不得硬编码，应通过密钥管理服务（如腾讯云 KMS）动态获取，避免泄露后被批量复用
最易被忽略的是二阶注入：用户提交的昵称 admin'-- 存进数据库，后续某处未参数化的 UPDATE 语句把它当原文取出拼接，瞬间触发。这种漏洞不会出现在扫描报告里，只能靠代码审计+关键路径的 SQL 日志采样分析来发现。
