SQL注入为何频发

SQL注入（SQL Injection）之所以在各类Web安全漏洞中长期居高不下、频频发生，主要可以从技术原理、开发习惯、系统架构和历史遗留几个层面来解释：

一、根本原因：SQL语句本身是“拼接”出来的

SQL注入的本质是：

用户输入被当作SQL代码执行，而不是纯粹的数据

例如：

SELECT * FROM users WHERE name = '" + username + "';

如果用户输入：

' OR '1'='1

最终SQL变成：

SELECT * FROM users WHERE name = '' OR '1'='1';

这就是注入发生的核心原因——没有严格区分“代码”和“数据”。

二、开发层面原因（最主要）

1. 字符串拼接SQL太常见

很多初学者或老旧系统直接使用：

• Java：+
• PHP：.
• Python：% / format
• 前端直接拼SQL

✅ 正确做法应使用：

• 预编译语句（PreparedStatement）
• ORM（如 MyBatis、Hibernate、SQLAlchemy）

但现实中大量系统并未采用。

2. 安全意识不足

• 认为“内部系统不会被人攻击”
• 认为“用户不会乱输入”
• 只做前端校验（前端可被绕过）

3. 输入校验不完整

常见错误：

• 只过滤单引号 '
• 只防 select，不防 union、sleep、benchmark
• 黑名单方式（永远补不全）

三、系统与历史原因

1. 老旧系统太多

• 十年前的代码仍在运行
• 当时根本没有安全意识
• 改造成本高，不敢动

2. 框架默认不安全或误用

例如：

• MyBatis 中 ${} 仍会注入
• ORM 写原生SQL时不小心拼接
• 报表系统、BI系统大量动态SQL

3. 接口和参数太多

• URL参数
• Header
• Cookie
• JSON Body
• 文件内容

只要有一处没防住，就会中招。

四、攻击成本低，收益高

对攻击者：

• 工具成熟（sqlmap）
• 可自动化
• 不需要高端技术

对系统：

• 可拖库
• 可提权
• 可控制服务器

⚠️ 投入产出比极高

五、典型高发场景

• 登录接口
• 搜索框
• 排序参数（order by）
• 报表查询
• 后台管理系统

六、为什么“频发的现状”难改变？

✅ 技术上有解
❌ 组织上难推

• 历史债务重
• 安全不是KPI
• 修复可能引入Bug

七、根本解决思路

1. 永远使用参数化查询
2. 最小权限数据库账号
3. 关闭错误信息外显
4. WAF + 审计 + 扫描
5. 安全左移（开发阶段就防）

如果你愿意，我也可以：

• 用真实案例讲一次SQL注入过程
• 对比 MyBatis $ 和 # 的区别
• 给你一份 SQL注入自查清单

你可以直接说你关注的是开发 / 安全测试 / 运维哪方面。