详解CTF中常见的URL编码与Base64嵌套技巧

在渗透演练的赛场上，URL 编码与 Base64 的交叉使用几乎成了“暗号”。不少选手在抓取参数时会误把一次简单的解码当作终点，实则后面常埋藏着层层叠叠的再编码，像是把钥匙藏进了钥匙圈里。本文从原理切入，拆解几种典型的嵌套手法，并给出实战中常见的解码顺序，帮助读者在数分钟内把“看不见的文字”变成可读的线索。

URL 编码的原理与陷阱

URL 编码本质是把非 ASCII 字符或保留字符转成 %xx 形式，其中 xx 为十六进制值。多数浏览器在发送请求时会自动解码，但在源码或日志里常出现“半解码”状态——比如 %252F 实际代表 %2F，再解一次才是斜杠 /。选手若只做一次 urldecode，很可能错失隐藏路径。

Base64 在 CTF 中的常见用法

Base64 通过 6 位一组映射到可打印字符，常用于隐藏二进制或长文本。赛题里常见的做法是把敏感参数直接放进 GET 或 POST，再用 base64_encode 包裹；甚至把多段 Base64 串拼接，形成“碎片化”密文。解码时如果出现填充符 = 被 URL 编码成 %3D，又会触发二次 URL 解码。

嵌套实例：URL → Base64 → URL

http://example.com/?q=%2552%2545%2547%2545%254E%2545%2543%254F%2544%2545%253D
# 实际传递的参数是 %52%45%47%45%4E%45%43%4F%44%45=
# 第一次 urldecode → "REGENCODE="
# 再次 base64_decode → "FLAG{nested}"

• 先对 q 参数执行一次 urldecode，得到 REGENCODE=。
• 将结果再做一次 urldecode（因为原始字符串被双层编码），得到 REGENCODE。
• 对 REGENCODE 进行 base64_decode，即可得到最终 flag。

“别忘了检查两遍 URL 编码，尤其是 %25 开头的序列。”

如果把上述步骤写成脚本，往往只需要三行代码：urldecode、urldecode、base64_decode。这也是为什么很多新人在看到密文时会卡住——他们只跑了一遍 urldecode，结果得到的仍是看似毫无意义的字符。掌握了“双层 URL + Base64”这条链，很多看似高难度的 Web 题目瞬间变平。