PortSwigger SQL注入LAB 1

PortSwigger SQL注入实验室（一）
利用WHERE子句漏洞检索未发布产品

本实验来自 PortSwigger Web Security Academy。是 SQL 注入系列的第一个基础实验,目标是通过分析URL参数与页面响应，推测SQL查询结构并构造注入载荷，最终获取未发布产品的数据。

通过该实验可以理解：当应用程序将用户输入直接拼接到 SQL 查询中且未做恰当处理时，攻击者能够篡改原始查询逻辑，获取未授权数据。

【实验目标】
产品类别筛选功能存在 SQL 注入漏洞。应用程序在用户选择类别时执行如下查询：
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
利用注入漏洞让数据库返回一个或多个未发布的产品（即 released = 0 的数据）。

1. 原始查询逻辑分析

题目提供的 SQL 语句：

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

该查询从 products 表中选取所有列，条件为：
  ▸ 类别 (category) 等于 'Gifts'；
  ▸ 且 released 字段值为 1（表示已发布）。
我们的攻击目标是绕过 released = 1 的限制，使数据库同时返回 released = 0 的未发布产品。

2. 初步观察与逻辑推测

启动实验室，可以看到一个典型的购物页面，提供了一个“Refine your search”分类筛选功能。

点击任意分类（如 Accessories），页面仅展示该类别下已发布的产品，观察到地址栏变为：

/filter?category=Accessories

此时我们虽然看不到后台代码，但根据题目提示可以合理推测的后台查询模板为：

SELECT * FROM products WHERE category = '[用户输入]' AND released = 1

用户的输入 Accessories 被直接放入单引号内。

3. 漏洞验证

尝试破坏查询语法：将 category 参数改为一个单引号。

/filter?category='

页面返回 Internal Server Error，说明后端 SQL 语句因多出一个单引号而语法错误。

据此可进一步推测：
错误发生时的SQL结构：

SELECT * FROM products WHERE category = ''' AND released = 1

—— 输入的单引号提前闭合了字符串，导致后续 AND released = 1 成为游离文本，引发语法错误。

由此可得:该位置存在 SQL 注入漏洞，且注入点为单引号字符串上下文。

4. 构造攻击载荷（Payload）

为了获取所有产品（包括未发布的），需要消除 category 限制并跳过 released = 1 条件。

4.1 使用注释符消除尾部条件

初步尝试使用注释 -- （注意：MySQL 中 -- 后需加空格；此处实验环境为通用 SQL 语法，-- 后跟任意字符即可）。假设我们提交：' --
则查询变为：

SELECT * FROM products WHERE category = '' --  AND released = 1

这样虽然注释掉了 released 条件，但 category = '' 依然生效，只会返回类别为空字符串的产品（通常不存在）。因此我们需要让 category 条件也失去约束力。

4.2 引入 OR 永真条件

我们需要让整个 WHERE 子句恒为真。在注释之前添加 OR 1=1：

推测拼接出的 SQL 语句变为：

SELECT * FROM products WHERE category = '' OR 1=1 --  AND released = 1

逻辑分析：

• category = '' 为假；
• 1=1 永远为真，通过 OR 连接使得整个条件恒成立；
• 注释符 -- 使后面的 AND released = 1 失效。

因此，该 Payload 将返回 products 表中的全部记录，包括未发布产品。

4.3 执行最终请求

在浏览器地址栏输入（空格可用 + 替代）：

/filter?category='+OR+1=1+--+

页面显示了原本隐藏的未发布产品，实验目标达成。

【本题最终Payload】

' OR 1=1 --

URL 中使用时注意空格编码：' OR 1=1 --+ 或 ' OR 1=1 --%20

5. 总结与防御建议

本实验是一次典型的 基于布尔条件的 WHERE 子句注入（未使用 UNION）。根本原因在于：

• 用户输入与 SQL 语句通过字符串拼接；
• 未对单引号等特殊字符进行转义或过滤；
• 未采用参数化查询（Prepared Statement）。

防御措施：

• 参数化查询 —— 将数据与代码彻底分离；
• 输入校验 —— 限制 category 参数仅允许字母数字；
• 最小权限原则 —— 应用数据库账户仅授予必要权限。

这个实验虽然简单，但清晰地揭示了 SQL 注入的核心原理。后续的实验中我将继续深入学习探索联合查询（UNION）攻击、盲注等高级技巧。

---

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