0x00 前言
SQL 注入（SQL Injection，简称 SQLi）是 Web 应用中一种常见的安全漏洞。当应用程序将用户输入直接拼接进 SQL 语句，且缺少有效处理时，就可能导致数据库执行非预期的查询。
本文主要介绍 SQL 注入的基本原理、常见类型、检测思路及防御方法。
免责声明：本文仅用于网络安全学习与授权测试，请勿对未获授权的系统进行测试。
0x01 什么是 SQL 注入
SQL 注入是一种通过不可信输入影响数据库查询逻辑的漏洞。
正常情况下，用户输入应当作为普通数据参与查询。但如果程序直接拼接输入内容，数据库就可能将其中的内容解释为 SQL 语法，从而改变原有查询逻辑。
简单来说：本来应该输入数据的地方，却有机会影响数据库执行什么操作。
0x02 SQL 注入的危害
SQL 注入可能造成以下影响：
数据泄露： 未授权访问用户信息、业务数据等。
数据篡改： 修改或删除数据库中的内容。
权限扩大： 在特定条件下绕过原有的数据访问限制。
业务受损： 影响网站正常运行，甚至造成服务中断。
实际危害取决于数据库权限、应用设计和运行环境，并非所有 SQL 注入都能直接控制服务器。
0x03 SQL 注入的基本原理
典型 Web 应用的数据交互过程如下：
用户向网站提交请求。
后端接收参数并组织 SQL 查询。
数据库执行查询并返回结果。
后端处理结果，再返回给用户。
如果后端使用字符串拼接构造 SQL，且没有正确处理用户输入，就可能产生注入风险。
常见参数入口包括：
URL 查询参数
表单提交内容
Cookie
请求头
JSON 请求体
因此，不能只关注网页上的输入框，所有进入数据库查询的数据都应纳入安全审查。
0x04 SQL 注入的常见类型
1. 按参数形式分类
数字型注入： 参数以数字形式参与 SQL 查询。
字符型注入： 参数以字符串形式参与 SQL 查询，通常涉及引号和字符处理。
2. 按利用原理分类
需要注意：这些分类并非完全处于同一维度。例如，数字型和字符型描述参数形式，而盲注、报错注入描述的是信息判断方式。
0x05 检测时关注什么
在授权测试或代码审计中，可以重点关注：
用户输入是否直接拼接进 SQL。
不同输入是否导致查询结果出现异常变化。
页面是否暴露数据库错误信息。
响应时间是否存在不合理波动。
数据库查询是否缺少参数化处理。
单次异常响应不能直接证明存在 SQL 注入，需要结合代码、日志和多次测试结果综合判断。
0x06 防御与修复
防止 SQL 注入，关键在于从代码层面控制用户输入与 SQL 语法之间的边界。
1. 使用参数化查询
优先使用预编译语句和参数绑定，让用户输入始终作为数据处理，而不是 SQL 语法。
2. 避免字符串拼接
不要直接将用户输入拼接进 SQL 语句。
3. 限制数据库权限
应用账号只应拥有业务所需的最低权限，避免漏洞造成更大影响。
4. 规范错误处理
不要向普通用户暴露数据库结构、SQL 语句和内部错误信息。
5. 加强输入校验
根据业务需求校验数据类型、长度和格式，但不能用输入过滤代替参数化查询。
6. 定期开展代码审计
重点检查数据库访问层、登录模块、搜索功能和数据查询接口。
0x07 总结
SQL 注入的核心问题，是程序没有正确区分用户数据与 SQL 语法。
随着开发框架和数据库安全机制不断完善，这类漏洞并非无法避免。使用参数化查询、遵循最小权限原则，并做好代码审计，能够有效降低 SQL 注入风险。
0x08 About 作者
记录网络安全学习过程，分享漏洞原理、安全研究与技术实践。