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)攻击、盲注等高级技巧。


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

相关推荐
сокол6 小时前
【网安-Web渗透测试-免杀系列】内存免杀(无文件落地)
windows·网络安全
学习溢出8 小时前
【网络安全】追踪PowerShell命令历史
安全·网络安全
Sombra_Olivia9 小时前
Vulhub 中的 cmsms CVE-2019-9053 & CVE-2021-26120
安全·web安全·网络安全·渗透测试·vulhub
大方子11 小时前
【PolarCTF】bllbl_ser1
网络安全·polarctf
Chengbei1111 小时前
小程序 AI 渗透新工具MCP!打通调试与安全检测、网络抓包、接口分析、越权检测一站式实现
人工智能·安全·web安全·搜索引擎·网络安全·小程序·系统安全
humors22111 小时前
Windows运维与安全场景合集(不定期更新)
大数据·运维·服务器·程序人生·网络安全
X7x512 小时前
安全编排自动化与响应(SOAR):重塑企业安全运营的新引擎
网络安全·网络攻击模型·安全威胁分析·安全架构·soar
humors22112 小时前
聊聊密码为啥会“白设”
大数据·运维·服务器·网络·网络安全
消失的旧时光-194312 小时前
Android企业级网络架构实战:一套完整的双Token认证解决方案 ——(401自动续期|请求重放|RefreshToken刷新|并发401治理)
网络安全·网络框架·双token·android 网络认证架构