哪些代码易引发SQL注入问题

SQL 注入本质上是因为把用户输入直接拼接到 SQL 语句中，并且没有做正确的校验或参数化处理。下面从「容易引发 SQL 注入的代码写法」和「常见场景」两方面说明。

一、最容易导致 SQL 注入的代码写法

1️⃣ 字符串拼接 SQL（最典型）

String sql = "SELECT * FROM user WHERE name = '" + username + "'";
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(sql);

如果用户输入：

' OR '1'='1

最终 SQL 变成：

SELECT * FROM user WHERE name = '' OR '1'='1'

✅ 后果：绕过登录、拖库

2️⃣ 使用拼接方式的 ORM（误用）

sql = "SELECT * FROM user WHERE id = %s" % user_id
cursor.execute(sql)

即使使用 ORM，只要手写 SQL + 拼接，仍然危险。

3️⃣ Like / Order By 拼接

String sql = "SELECT * FROM user ORDER BY " + sortColumn;

用户输入：

id; DROP TABLE user--

4️⃣ IN 语句拼接

String sql = "SELECT * FROM user WHERE id IN (" + ids + ")";

ids = "1,2,3); DROP TABLE user;--"

5️⃣ 动态表名 / 字段名拼接

String sql = "SELECT * FROM " + tableName;

表名、字段名无法用参数化，只能白名单控制。

6️⃣ 存储过程中拼接 SQL

EXEC('SELECT * FROM user WHERE name = ''' + @name + '''')

动态 SQL 同样危险。

二、常见高危场景

✅ 登录功能

SELECT * FROM user WHERE name='xxx' AND pwd='xxx'

拼接输入 → 万能密码

✅ 搜索框（Like）

SELECT * FROM article WHERE title LIKE '%关键词%'

关键词未过滤

✅ 分页参数

LIMIT 0, 10

page 参数被篡改

✅ 导出 / 报表系统

复杂 SQL + 多参数拼接

三、安全写法（正确示例）

✅ 使用预编译（PreparedStatement）

String sql = "SELECT * FROM user WHERE name = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, username);

✅ 使用 ORM 参数化

User.objects.filter(name=username)

✅ 白名单控制动态字段

if (!allowedColumns.contains(sortColumn)) {
    sortColumn = "id";
}

四、一句话总结

只要 SQL 中出现了“用户输入 + 字符串拼接”，就极有可能存在 SQL 注入风险。

如果你愿意，我可以：

• 帮你审查一段具体代码
• 按语言（Java / Python / PHP / Go）举例
• 或讲 SQL 注入的利用与防御实战