最近帮朋友维护一个小型电商后台，发现日志里频繁出现奇怪的请求，比如在搜索框输入的内容里夹带一堆单引号和函数名。仔细一查，原来是有人在尝试用报错注入搞事情。这类攻击不靠盲猜数据，而是利用数据库错误信息直接“套话”，得好好说道说道。
报错注入是咋回事？
正常情况下，SQL 查询出错了，系统会记录日志但不会把详细信息暴露给用户。可一旦程序没处理好异常，攻击者就能故意构造特殊语句，让数据库返回错误的同时，把敏感数据“顺”出来。
比如在登录框输入用户名时，后端拼接 SQL 类似这样：
SELECT * FROM users WHERE username = '<input>' AND password = '<pass>';如果输入的是：' AND (SELECT 1 FROM (SELECT COUNT(*),CONCAT(0x3a,(SELECT database()),0x3a,FLOOR(RAND(0)*2))x FROM information_schema.tables GROUP BY x)a) AND '，可能会触发类似下面的错误：
ERROR 1062 (23000): Duplicate entry ':shop_db:1' for key 'group_key'看到没？错误信息里直接冒出了数据库名 shop_db。这就是典型的报错注入——利用 GROUP BY 冲突配合 CONCAT 拼接，把查询结果塞进错误提示里。
常见函数套路
MySQL 里几个容易被滥用的函数：
EXTRACTVALUE(xml_frag, xpath_expr)：解析 XML 出错时会回显 xpath 内容UPDATEXML(xml_frag, xpath_expr, new_val)：同上，改写失败也会暴露路径GTID_SUBSET()、JSON_KEYS()等在特定版本也能触发信息泄露
举个例子：
' AND EXTRACTVALUE(1, CONCAT(0x7e,(SELECT user()),0x7e))--
执行后可能报错：
XPATH syntax error: '~root@localhost~'账号信息就这么被亮出来了。
别让错误成为突破口
防御的核心就一条：别把数据库原生错误甩给前端。不管是 PHP、Java 还是 Python，捕获异常后返回统一提示就行，比如“操作失败，请重试”。
更进一步的做法是开启自定义错误页，连 HTTP 状态码都包装一层。开发阶段可以开详细错误，上线前必须关掉。
另外，参数化查询（Prepared Statement）能从根本上杜绝拼接风险。像这样：
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, inputUser);
pstmt.setString(2, inputPass);
就算用户输一堆花里胡哨的符号，也只是当作普通字符串处理，不会改变 SQL 结构。
还有个小技巧：限制数据库账户权限。Web 应用用的账号不需要 information_schema 的读权限，也不该有建表删库的权力。最小化授权，就算被撞开一道缝，损失也能控制住。
最后提醒一句，网上那些“一键检测注入点”的工具别乱用，扫自家系统没问题，对外扫描可能踩到法律红线。安全这事儿，还是踏踏实实做防护最靠谱。