UNION注入能成功是因为后端将用户输入直接拼接进SQL字符串，未做类型校验、单引号转义或长度限制，攻击者利用' UNION SELECT ... --+截断原语句并注入恶意查询。
为什么 UNION 注入能成功？关键在拼接逻辑
联合查询注入能跑通，根本不是因为 UNION 本身危险，而是后端把用户输入直接拼进 SQL 字符串里，比如：SELECT * FROM users WHERE id = ' + user_input。只要没做类型校验、没转义单引号、也没限制长度，攻击者就能用 ' UNION SELECT ... --+ 截断原语句、补上恶意查询。
常见错误现象包括：页面返回多条数据、报错信息里暴露表结构、甚至直接显示数据库名或密码字段内容。这类漏洞往往出现在搜索框、分页参数、ID 过滤器等位置，且多为字符型注入（带单引号闭合）。
- 整数型参数却未强制转成
int，仍当字符串拼接（如 PHP 中$id = $_GET['id']; $sql = "SELECT ... WHERE id = '$id'";） - 使用了
mysql_real_escape_string但连接字符集不一致（如 GBK 宽字节），导致转义失效 - 前端做了数字校验，后端没复核——绕过前端提交任意字符串即可
mysqli::prepare 和 PDO::prepare 怎么选？看执行环境
参数化查询是修复核心，但具体用哪个 API，得看你用的扩展和 PHP 版本。PHP 8.1+ 已废弃 mysql_* 系列函数，mysqli 和 PDO 是唯二可靠选择。
mysqli::prepare 更轻量，适合只连一个 MySQL 实例的项目；PDO::prepare 支持多种数据库驱动，抽象层更干净，且默认启用预处理模拟（PDO::ATTR_EMULATE_PREPARES = false 必须显式关掉，否则仍是拼接）。
- 用
mysqli时，确保开启MYSQLI_OPT_CONNECT_TIMEOUT并检查mysqli_stmt::execute()返回值，失败要记录日志 - 用
PDO时，必须设置setAttribute(PDO::ATTR_EMULATE_PREPARES, false)，否则prepare只是语法检查，实际仍拼接 - 不要混用：比如用
PDO连接，却把变量直接插进query()字符串里——这等于没修
哪些“看似安全”的写法其实无效？
很多团队加了过滤函数就以为高枕无忧，结果上线不久就被绕过。最典型的是只过滤单引号、或只做 addslashes，这些在现代注入手法面前形同虚设。
-
addslashes()无法防御宽字节注入（如%df%27在 GBK 下被解析为運'） - 正则替换
'、--、UNION等关键词——攻击者改用大小写混合（UnIoN）、编码（%55nion）、注释分隔（/**/UNION/**/SELECT）轻松绕过 - 前端 JS 校验
isNaN()判断数字型参数——禁用 JS 后直接发包，后端没校验照样中招 - 用
intval()处理 ID 参数，但没检查返回是否为 0 或负数，导致id=1' or sleep(5) --被转成0，虽不报错却可能触发异常逻辑分支
修复后必须验证的三个边界点
改完代码不能只测正常流程，重点看它在异常输入下是否真正阻断，而不是静默失败或抛出敏感错误。
- 传入
' OR 1=1 --+：应返回空结果或 400 错误，绝不能查出所有用户 - 传入超长字符串（如 10000 个
a）：数据库字段长度限制应生效，而非被截断后拼接执行 - 传入
1 union select @@version,2,3（无引号）：若参数本该是整数，此处应被类型转换拦截，而不是进 SQL 执行层
最易被忽略的是错误页面配置——即使用了预处理，如果 display_errors = On 且没自定义错误处理器，MySQL 报错仍可能泄露表名、字段名甚至完整 SQL，给后续盲注提供线索。
