SQL注入成功是因为程序未区分代码与数据，直接拼接用户输入；防御核心是预编译参数化查询，辅以最小权限、错误信息隐藏、输入校验和WAF。
SQL注入攻击本质是把用户输入当成了SQL代码来执行，而不是当作普通数据处理。关键在于程序没区分“代码”和“数据”，让攻击者能拼接恶意SQL片段，绕过登录、读取敏感表、甚至删库跑路。
为什么SQL注入能成功？
根本原因在于动态拼接SQL语句时，直接把用户输入（比如登录框填的用户名、URL里的id参数）塞进SQL字符串里，没做任何隔离或转义。
- 例如："SELECT * FROM users WHERE name = '" + userInput + "'"，如果userInput是' OR '1'='1，整条语句就变成SELECT * FROM users WHERE name = '' OR '1'='1'，条件恒真，可能查出所有用户
- 数据库按语法解析执行，不关心这个值是不是用户本意，只要语法合法，就照单全收
- 权限配置不当会放大危害——应用账号有DBA权限，一条注入就能拖走整个库
最有效的防御方式：预编译参数化查询
不是靠过滤单引号、分号这些字符，而是从机制上让输入彻底变成“数据”，无法参与SQL结构解析。
- Java用PreparedStatement，占位符?传参："SELECT * FROM users WHERE id = ?"，再setInt(1, userId)，数据库引擎会严格区分SQL骨架和参数值
- Python用sqlite3的cursor.execute("SELECT * FROM log WHERE type = ?", (log_type,))，括号里必须是元组
- PHP用PDO的prepare+execute，避免直接拼接$_GET或$_POST到SQL中
其他必须配合的安全措施
参数化是核心，但不能只靠它。还要堵住旁路和降低损失。
- 最小权限原则：应用数据库账号只给必要权限，比如只需查用户信息，就只授权SELECT users表，禁用DROP、UNION、LOAD_FILE等高危操作
- 错误信息不暴露细节：生产环境关闭数据库报错堆栈，别把表名、字段名、MySQL版本直接打在页面上，否则帮攻击者探路
- 输入格式校验前置：手机号就校验11位数字，ID就限定为正整数，非法格式直接拦截，不进SQL层
- Web应用防火墙（WAF）可作为辅助层，识别常见注入特征（如UNION SELECT、sleep(5)），但不能替代代码层防护
基本上就这些。防注入不复杂，关键是意识到位、方法用对——永
远别信用户输入，永远用参数化，永远限制权限。
