从BJDCTF EzPHP看PHP代码审计中的多层编码与协议绕过技巧

1. 初识BJDCTF EzPHP的挑战

第一次看到这道题目时，我承认有点被它复杂的过滤规则吓到了。题目看似简单，就是让你通过一系列检查获取flag，但实际审计起来才发现处处是坑。这道题完美展示了PHP代码审计中常见的各种绕过技巧，特别是多层编码和协议利用的巧妙组合。

题目入口是一个看似普通的网页，但查看源码后会发现注释中藏有线索。这个设计很经典，很多CTF题目都喜欢把关键信息藏在HTML注释里。用base32解码注释内容后，我们得到了真正的入口文件1nD3x.php。这种"藏宝图"式的设计在CTF中很常见，提醒我们审计时一定要养成查看源码的好习惯。

拿到源码后，我习惯先整体浏览一遍代码结构。这道题设置了七重关卡，每关都有不同的过滤规则：

1. QUERY_STRING的黑名单过滤
2. debu参数的严格匹配
3. $_REQUEST的字母检测
4. file_get_contents的内容验证
5. sha1的强类型比较
6. create_function的代码注入
7. 最后的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

这里有几个技巧：

1. 对部分字符进行URL编码，避免触发第一关的黑名单
2. 在字符串末尾添加换行符，使正则匹配成功但字符串比较失败
3. 保持关键字符的可识别性，确保业务逻辑能正确执行

4. 利用$_REQUEST的特性绕过字母检测

第三关会检查所有$_REQUEST参数的值，如果包含字母就直接拒绝。$_REQUEST包含了GET、POST和COOKIE参数，而且POST参数会覆盖同名的GET参数。

绕过方法是先通过GET方法传入编码后的参数，再用POST方法传入纯数字的值覆盖。这样：

1. GET参数携带了必要的信息（经过URL编码）
2. POST参数满足了字母检测的要求
3. 由于代码先处理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

这里需要注意：

1. 对部分字符进行URL编码，避免触发之前的过滤规则
2. 明确指定MIME类型为text/plain
3. 直接内嵌所需内容，不需要base64编码

data协议在CTF中非常实用，它允许我们直接在URL中嵌入文件内容，常用于绕过各种文件读取限制。

6. sha1强比较的两种绕过方式

第五关要求两个不同的变量具有相同的sha1值，这是典型的哈希强比较绕过。常见的有两种方法：

1. 数组绕过：sha1函数处理数组时会返回NULL

sh%61na[]=1&p%61sswd[]=2

2. 哈希碰撞：寻找两个不同的字符串产生相同的sha1值

在CTF中通常使用第一种方法，因为它简单可靠。我在实际渗透测试中也遇到过类似场景，开发者没有考虑数组的特殊情况，导致认证被绕过。

7. create_function的代码注入技巧

最后一关是最复杂的，需要利用create_function的代码注入漏洞。create_function的工作原理是动态创建一个函数，但由于实现方式的问题，可能导致代码注入。

典型的注入方式是在第二个参数中闭合原函数定义，然后添加恶意代码。例如：

$code = 'create_function'; $arg = '}phpinfo();//';

在这道题中，我们需要：

1. 通过flag[code]参数设置$code为create_function
2. 通过flag[arg]参数注入恶意代码
3. 绕过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中，但直接包含会遇到各种限制：

1. 点号被过滤，无法直接写文件名
2. include关键字被过滤
3. 常规的编码方式被检测

解决方案是：

1. 使用require代替include
2. 对文件名进行base64编码
3. 或者使用取反操作绕过过滤

取反操作的步骤：

$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));//

这种取反操作在绕过复杂过滤时非常有效，我在一些实际系统的渗透测试中也成功应用过这种技术。