SQL注入漏洞挖掘实战：从隐藏注册功能到漏洞发现

1. 漏洞发现背景

本文记录了一个通过分析隐藏注册功能发现SQL注入漏洞的完整过程。目标系统表面只有登录界面，但通过接口猜测和测试，发现了一个未完全关闭的注册接口，并最终利用该接口实现了SQL注入攻击。

2. 初始侦察

2.1 目标系统初步分析

• 系统仅显示登录框
• 随意输入账号密码后返回"账号不存在"提示
• 登录接口路径：/dev-api/auth/login

2.2 注册接口猜测与验证

1. 接口路径猜测：

   • 基于登录接口路径/dev-api/auth/login
   • 猜测注册接口可能为/dev-api/auth/register

2. 验证方法：

   • 浏览器开发者工具全局搜索/register
   • 确认存在/auth/register接口
   • 同样方法验证/auth/login接口存在

3. 接口访问测试：

   • 通过Burp Suite修改路径访问注册接口
   • 返回HTTP 200状态码
   • 响应体显示"当前系统没有开启注册功能"（服务器内部错误500）

3. 注册接口功能分析

3.1 输入验证测试

• 用户名长度限制：2到20个字符
• 密码长度限制：5到20个字符

3.2 后端逻辑推测

注册接口虽然关闭但仍在处理请求，可能有两种后端逻辑：

1. 第一种可能：

   • 先处理请求体数据
   • 创建账号并存入数据库
   • 检查注册功能是否开启
   • 如未开启则不启用账号并返回提示

2. 第二种可能：

   • 先检查注册功能是否开启
   • 如未开启则直接返回提示

无论哪种情况，都涉及数据库查询操作，可能存在SQL注入点。

4. SQL注入漏洞验证

4.1 初步注入尝试

构造特殊请求包后，系统返回明显报错信息，确认存在SQL注入漏洞。

4.2 报错注入利用

1. 确定列数：

   • 通过报错信息发现查询涉及12列

2. 联合查询获取信息：

   • 使用UNION查询获取数据库信息
   • 成功获取到root@localhost信息

4.3 自动化工具利用

• 将请求保存到本地
• 使用SQLmap进行自动化注入测试
• 成功获取数据库信息

5. 关键经验总结

1. 隐藏接口的价值：

   • 功能关闭的接口仍可能存在安全风险
   • 这些接口可能未经过充分的安全测试
   • 应全面测试所有可访问的接口，包括看似不可用的

2. HTTP状态码解读：

   • 200状态码不一定表示操作成功
   • RESTful API可能将实际错误码放在响应体中
   • 需要仔细分析完整的响应内容

3. SQL注入挖掘思路：

   • 关注所有涉及数据库查询的操作
   • "凡数据，皆查询" - 任何数据处理都可能涉及数据库操作
   • 不要局限于明显的功能点，要测试边界情况

4. 测试方法论：

   • 基于现有接口合理猜测其他接口
   • 使用开发者工具辅助分析
   • 通过修改请求参数测试各种边界条件
   • 注意系统对输入长度的限制和验证

6. 防御建议

1. 对所有接口实施安全措施：

   • 即使是关闭的功能也应实施同等安全防护
   • 彻底关闭不需要的接口而非仅屏蔽前端访问

2. 输入验证与参数化查询：

   • 对所有输入实施严格验证
   • 使用参数化查询或ORM框架

3. 错误处理：

   • 避免在错误响应中泄露敏感信息
   • 实现统一的错误处理机制

4. 安全测试：

   • 对所有接口进行安全测试，包括隐藏接口
   • 定期进行安全审计和渗透测试

7. 完整攻击流程总结

1. 发现系统登录接口
2. 猜测并验证注册接口存在
3. 测试注册接口的输入验证
4. 分析后端可能的数据处理逻辑
5. 构造特殊输入触发SQL错误
6. 利用报错信息确认注入点
7. 通过UNION查询获取数据库信息
8. 使用SQLmap自动化利用漏洞

这个案例展示了如何通过系统分析和合理猜测，从看似安全的系统中挖掘出严重的安全漏洞。