PortSwigger SQL注入实验（二）
通过SQL注入绕过登录验证

本实验来自 PortSwigger Web Security Academy，是 SQL 注入系列的第二个基础实验。目标为：使用 Burp Suite 对登录请求进行拦截与分析，并通过修改请求参数实现绕过登录验证。

通过该实验可以理解：当应用程序将用户输入直接拼接至 SQL 语句而未做任何过滤或参数化处理时，攻击者可通过精心构造的输入改变原始 SQL 语句的语义，从而绕过密码校验机制。

【实验目标】
该实验的登录功能中存在 SQL 注入漏洞。
利用该漏洞以管理员身份（administrator）登录应用。

1. 启动实验环境与 Burp Suite

启动实验环境后，可以看到与 LAB1 相似的购物页面，页面右下方提供了“Home”与“My account”功能入口。

接下来启动 Burp Suite，进入 Proxy 模块下的 HTTP history 子页面。当浏览器中的代理配置生效后，此处将开始记录所有 HTTP 流量。

我们首先点击 My account 查看登录页面的结构：

界面非常简洁（笑），接下来便可以着手进行抓包分析。

2. 开启代理并抓取登录请求

启用浏览器中已配置好的 Burp Suite 代理，准备捕获登录请求。

由于目标是使用管理员账户登录，我们在用户名栏输入 administrator，密码栏为了方便追踪填入 testcode。

点击登录后，观察 Burp Suite 中捕获到的数据：

面对大量记录，如何快速定位目标请求？已知实验站点为 https://0a62009904db1a7e815c7af3006400a2.web-security-academy.net，因此可筛选 Host 为该域名且请求路径为 /login 的条目。

由于我们刚刚提交了用户名与密码，该请求必然存在于记录中，可直接在请求列表中根据上述条件锁定：

右键将该请求发送至 Repeater 模块，以便后续进行重放与修改测试。

3. 分析请求数据并推测后端 SQL 逻辑

观察 Request 的 Body 部分，可以发现我们向服务器提交的核心参数为：username=administrator&password=testcode。据此推测，后端可能存在如下 SQL 查询逻辑：

SELECT * FROM users WHERE username = '$username' AND password = '$password'

4. 构造注入攻击

4.1 定位注入点

要破坏上述查询语句的原有逻辑，我们需要像 LAB1 中一样，利用单引号 ' 跳出字符串边界。尝试在用户名后追加一个单引号，则查询语句将变为：

SELECT * FROM users WHERE username = 'administrator'' AND password = 'testcode'

这将导致 SQL 语法错误。我们在 Repeater 中将 username 的值改为 administrator' 并发送请求：

服务器返回 500 Internal Server Error，证实单引号被成功带入 SQL 语句并破坏了其语法结构，从而确认此处存在 SQL 注入漏洞。

4.2 注释掉密码验证部分

既然 username 字段存在注入点，下一步即可通过注释符屏蔽密码校验条件，实现绕过登录。

我们期望后端执行的 SQL 语句变为如下形式：

SELECT * FROM users WHERE username = 'administrator'-- ' AND password = 'testcode'

其中 -- 为 SQL 单行注释符，其后的内容（即密码校验部分）将被数据库忽略。

4.3 构造最终 Payload

Payload 各组成部分的作用如下：

• administrator：目标用户名。
• '：闭合 SQL 语句中用户名字段的左引号。
• -- ：注释掉后续的 AND password = 'testcode' 条件（注意末尾空格）。

最终构造的完整请求体为：

csrf=fAUUPbRa2TaV8nWFNSxRGI12atFIWyW3&username=administrator' -- &password=testcode

4.4 执行攻击请求

在 Repeater 中将 username 参数的值修改为 administrator' -- ，点击 Send 发送：

观察响应头中的 Location 字段，其值为 /my-account?id=administrator，表明已成功以管理员身份登录，实验目标达成。

5. 总结与防御建议

本实验是一次典型的 登录绕过型 SQL 注入（利用注释符截断查询逻辑）。其根本成因包括：

• 登录表单中的用户名与密码参数直接拼接到 SQL 语句中；
• 未对单引号、注释符等特殊字符进行转义或过滤；
• 未采用参数化查询（Prepared Statement）或 ORM 框架的安全方法。

防御措施：

• 参数化查询 —— 将 SQL 代码与用户数据彻底分离，从根本上杜绝注入可能；
• 输入校验与过滤 —— 对用户名、密码等字段进行严格格式校验，并转义危险字符；
• 最小权限原则 —— 应用程序连接数据库的账户仅授予必要查询权限，降低注入成功后的危害。

本实验虽然基础，却清晰地揭示了注释符在 SQL 注入攻击中的关键作用。后续实验中，我将继续深入学习联合查询（UNION）攻击、盲注等进阶技巧。

博客园技术分享 · 请勿用于非法测试