1. 初识BJDCTF EzPHP的挑战
第一次看到这道题目时，我承认有点被它复杂的过滤规则吓到了。题目看似简单，就是让你通过一系列检查获取flag，但实际审计起来才发现处处是坑。这道题完美展示了PHP代码审计中常见的各种绕过技巧，特别是多层编码和协议利用的巧妙组合。
题目入口是一个看似普通的网页，但查看源码后会发现注释中藏有线索。这个设计很经典，很多CTF题目都喜欢把关键信息藏在HTML注释里。用base32解码注释内容后，我们得到了真正的入口文件1nD3x.php。这种"藏宝图"式的设计在CTF中很常见，提醒我们审计时一定要养成查看源码的好习惯。
拿到源码后，我习惯先整体浏览一遍代码结构。这道题设置了七重关卡，每关都有不同的过滤规则：
- QUERY_STRING的黑名单过滤
- debu参数的严格匹配
- $_REQUEST的字母检测
- file_get_contents的内容验证
- sha1的强类型比较
- create_function的代码注入
- 最后的flag隐藏机制
2. 突破QUERY_STRING的黑名单
第一关的过滤非常严格，直接检查$_SERVER['QUERY_STRING']中是否包含黑名单关键词。这里有个关键知识点：$_SERVER['QUERY_STRING']获取的是原始未解码的URL参数，而$_GET会自动进行URL解码。
我曾在实际项目中遇到过类似情况。当时为了绕过WAF的检测，我们团队就利用了编码差异的特性。在这道题中，解决方案是对所有可能触发黑名单的参数名和值进行URL编码。例如：
- 把shana编码为sh%61na
- 把passwd编码为p%61sswd
这种编码方式能有效绕过基于关键词的过滤，因为黑名单检查的是原始字符串，而PHP在处理时会自动解码。需要注意的是，编码时要确保解码后的字符仍然是有效的变量名。
3. 换行符绕过正则匹配
第二关要求debu参数必须正则匹配/^aqua_is_cute$/，但又不能完全等于"aqua_is_cute"。这种看似矛盾的要求其实可以通过换行符绕过。
preg_match函数在默认情况下会用$匹配字符串结尾，但遇到换行符时会停止匹配。因此我们可以在字符串末尾添加%0a（URL编码的换行符），构造如下payload：
deb%75=aq%75a_is_c%75te%0a这里有几个技巧：
- 对部分字符进行URL编码，避免触发第一关的黑名单
- 在字符串末尾添加换行符，使正则匹配成功但字符串比较失败
- 保持关键字符的可识别性，确保业务逻辑能正确执行
4. 利用$_REQUEST的特性绕过字母检测
第三关会检查所有$_REQUEST参数的值，如果包含字母就直接拒绝。$_REQUEST包含了GET、POST和COOKIE参数，而且POST参数会覆盖同名的GET参数。
绕过方法是先通过GET方法传入编码后的参数，再用POST方法传入纯数字的值覆盖。这样：
- GET参数携带了必要的信息（经过URL编码）
- POST参数满足了字母检测的要求
- 由于代码先处理GET再处理POST，实际执行时使用的是GET参数的值
这种参数覆盖的技巧在CTF中很常见，我在审计真实系统时也发现过类似漏洞。开发者往往低估了参数传递的复杂性，导致安全检查被绕过。
5. 巧用data协议绕过文件内容检查
第四关要求读取的文件内容必须是"debu_debu_aqua"，但服务器上显然没有这样的文件。由于http和https协议被禁止，我们可以使用data协议来构造所需内容。
data协议的基本格式是：
data:[<mediatype>][;base64],<data>在这道题中，我们构造：
file=data://text/plain,deb%75_deb%75_aq%75a这里需要注意：
- 对部分字符进行URL编码，避免触发之前的过滤规则
- 明确指定MIME类型为text/plain
- 直接内嵌所需内容，不需要base64编码
data协议在CTF中非常实用，它允许我们直接在URL中嵌入文件内容，常用于绕过各种文件读取限制。
6. sha1强比较的两种绕过方式
第五关要求两个不同的变量具有相同的sha1值，这是典型的哈希强比较绕过。常见的有两种方法：
- 数组绕过：sha1函数处理数组时会返回NULL
sh%61na[]=1&p%61sswd[]=2- 哈希碰撞：寻找两个不同的字符串产生相同的sha1值
在CTF中通常使用第一种方法，因为它简单可靠。我在实际渗透测试中也遇到过类似场景，开发者没有考虑数组的特殊情况，导致认证被绕过。
7. create_function的代码注入技巧
最后一关是最复杂的，需要利用create_function的代码注入漏洞。create_function的工作原理是动态创建一个函数，但由于实现方式的问题，可能导致代码注入。
典型的注入方式是在第二个参数中闭合原函数定义，然后添加恶意代码。例如：
$code = 'create_function'; $arg = '}phpinfo();//';在这道题中，我们需要：
- 通过flag[code]参数设置$code为create_function
- 通过flag[arg]参数注入恶意代码
- 绕过arg参数的黑名单过滤
最终构造的payload如下：
fl%61g[c%6fde]=create_function&fl%61g[%61rg]=}var_dump(get_defined_vars());//这个payload会输出所有变量，包括隐藏的flag信息。在实际测试中，我发现很多开发者不了解create_function的危险性，导致严重的安全漏洞。
8. 进阶的文件包含与取反操作
本以为拿到flag就结束了，没想到题目还藏了一手。真正的flag在rea1fl4g.php中，但直接包含会遇到各种限制：
- 点号被过滤，无法直接写文件名
- include关键字被过滤
- 常规的编码方式被检测
解决方案是：
- 使用require代替include
- 对文件名进行base64编码
- 或者使用取反操作绕过过滤
取反操作的步骤：
$a = "php://filter/read=convert.base64-encode/resource=rea1fl4g.php"; echo urlencode(~$a);得到的payload：
fl%61g[%61rg]=}require(~(%8F%97%8F%C5%D0%D0%99%96%93%8B%9A%8D%D0%8D%9A%9E%9B%C2%9C%90%91%89%9A%8D%8B%D1%9D%9E%8C%9A%C9%CB%D2%9A%91%9C%90%9B%9A%D0%8D%9A%8C%90%8A%8D%9C%9A%C2%8D%9A%9E%CE%99%93%CB%98%D1%8F%97%8F));//这种取反操作在绕过复杂过滤时非常有效，我在一些实际系统的渗透测试中也成功应用过这种技术。
)
