SQL注入漏洞的核心是将用户输入当作代码执行，源于未区分“数据”与“指令”边界，典型表现为直接字符串拼接SQL、动态构造表名/字段名、弱过滤绕过及错误信息泄露叠加高权限账号。
SQL注入漏洞的产生，核心就一条：把用户输入当代码执行了。不是输入本身危险，而是程序没分清“数据”和“指令”的边界。
用户输入直接拼进SQL语句
这是最典型、最危险的写法。后端拿到用户名、ID、搜索词这类参数，不加处理就用字符串拼接方式塞进SQL里。
- 比如 PHP 中：
$sql = "SELECT * FROM users WHERE id = '" . $_GET['id'] . "'"; - Java JDBC 中：
String sql = "SELECT name FROM user WHERE username = '" + username + "'"; - Python 中：
query = "SELECT * FROM products WHERE category = '" + cat + "'"
只要用户传入 1' OR '1'='1 或 1' UNION SELECT password FROM users--，原查询逻辑就被彻底改写，数据库照单执行。
动态构造表名或字段名
有些业务需要根据参数切换查询的表或排序字段，但开发者误用拼接方式处理这些“元信息”。
- 错误示例：
$table = $_GET['tab']; $sql = "SELECT * FROM {$table} WHERE status=1"; - 攻击者传
?tab=users%20UNION%20SELECT%20password%20FROM%20admin，可能触发非法查询 - 排序字段也常见：
ORDER BY $_GET['sort']—— 传入name, (SELECT @@version)就能读版本
这类场景无法用参数化查询解决，必须白名单校验或映射转换（如 sort=name → ORDER BY name）。
使用危险函数或特性绕过基础过滤
有些开发试图用简单替换（如删掉单引号）来防御，反而制造新漏洞。
- 用
str_replace("'", "''", $input)处理，但在 MySQL 宽字节环境下可被绕过 - 过滤了
union却没过滤大小写变体：UnIoN、%55%4e%49%4f%4e - 允许
SELECT但没限制子查询，导致SELECT (SELECT password FROM users LIMIT 1)成功执行
这类“半吊子过滤”比完全不防更危险——它给人虚假安全感，实际形同虚设。
错误信息泄露+高权限数据库账号
单独看这两点不算直接“产生”注入，但会把普通漏洞放大成高危甚至远程控制风险。
- 开启调试模式，让数据库报错直接回显在页面上（如
MySQL Error: You have an error in your SQL syntax...），攻击者立刻知道表结构、字段名 - 应用连接数据库用的是 root 或 dba 权限账号，一旦注入成功，就能执行
INTO OUTFILE写 Webshell、调用LOAD_FILE()读配置、甚至执行系统命令（如SELECT sys_exec('id')）
没有错误回显，盲注也能打；但有了错误回显+高权限，攻防效率呈指数级提升。
