渗透测试(4)：SQL注入示例

渗透测试(4)：SQL注入示例

1、新增/修改功能的SQL注入

新增（INSERT 操作）和修改（UPDATE 操作）功能如果对用户输入处理不当，同样会存在 SQL 注入漏洞。

原理分析

SQL 注入的本质是用户输入被不当拼接进 SQL 语句，无论操作是查询（SELECT）、新增（INSERT）、修改（UPDATE）还是删除（DELETE），只要存在 “将用户输入直接拼接为 SQL 语句的一部分” 的情况，就可能被注入攻击。

新增功能（INSERT）的注入场景

假设新增用户的 SQL 语句是：

INSERT INTO users (username, password) VALUES ('用户输入的用户名', '用户输入的密码')

如果用户输入用户名为 ' OR 1=1; DROP TABLE users; --，拼接后 SQL 会变成：

INSERT INTO users (username, password) VALUES ('' OR 1=1; DROP TABLE users; --', '用户输入的密码')

这会导致数据库执行 “插入空用户名”+“删除users表” 的恶意操作。

修改功能（UPDATE）的注入场景

假设修改用户信息的 SQL 语句是：

UPDATE users SET password='新密码' WHERE id='用户输入的ID'

如果用户输入 ID 为 ' OR 1=1; --，拼接后 SQL 会变成：

UPDATE users SET password='新密码' WHERE id='' OR 1=1; --'

这会导致所有用户的密码都被修改为 “新密码”，造成大规模数据篡改。

防范建议

与查询功能的防护逻辑一致，核心是避免手动拼接 SQL，改用参数化查询 / 预编译语句：

• 采用框架自带的参数化能力（如 MyBatis 的#{} 、Hibernate 的实体映射）。
• 若手动写 SQL，使用PreparedStatement（Java）、parameterized queries（Python）等方式，让数据库自动处理输入转义。
• 严格做输入验证，限制输入的字符类型、长度，过滤 SQL 关键字和特殊符号。

2、查询功能的SQL注入

查询功能很容易成为 SQL 注入的重灾区。

SQL 注入的核心原因是应用程序将用户输入的内容直接拼接进 SQL 语句中，且未做有效过滤 / 校验。而查询功能（比如搜索框、数据筛选、条件查询等）恰恰是用户输入与 SQL 语句交互最频繁的场景之一。

举个简单例子：假设查询功能的 SQL 语句是 SELECT * FROM user WHERE username = '用户输入'，如果用户输入 ' OR 1=1 --，拼接后就会变成 SELECT * FROM user WHERE username = '' OR 1=1 --'，这会导致数据库执行 “查询所有用户数据” 的逻辑，从而引发 SQL 注入漏洞。

如何防范查询功能的 SQL 注入？

• 使用参数化查询 / 预编译语句（如 Java 的 PreparedStatement、Python 的 SQLAlchemy 参数化等），让数据库自动处理输入的转义，避免拼接风险。
• 严格的输入验证与过滤：对用户输入的字符类型、长度、格式进行校验，过滤掉 SQL 关键字（如OR、DROP等）或特殊符号（如'、;）。
• 最小权限原则：给数据库操作账号分配仅满足业务需求的最小权限，即使被注入，也能限制攻击范围。