★ FEATURED ARTICLE 1. 从一道题看透 parse_url 的“脾气”parse_url这个函数写过 PHP 的人几乎都用过但真正把它“玩明白”的人不多。我第一次在 ctfshow 上碰到这道parse_url相关的题目时心里想的是不就是个解析 URL 的内置函数吗能有什么坑结果提交了七八次 payload 全被拦才意识到这玩意儿的水比想象中深得多。这道题的核心不是让你去攻击什么真实系统而是借一个模拟的 URL 校验场景逼你把parse_url在边界情况下的解析行为彻底摸清楚——它怎么切协议、怎么认主机、怎么处理用户名密码、遇到畸形字符串又会返回什么。说白了这道题解决的是一个非常具体的问题当后端用parse_url提取 URL 的各个组成部分再基于这些部分做安全判断时攻击者能否构造一个“解析结果和实际访问目标不一致”的 URL从而绕过校验。这个知识点适合谁适合已经会写 PHP 基础代码、但对内置函数边界行为不够敏感的同学也适合做 Web 安全入门训练、想理解“解析器差异”这类经典问题的人。哪怕你平时不做安全只要你的代码里出现过parse_url配合白名单校验这篇文章里的坑你大概率也会踩。我先把结论摆前面parse_url不是一个“严格校验器”它是一个“尽力而为的解析器”。它对畸形输入非常宽容很多在浏览器里根本打不开的字符串它都能给你解析出一个看似合理的数组。这种宽容正是所有绕过手法的根源。下面我按自己的复现思路把这道题从头拆一遍。2. 题目场景还原与整体思路拆解2.1 这道题到底在考什么ctfshow 上这类parse_url题目通常的形态是给你一段模拟的 PHP 源码或者一个在线环境源码逻辑大致是接收一个 URL 参数用parse_url拆出host、scheme等字段然后判断 host 是否在白名单里、scheme 是否是 http/https全部通过才“放行”到下一步。题目的目标就是构造一个输入让校验逻辑认为它是合法的但实际语义上指向了别的地方。这里要先建立一个认知parse_url的解析结果和浏览器实际发起请求时的目标可能完全不是一回事。校验代码信任的是parse_url的输出而真正“访问”时遵循的是另一套规则浏览器或下游组件的解析逻辑。两者之间的缝隙就是这道题的突破口。理解这一点比记住任何一个具体 payload 都重要。我在复现时做的第一件事不是急着构造 payload而是把parse_url在各种输入下的返回值全部打印出来建一张“行为对照表”。这个习惯救了我很多次——很多绕过手法不是想出来的是对比出来的。2.2 为什么选择从解析差异入手面对一个 URL 校验场景常见的思路有三条一是找白名单本身的逻辑漏洞比如大小写、后缀判断二是找参数污染或多次解析的差异三是直接研究解析器本身的行为边界。前两条依赖具体代码换一道题就失效第三条是“根”上的东西parse_url的行为是 PHP 版本决定的学会了就能迁移。我选第三条是因为这道题的标题已经把方向点明了——它就叫parse_url出题人显然是想让你聚焦这个函数本身。而且从投入产出比看把parse_url的边界行为摸一遍成本不高一个脚本就能批量测收益却很持久。后面你会发现很多看似花哨的 payload本质都是在利用同一个特性parse_url对某些字符的处理方式和下游不一致。具体来说我关注三个维度协议部分怎么被识别、host 部分到哪里截止、特殊字符如、\、#、?、多个/如何影响分段。这三个维度基本覆盖了这类题目的所有变体。2.3 整体验证框架的搭建为了高效对比我写了一个小脚本把一批候选字符串丢进parse_url把结果格式化成表格。这样一眼就能看出哪个输入产生了“意料之外”的 host。框架很简单一个字符串数组循环调用输出scheme、host、user、pass、path几个关键字段。别小看这个动作手工一个个试很容易漏批量跑一遍能发现很多反直觉的结果。我用的测试环境是本地搭的一个 PHP 运行环境版本选的是题目环境相近的版本这点很重要parse_url在不同大版本间有过行为调整用错版本测出来的结论可能不适用。测试字符串覆盖了正常 URL、带用户信息的 URL、带反斜杠的、带多重斜杠的、带编码字符的、以及各种畸形拼接。下面几节我会把关键发现逐条展开。3. parse_url 核心行为细节全解析3.1 协议识别它比你想象的宽松先看协议部分。正常输入http://example.comparse_url返回的scheme是http这没什么好说的。但当你输入一些奇怪的组合时它的判定就没那么直观了。比如协议名里允许出现哪些字符我实测下来字母、数字、加号、减号、点号在协议段里基本都能被接受只要后面跟着://。这意味着如果你在校验里只判断scheme http那构造一个http开头但后面结构诡异的串是有操作空间的。更关键的一点parse_url对://的依赖很强但对斜杠的数量和方向并不严格。我试过http:///example.com三个斜杠它依然能解析出 host 为example.com。也试过http:\\example.com这种反斜杠形式在某些版本下它会把反斜杠当作路径分隔符处理host 的判定就会变得微妙。这些行为在浏览器里未必成立但校验代码只看parse_url的结果所以差异就出现了。这里有个实操心得不要凭记忆判断某个畸形串的解析结果一定要实际跑一遍。我一开始笃定某个带反斜杠的串会被解析成路径结果打印出来 host 竟然被识别了直接推翻了我的假设。从那以后我养成了“先打印再下结论”的习惯。3.2 host 的边界 符号是重灾区在 URL 里的语义是“用户信息分隔符”user:passhost这种形式里前面是用户信息后面才是 host。parse_url严格遵守这个规则它会找最后一个注意是最后一个不是第一个把前面的当用户信息后面的当 host。这个“找最后一个”的行为是很多绕过的核心。假设校验代码天真地认为“URL 里第一个后面就是 host”而parse_url取的是最后一个后面的部分两者就会产生分歧。构造一个包含多个的串就能让校验方和解析方看到不同的 host。我在测试里用http://abc这种形式验证过parse_url给出的 host 是cuser 是ab或者按版本不同拆成a和b的组合总之 host 落在最后一段。还有一个细节值得记当出现在路径部分即 host 已经确定之后时它就不再影响 host 判定了。所以 payload 里的位置非常讲究放错地方就前功尽弃。这也是为什么很多人照着别人的 payload 抄却打不通——位置差一个字符解析结果就完全不同。3.3 特殊字符的连锁反应除了还有几个字符会显著改变解析走向。#是片段标识符它后面的内容会被归入fragment不再参与 host 和 path 的判定?是查询串起点同理。这两个字符如果出现在 host 应该出现的位置之前就能“截断”掉后面的内容让 host 判定提前结束。反斜杠\是个更微妙的存在。在标准 URL 里它不该出现但parse_url对它的容忍度因版本而异。我实测发现某些情况下反斜杠会被当作普通路径字符某些情况下又会影响分段。这种不确定性恰恰是出题人喜欢利用的点——因为校验代码和实际访问组件对反斜杠的理解往往不一致。还有一个容易被忽略的多重斜杠和点号路径。http://example.com/../admin这种带..的路径parse_url不会帮你做规范化它原样保留在 path 里。如果你的校验逻辑只看 host 不看 path那 path 里的花样就完全不受约束。这一点在真实代码审计里也经常被忽视。3.4 返回值类型与失败情形parse_url在解析失败时返回false而不是抛异常。这个特性意味着如果校验代码写成if (parse_url($url)[host] xxx)遇到返回false的输入取数组下标会得到 null配合错误抑制判断自然不成立看起来“安全”。但如果代码写成先判断! false再取字段逻辑就不同了。我特意测了一批“看起来像 URL 但解析失败”的串比如纯空格、只有协议没有内容、超长畸形串等。发现有些输入会返回部分字段比如只有 path 没有 host有些直接false。这个差异提醒我校验代码对“解析结果不完整”的处理方式本身就是一个攻击面。如果代码假设“只要不是 false 就一定有 host”那构造一个“解析成功但没有 host”的输入就可能让后续逻辑走进意料之外的分支。4. 实操复现从零构造可用 payload4.1 环境准备与测试脚本我本地用的是命令行方式跑 PHP 片段不依赖任何框架一个文件就够。核心就是把候选串数组循环丢给parse_url用var_export打印结果。为了让对比更直观我在输出里加了分隔线和原始输入方便回溯。这个脚本我建议每个做这类题的人都自己写一遍比看别人的结论印象深得多。脚本结构大致是定义$tests数组foreach遍历对每个元素调用parse_url然后打印scheme、host、user、pass、path、query、fragment这几个键用??兜底避免报错。跑一遍就能得到一张完整的对照表。我实际跑的时候准备了三十多个候选串覆盖了正常、带、带反斜杠、带多重斜杠、带编码、带#/?截断等各类情况。提示测试时务必确认 PHP 版本与题目环境一致。parse_url在较老版本和较新版本之间对反斜杠和某些畸形串的处理存在差异用错版本得出的结论可能直接导致 payload 失效。4.2 关键 payload 的构造与验证过程构造 payload 的思路是“逆向”的先想清楚我要让parse_url解析出什么 host白名单里的那个再想清楚我要让实际语义指向哪里然后找一种写法让这两者分离。最经典的手法就是利用把白名单 host 放在后面让parse_url认为 host 合法而把真正想指向的目标放在前面作为“用户信息”。我实际验证时先写了一个最朴素的http://目标白名单host打印出来 host 确实是白名单 hostuser 是目标。这一步确认了方向可行。但题目往往还有 scheme 校验和路径校验于是我又在这个基础上叠加用#或?截断掉可能触发额外校验的部分用多重斜杠调整分段。每改一次就重新打印确认 host 没跑偏。这里有个我踩过的坑某些 payload 在parse_url里 host 正确但下游组件解析时 host 却变成了目标。也就是说光看parse_url的输出还不够还得考虑“实际访问”那一侧的解析规则。这道题虽然是模拟环境但这个思维不能丢——真实场景里校验方和访问方用的往往不是同一个解析器差异才是漏洞。4.3 参数选择背后的计算逻辑为什么选这个字符而不是那个我总结了一个判断依据看校验代码取了parse_url返回数组的哪几个键。如果它只取host那我重点操作和截断字符如果它还取scheme我就得保证协议段干净如果它检查path是否包含某些关键字我就用#/?把敏感部分挪到不被检查的字段里。举个具体的假设校验要求 host 必须是白名单域名且 path 不能包含admin。那我可以构造http://白名单域名#/admin此时parse_url的 path 是空或/fragment才是/adminpath 检查通过但实际访问时片段标识符不发给服务端所以这个写法在真实场景里意义有限——这正说明“理解每个字段的实际语义”比“机械套 payload”重要。我在做题时会把每个字段的语义和它在真实请求中的去向都过一遍避免构造出“解析对了但实际没用”的假 payload。5. 常见问题与排查技巧实录5.1 为什么我的 payload 打印出来 host 不对这是最高频的问题。原因通常有三类一是的位置放错了parse_url取最后一个如果你在目标后面又加了一个host 判定就会后移二是中间混入了#或?导致 host 段被提前截断三是用了反斜杠但版本不匹配解析行为和预期不同。排查方法很土但有效把 payload 拆成最小片段一段段加每加一段打印一次看 host 在哪一步跑偏。我遇到过最隐蔽的一次是 payload 里有个不可见字符复制粘贴带进来的肉眼完全看不出来但parse_url的解析结果就是不对。后来用十六进制查看才发现。所以如果你反复检查逻辑都没问题不妨看看字符串里有没有混入奇怪字符。5.2 校验通过了但“下一步”没反应这种情况说明你的 payload 让校验逻辑满意了但实际语义没达到目的。根因往往是“校验方和访问方解析不一致”这个差异没有被真正利用起来——你只是让parse_url输出了合法 host但下游组件解析同一个串时host 也是合法的那就没有绕过效果。解决办法是回到“两侧解析规则对比”上找一个在parse_url里 host 合法、在下游解析里 host 指向别处的写法。和反斜杠通常是这类差异的高发区。5.3 常见问题速查表现象可能原因排查动作host 解析成了目标而非白名单位置错误或数量不对确认最后一个后面是白名单 hosthost 为空或字段缺失被#/?提前截断检查截断字符是否出现在 host 段之前解析结果与预期完全不符PHP 版本差异或混入不可见字符换版本重测十六进制检查字符串校验通过但无效果两侧解析规则一致未形成差异对比parse_url与下游组件的解析结果返回 false 导致逻辑异常输入畸形到无法解析检查是否触发了“解析失败”分支5.4 几条踩坑换来的经验第一条永远先打印再下结论。我早期凭直觉判断解析结果错了不止一次浪费的时间远超写个打印脚本的成本。第二条payload 要最小化。能用一个解决的就别加一堆花哨字符字符越多不可控因素越多排查越难。第三条别迷信别人的 payload。环境版本、校验代码细节稍有不同同一个串的结果就可能天差地别理解原理后自己构造才靠谱。还有一条偏思维层面的做这类题时我会刻意区分“解析层”和“语义层”。解析层是parse_url给出的数组语义层是这个 URL 在真实请求里意味着什么。绝大多数绕过本质都是这两层的不一致。把这两层分开想思路会清晰很多也不容易被具体的 payload 形式带偏。6. 从这道题延伸出的通用防御视角做完题不能只停留在“打通了”我习惯反过来想如果我是写校验代码的人怎么防答案其实就藏在上面那些坑里。首先不要用parse_url的结果直接做安全判断它是个解析器不是校验器对畸形输入太宽容。其次如果非要用必须对解析结果的完整性做严格检查——host 必须存在、scheme 必须在白名单、不能有用户信息段user/pass非空直接拒绝。再者校验用的解析逻辑和实际访问用的解析逻辑要尽量统一避免“两套规则”带来的差异。我在实际写代码时养成了一个习惯凡是涉及 URL 白名单的地方先拒绝掉所有含、反斜杠、多重斜杠、编码字符的输入再做解析。这种“先收紧再解析”的顺序比“先解析再判断”稳得多。因为解析器的宽容度你控制不了但输入的字符集你可以控制。这个思路不只适用于parse_url任何“解析后校验”的场景都值得借鉴——解析器的边界行为是无穷的而你能白名单化的字符是有限的。最后分享一个小技巧如果你在本地复现时结果和题目环境对不上优先怀疑版本差异其次怀疑字符编码。我一般会先用一个已知能通的简单 payload 在题目环境里验证一次确认环境行为基线再往上叠加复杂构造。这个“先校准再实验”的步骤能省掉大量“明明本地对、线上不对”的困惑。这道题的价值不在于记住某个 payload而在于让你对“解析器差异”这件事产生肌肉记忆——下次再看到任何基于字符串解析做判断的代码你都会下意识多问一句它解析出来的和实际用的是同一个东西吗
阅读完成 · 觉得有帮助？
