一、SQL注入攻击的核心原理与常见类型
SQL注入是指攻击者通过在用户输入中插入恶意SQL代码，使服务器执行未授权的数据库操作。其本质是数据被当作代码执行，当应用程序直接将用户输入拼接到SQL语句中时，攻击者就能篡改原有逻辑，实现越权访问、数据窃取甚至服务器控制。
常见攻击类型
基于错误的注入：通过构造错误SQL语句（如输入单引号'），触发数据库报错，从中获取表结构、字段名等敏感信息。例如在登录框输入admin'，若返回“SQL语法错误”，则说明存在注入点。
联合查询注入：利用UNION SELECT语句合并查询结果，获取其他表的数据。例如在URL中输入?id=1 UNION SELECT username,password FROM users，可直接读取用户账号密码。
布尔盲注：通过构造逻辑判断语句（如AND 1=1或AND 1=2），根据页面返回的真假状态，逐步推断数据库内容。这种方式无明显报错，隐蔽性极强。
时间盲注：利用SLEEP()等函数，通过页面响应时间判断逻辑是否成立。例如输入?id=1 AND IF(ASCII(SUBSTRING(database(),1,1))=115,SLEEP(5),0)，若页面延迟5秒，则说明数据库名首字母ASCII码为115（即s）。
堆叠查询注入：通过分号;分隔多个SQL语句，执行额外操作。例如输入?id=1; DROP TABLE users，可能直接删除用户表（需数据库支持多语句执行）。
二、SQL注入的典型攻击场景
- 登录绕过
在登录界面输入' OR 1=1 #，原SQL语句会被篡改为：
SELECT * FROM admin WHERE username='' OR 1=1 #' AND password=''
由于#注释了后续内容，1=1恒成立，攻击者无需正确账号密码即可登录后台。
- 数据窃取
通过联合查询读取敏感数据，例如：
UNION SELECT 1,group_concat(username,0x3a,password),3 FROM users
其中0x3a是冒号的十六进制编码，用于分隔用户名和密码，攻击者可一次性获取所有用户凭证。
- 权限提升
若数据库用户权限过高，攻击者可通过注入执行系统命令。例如在MySQL中：
SELECT INTO OUTFILE '/var/www/html/shell.php' VALUES('')
直接写入Webshell，控制整个服务器。
三、SQL注入防护的核心策略
- 代码层面：严格分离数据与代码
参数化查询（预编译语句）
这是防御SQL注入最有效的方法，通过预编译SQL模板，将用户输入作为参数传递，确保输入仅被视为数据。
Java示例：
String sql = "SELECT * FROM users WHERE username = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, username); // 绑定参数
ResultSet rs = pstmt.executeQuery();
MyBatis示例：使用#{}而非${}，#{}会自动进行参数化处理：
SELECT * FROM users WHERE username = #{username}
输入验证与过滤
白名单验证：仅允许符合预期格式的输入，如手机号限制为11位数字，邮箱需包含@符号。例如用正则表达式验证手机号：
Pattern pattern = Pattern.compile("^1[3-9]\d{9}$");
if (!pattern.matcher(phone).matches()) {
throw new IllegalArgumentException("手机号格式错误");
}
特殊字符转义：对单引号'、双引号"等特殊字符进行转义，但需注意避免依赖单一转义（如宽字节注入可绕过addslashes()）。
- 数据库层面：最小权限原则
应用程序连接数据库时，使用专用低权限账户，避免使用root、sa等超级管理员账号。
严格限制账户权限，例如仅授予SELECT、INSERT权限，禁止DROP、ALTER等高危操作。
对敏感数据进行加密存储，如用户密码使用BCrypt、Argon2等哈希算法加密，即使数据泄露也无法直接还原。
- 运维层面：强化环境安全
定期更新与补丁：及时修复数据库、Web服务器及应用框架的已知漏洞，如MySQL的CVE-2023-25735、Apache的Log4j漏洞等。
禁用危险功能：关闭数据库的LOAD_FILE()、INTO OUTFILE()等函数，禁止执行系统命令。
日志监控与审计：开启数据库审计日志，实时监控异常SQL语句（如包含UNION、DROP的查询），发现攻击及时告警。
四、Web应用防火墙（WAF）与SCDN防护
- WAF的核心防护逻辑
Web应用防火墙通过规则引擎识别并拦截SQL注入攻击，常见防护方式包括：
特征匹配：识别UNION SELECT、OR 1=1等攻击特征。
语义分析：分析SQL语句的语法结构，判断是否存在恶意篡改。
机器学习：通过AI模型识别新型攻击变种，降低误报率。
- WAF与代码防护的协同
WAF是最后一道防线，不能替代代码层面的安全措施。建议采用“代码防护+WAF”的纵深防御体系：
代码层面实现参数化查询与输入验证，从根源避免注入风险。
WAF作为补充，拦截漏网的攻击请求，同时防护零日漏洞攻击。
五、常见误区与避坑指南
仅过滤单引号：攻击者可通过宽字节注入（如输入%df'）绕过转义，需结合参数化查询使用。
依赖客户端验证：前端验证可被轻易绕过（如通过Burp Suite修改请求），必须在后端重复验证。
禁用错误提示过度：完全关闭错误提示会增加调试难度，建议在生产环境返回通用错误页面，同时将详细错误日志记录到服务器。
忽视存储过程风险：存储过程若使用动态SQL拼接，同样存在注入风险，需确保存储过程中的参数也经过验证。
六、应急响应与恢复
若发生SQL注入攻击，需立即采取以下措施：
隔离攻击源：通过WAF或防火墙阻断攻击IP，限制可疑请求。
排查漏洞：检查应用代码，找出注入点并修复（如替换动态SQL为参数化查询）。
数据恢复：使用最新备份恢复被篡改或删除的数据，若数据已泄露，需及时通知用户并修改密码。
事后审计：分析攻击日志，总结漏洞原因，完善防护规则，避免再次发生。
