file get contents漏洞shell

一个`.php`文件，内容只有一行``，就能把服务器上的敏感文件全抖出来。这玩意儿在CTF里叫“文件读取”，在实战里叫“任意文件读取漏洞”。我见过最蠢的用法是直接读`/etc/passwd`，最骚的操作是配合日志注入直接打RCE——但今天不谈RCE，只聊这个函数本身怎么变成shell的。

先泼盆冷水：`file_get_contents`本身不危险，危险的是你把它和用户输入拼在一起。比如某后台有个“导出报告”功能，代码写的是`file_get_contents('/var/www/reports/'.$_GET['name'])`，攻击者把`name`改成`../../../../etc/shadow`，路径穿越直接生效。更恶心的是PHP的`filter`协议——`php://filter/convert.base64-encode/resource=config.php`，能把源码base64编码后吐出来，绕过`.php`文件会被执行的限制。你问为啥要绕？因为直接读`.php`文件，服务器会先执行它，你只能看到执行结果，看不到源码。但用filter协议，源码就裸奔了。

有个真实案例，某电商站点的图片处理接口，参数`img=uploads/xxx.jpg`，后端用`file_get_contents($img)`把图片读进内存再裁剪。攻击者把参数改成`php://input`，POST一个PHP代码块——好家伙，服务器直接把POST内容当文件读，然后……没有然后，因为没写eval。但要是代码里多了个`include`或者`require`，那就直接变代码执行了。这种组合拳在渗透测试里叫“伪协议链”，实际利用时比想象中更常见。

防御手法其实老生常谈：白名单校验、`realpath()`强制路径规范化、禁用`allow_url_fopen`。但真正让人头疼的是业务逻辑漏洞——比如有的系统允许用户上传文件，然后通过`file_get_contents`读取上传文件内容做“在线预览”，攻击者上传一个包含PHP代码的`.txt`，虽然不会执行，但配合`file_get_contents`把内容回显到页面上——反射型XSS就出来了。这不算shell，但能钓鱼，能偷cookie。

最讽刺的是，有些开发者为了“安全”，把`file_get_contents`包装成自定义函数，加了一堆过滤，比如禁止`../`，禁止`http://`——结果攻击者用`php://filter`的`resource=`参数绕过，因为过滤规则只检查了字符串开头。我见过一个系统，过滤了`php://`，但没过滤`PHP://`——PHP的协议名不区分大小写。这种低级错误，比漏洞本身更让人血压升高。

说回shell这个标题。真正的shell不是靠`file_get_contents`直接拿的，而是靠它当跳板。比如先读`.env`文件拿到数据库密码，再连上MySQL写个`into outfile`生成webshell——这链条里，`file_get_contents`是第一步。或者读`/proc/self/environ`拿到UA头，配合日志注入把恶意代码写进日志文件，再通过`file_get_contents`包含日志——这就成了。我管这叫“曲线救国”，但现实中确实有人这么干成功过。

最后说点实操建议：如果你在代码审计里看到`file_get_contents`，别急着下结论，先看参数来源和过滤逻辑。如果参数直接来自`$_GET`、`$_POST`或者`$_COOKIE`，而且没有白名单——大概率能打。如果代码里还出现了`include`、`require`、`eval`这些函数，那这漏洞基本就是实锤的RCE。别迷信框架，框架也拦不住开发者自己写的烂代码。