代码审计之SQL注入及修复：系统性防御指南

一、SQL注入漏洞的本质与危害

SQL注入（SQL Injection）是Web应用中最常见的安全漏洞之一，其本质在于攻击者通过构造恶意SQL语句，绕过应用层的输入验证，直接操纵数据库查询逻辑。攻击者可利用此漏洞窃取敏感数据（如用户信息、交易记录）、篡改数据库内容（如修改密码、删除数据），甚至通过存储型XSS或命令注入实现更复杂的攻击链。

1.1 漏洞原理剖析

SQL注入的核心在于未对用户输入进行充分过滤或参数化处理。例如，某登录功能直接拼接用户输入到SQL查询中：

-- 恶意用户输入：admin' --
SELECT * FROM users WHERE username = 'admin' --' AND password = '...';

此时，--后的内容被注释，导致密码验证被绕过。更危险的攻击可通过联合查询（UNION）、盲注（Blind Injection）或时间延迟注入（Time-Based）实现。

1.2 典型攻击场景

• 数据泄露：通过UNION SELECT窃取其他表数据。
• 权限提升：修改管理员密码或插入恶意管理员账户。
• 拒绝服务：删除关键表或注入无限循环查询。
• 二次攻击：将数据库作为跳板，进一步渗透内网。

二、代码审计中的SQL注入识别方法

代码审计是发现SQL注入漏洞的关键环节，需结合静态分析与动态测试，重点关注以下风险点。

2.1 静态代码审计要点

2.1.1 危险函数与模式

• 字符串拼接查询：如PHP的mysql_query()、Java的Statement.execute()。
• 动态表名/列名：用户输入直接用于表名或列名拼接。
• 不安全的ORM使用：部分ORM框架在原生SQL模式下仍存在风险。

示例：某Java代码片段

// 危险：直接拼接用户输入
String username = request.getParameter("user");
String sql = "SELECT * FROM users WHERE username = '" + username + "'";
ResultSet rs = stmt.executeQuery(sql);

2.1.2 输入验证缺失

• 未对用户输入进行长度、类型或白名单校验。
• 过滤逻辑存在绕过风险（如仅过滤'但未处理"或十六进制编码）。

2.2 动态测试与工具辅助

• 自动化工具：Sqlmap、Burp Suite的主动扫描功能可快速检测注入点。
• 手动测试：通过输入'、"、1' OR '1'='1等测试用例验证。
• 日志分析：检查数据库错误日志中是否包含用户输入的SQL片段。

三、SQL注入漏洞的修复策略

修复SQL注入需从输入验证、参数化查询、最小权限原则三方面综合施策。

3.1 参数化查询（预编译语句）

参数化查询是防御SQL注入的核心手段，通过将用户输入作为数据而非代码执行，彻底阻断注入路径。

3.1.1 各语言实现示例

• Java（JDBC）：

  // 安全：使用PreparedStatement
  String username = request.getParameter("user");
  String sql = "SELECT * FROM users WHERE username = ?";
  PreparedStatement pstmt = connection.prepareStatement(sql);
  pstmt.setString(1, username);
  ResultSet rs = pstmt.executeQuery();

• PHP（PDO）：

  // 安全：使用PDO预处理
  $username = $_GET['user'];
  $stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
  $stmt->execute([$username]);
  $user = $stmt->fetch();

• Python（SQLite3）：

  # 安全：使用参数化查询
  username = request.args.get('user')
  cursor.execute("SELECT * FROM users WHERE username = ?", (username,))

3.1.2 ORM框架的正确使用

现代ORM（如Hibernate、Django ORM）默认使用参数化查询，但需避免以下情况：

• 调用原生SQL方法（如extra()、raw()）时未参数化。
• 动态生成SQL时拼接用户输入。

3.2 输入验证与过滤

• 白名单验证：限制输入为预期格式（如邮箱、数字ID）。
• 转义处理：对必须拼接的场景（如动态表名），使用数据库特定的转义函数（如MySQL的mysql_real_escape_string()，但参数化查询更优）。
• 长度限制：防止超长输入导致缓冲区溢出或查询超时。

3.3 最小权限原则

• 数据库用户仅授予必要权限（如仅SELECT而非DROP）。
• 避免使用root或sa等高权限账户连接应用数据库。

四、实际案例分析与修复实践

4.1 案例1：某电商平台的订单查询漏洞

漏洞描述：订单查询接口直接拼接用户输入的orderId到SQL中，攻击者可输入123 OR 1=1获取所有订单。

修复步骤：

1. 改用参数化查询：
   ```java
   // 修复前
   String sql = “SELECT * FROM orders WHERE orderId = “ + request.getParameter(“orderId”);

// 修复后
String sql = “SELECT * FROM orders WHERE orderId = ?”;
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setInt(1, Integer.parseInt(request.getParameter(“orderId”)));

2. 添加输入验证：确保`orderId`为数字。
### 4.2 案例2：某CMS系统的文章搜索漏洞
**漏洞描述**：搜索功能使用字符串拼接，攻击者可输入`admin' --`绕过权限检查。
**修复步骤**：
1. 改用参数化查询（PHP示例）：
```php
// 修复前
$keyword = $_GET['search'];
$sql = "SELECT * FROM articles WHERE title LIKE '%$keyword%'";
// 修复后
$stmt = $pdo->prepare("SELECT * FROM articles WHERE title LIKE ?");
$keyword = "%" . $_GET['search'] . "%";
$stmt->execute([$keyword]);

1. 对搜索关键词进行长度限制（如≤50字符）。

五、持续安全实践建议

1. 代码审计常态化：将SQL注入检查纳入CI/CD流程，使用SAST工具（如SonarQube）自动扫描。
2. 安全培训：定期对开发者进行安全编码培训，强调“绝不信任用户输入”原则。
3. 漏洞响应机制：建立漏洞上报与修复流程，确保高危漏洞在24小时内修复。
4. 依赖管理：及时更新数据库驱动与ORM框架，避免已知漏洞被利用。

结语

SQL注入漏洞的防御需要技术手段与管理流程的结合。通过参数化查询、输入验证与最小权限原则，可有效阻断绝大多数注入攻击。代码审计作为安全防线的前置环节，需持续关注新兴攻击手法（如宽字节注入、二次注入），并推动安全左移（Shift Left），将安全考量融入开发早期。唯有如此，方能构建真正健壮的Web应用安全体系。