CTFHUB--SSRF(中)--FastCGI协议\Redis协议 以及gopherus工具攻击

Fastcgi协议分析 && PHP-FPM未授权访问漏洞 && Exp编写 | 离别歌

CTFHub-FastCGI协议及其ssrf漏洞_ctfhub fastcgi-优快云博客

SSRF - ctfhub -2【FastCGI协议、Redis协议、URL Bypass、数字IP Bypass、302跳转 Bypass、DNS重绑定Bypass】_ctfhub fastcgi-优快云博客

FastCGI协议

FastCGI是CGI的一种替代方法。CGI是Web服务器与编程语言交互的一个标准,但是CGI每次都需要启动一个新的进程来处理请求,这样效率很低。FastCGI是一个常驻型的CGI,它在服务器启动的时候先启动一个应用程序池,然后由这个应用程序池来管理和调度应用程序的执行。

FastCGI的工作流程如下:

  1. Web服务器启动时载入FastCGI进程管理器

  2. FastCGI进程管理器初始化并等待从Web服务器发来的请求

  3. 当客户端请求到达Web服务器时,FastCGI进程管理器启动一个或多个FastCGI进程,这个进程执行特定的应用程序,处理请求,并返回结果给Web服务器

  4. FastCGI进程继续等待并处理来自Web服务器的请求,而不是结束

Fastcgi其实是一个通信协议,和HTTP协议一样的通信,都是进行数据交换的一个通道。只不过http协议是浏览器(即客户端)于服务器中间件的通信协议,而FastCGI协议是服务器中间件和某种语言编写的正在运行的后端程序间的通信协议。这张图能很清楚的表达

HTTP协议是浏览器和服务器中间件进行数据交换的协议,浏览器将HTTP头和HTTP体用某个规则组装成数据包,以TCP的方式发送到服务器中间件,服务器中间件按照规则将数据包解码,并按要求拿到用户需要的数据,再以HTTP协议的规则打包返回给服务器。

而fastcgi协议则是服务器中间件和某个语言后端进行数据交换的协议。Fastcgi协议由多个record组成,record也有header和body一说,服务器中间件将这二者按照fastcgi的规则封装好发送给语言后端,语言后端解码以后拿到具体数据,进行指定操作,并将结果再按照该协议封装好后返回给服务器中间件。

漏洞原理:

PHP-FPM默认监听9000端口,如果这个端口暴露在公网,则我们可以自己构造fastcgi协议,和fpm进行通信。本来我们可以执行任意文件,但是在FPM某个版本之后,增加了security.limit_extensions选项,限定了只有某些后缀的文件允许被fpm执行,默认是.php,所以现在要使用这个漏洞,我们得先知道服务器上的一个php文件,假设我们爆破不出来目标环境的web目录,我们可以找找默认源安装后可能存在的php文件,比如/usr/local/lib/php/PEAR.php。

​ 现在我们已经有可以执行代码的思路了,但是仅仅这样我们只能执行服务器上已有的代码,不能任意执行,所以我们还得想办法上传自己的代码,PHP.INI中有两个有趣的配置项,auto_prepend_file和auto_append_file。

auto_prepend_file是告诉PHP,在执行目标文件之前,先包含auto_prepend_file中指定的文件;auto_append_file是告诉PHP,在执行完成目标文件后,包含auto_append_file指向的文件。

​ 假设我们设置auto_prepend_file为php://input,那么就等于在执行任何php文件前都要包含一遍POST的内容。所以,我们只需要把待执行的代码放在Body中,他们就能被执行了。(当然,还需要开启远程文件包含选项allow_url_include)。设置auto_prepend_file的值又涉及到PHP-FPM的两个环境变量,PHP_VALUE和PHP_ADMIN_VALUE。这两个环境变量就是用来设置PHP配置项的,PHP_VALUE可以设置模式为PHP_INI_USER和PHP_INI_ALL的选项,PHP_ADMIN_VALUE可以设置所有选项。(disable_functions除外,这个选项是PHP加载的时候就确定了,在范围内的函数直接不会被加载到PHP上下文中),所以我们在传入环境变量是加入

'PHP_VALUE': 'auto_prepend_file = php://input',
'PHP_ADMIN_VALUE': 'allow_url_include &

### CTFHub Web平台中的SSRF漏洞利用Post请求 #### SSRF漏洞概述 服务器端请求伪造(Server-Side Request Forgery, SSRF)是一种攻击方式,其中攻击者能够诱使服务器向任意URL发出HTTP请求。这种攻击可能让攻击者绕过防火墙和其他安全控制措施,访问内部网络资源或敏感数据。 当应用程序允许用户输入并将其作为部分构建对外部服务的请求时,如果没有适当验证这些输入,则可能存在SSRF风险[^1]。 #### Post请求下的SSRF漏洞利用实例 在某些情况下,Web应用会接受来自用户的POST参数,并基于此创建新的HTTP POST请求到指定的目标位置。假设有一个接口`/api/fetchData`接收两个字段:一个是目标网址(`url`);另一个是要发送的数据体(`data`)。如果这个API不对传入的`url`做任何校验就直接发起请求的话,那么它就是一个潜在的SSRF入口点[^3]。 例如,在CTF场景下,可以通过构造如下表单提交来测试是否存在此类漏洞: ```html <form action="http://example.com/api/fetchData" method="POST"> <input type="hidden" name="url" value="http://internal-service/admin"/> <textarea name="data">{"action":"listUsers"}</textarea> <button>Submit</button> </form> ``` 一旦成功触发该行为,服务器就会尝试连接至所提供的内部路径并向其传递JSON负载,这可能导致未授权的信息泄露或其他更严重的后果。 #### 防御策略建议 为了防止上述情况的发生,应该采取以下几种方法加强防护: - **严格验证所有外部可控变量**:确保每一个由客户端提供的值都被仔细审查,特别是那些用来组成最终调用链路的部分。 - **采用白名单模式限定可到达的目的地集合**:仅限于已知可信站点列表内的链接才被准许处理,拒绝一切超出范围之外的选择。 - **实施细粒度的身份认证与权限管理**:即使是在受控环境之内也要遵循最小特权原则,即只有真正必要的时候才能给予特定实体执行高危动作的权利。 另外值得注意的是,除了基本防范手段外还可以考虑引入诸如代理层之类的技术方案进一步隔离内外网之间的交互过程,减少暴露面的同时也增加了中间件层面的安全保障能力[^4]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值