【网络安全】文件上传绕过思路

上周我遇到了文件上传绕过的情况。

项目渗透过程中，遇到加载白名单的限制。

我经常感觉白名单是相当安全的。

实际操作过程中，可能会出现加载接口漏网的情况。

看看界面上的信息就可以了。

测试可能的加载接口，例如“temp”和“test”。

发现接口存在后缀等限制。

仅允许使用特定后缀。

尝试使用伪后缀，例如“cer”后缀。

绕过限制，可以上传文件。

上传成功后，您就可以访问内网了。

后续操作会更容易。

情况2 类似。

在白名单中，使用“上传”接口。

但是接口限制有问题。

删除特定字符。

它实际上可以加载任何文件。

WAF 是另一个障碍。

获取域名的真实IP。

忽略 WAF 限制。

文件上传，高度隐藏。

案例3 ：加载Base64 文件。

观察包裹。

发现可以编辑特定字段。

编辑字段后，您可以上传任何文件。

外壳加载成功。

进一步获得权限。

案例4 是NGINX漏洞分析。

上传功能有白名单。

结合NGINX漏洞。

收购内联网据点。

漏洞挖掘非常重要。

文件上传成功，但没有路径。

使用 SQL 注入工具搜索 ID 号。

可以找到shell的地址。

直接显示文件名。

模糊匹配找到完整路径。

可以在目录之间上传。

使用“...”上传到根目录。

或上传 SSH 密钥。

系统用户覆盖率。

无法遍历目录并且不会注入。

查找网站日志文件。

使用原木喷砂工具。

你可以找到shell路径。

该文件包含并读取。

常见于射击场和CTF。

实际成功率很低。

绕过上传黑名单。

伪后缀是一种常见的策略。

获得外壳的过程相当具有挑战性。

挑战也很有趣。

渗透测试的魅力。

算了。

文件上传漏洞原理和绕过方式

文件上传漏洞是Web应用中常见的安全问题。
攻击者可以利用该漏洞对服务器进行非法操作。
此类漏洞通常出现在网站的文件上传功能中。
当网站代码没有严格检查上传文件的扩展名和类型时。
攻击者可以上传恶意文件。
一旦恶意文件被传递到易于使用的脚本解释器（例如 PHP），攻击者就会操纵数据库；它可以执行服务器文件管理和服务器命令执行等恶意活动。

这是一个陷阱，我不相信不要这样做。

Nginx 文件名逻辑漏洞（CVE-2013-4547）

上周我研究了 Nginx 漏洞 CVE-2 01 3 -4 5 4 7 这个漏洞非常有趣。
这使得 Nginx 无法正确解析请求的 URI，从而导致权限绕过和代码执行的风险。

正常情况下，Nginx只解析以.php结尾的文件。
但是，如果存在此漏洞，例如请求“1 .gif[0x2 0][0x00].php”时，Nginx 会错误地将其解析为“1 .gif[0x2 0]”，并将 SCRIPT_FILENAME 值设置为 fastcgi。
这样，fastcgi就会根据错误的文件名进行解析，从而产生解析漏洞。

2 02 3 年，我们尝试重现此漏洞。
首先，我在 /vulhub/nginx/CVE-2 01 3 -4 5 4 7 环境中启动了 Nginx 服务器。
目标IP为1 9 2 .1 6 8 .1 .1 3 7 接下来，我们将攻击机器的IP设置为1 9 2 .1 6 8 .1 .1
访问http://your-ip:8 08 0/，您将看到上传页面。
您尝试上传后缀不是 .php 的文件，例如“info_yjh.jpg”。
请记住在文件名后添加一个空格。

接下来，我访问http://your-ip:8 08 0/uploadfiles/1 .gif[0x2 0][0x00].php，发现PHP解析成功。
这使我们相信，深度利用此漏洞可能允许攻击者修改包并执行命令。
写完文字后，您可以访问相应的链接，了解更详细的使用方法。

影响范围相当广泛。
这个漏洞在当时的 Nginx 版本中非常常见。
因此，如果您仍在使用该版本，请立即升级。
算了，你就会明白的。

php和nginx如何交互

说到PHP和Nginx的交互，我对这件事了解得很透彻。
好吧，我给大家解释一下中间的步骤，就像我刚进入这个行业的时候一样。

首先，用户打开浏览器并输入URL，然后Nginx接收HTTP请求。
就好像你给餐厅打电话时，Nginx 就是接电话的服务员。
用户和Nginx首先要建立TCP连接，这是一次三向握手。
这个过程就像确认对方的身份，以确保电话那头的人确实是你要联系的人。

然后，Nginx 必须看看这个请求的用途。
它必须根据URL和文件后缀来确定它是静态资源还是动态资源。
静态资源有HTML、CSS、JS、图片等，Nginx直接从硬盘读取文件内容并发送给用户，事情就结束了。
但如果它是动态资源，例如 .php 文件，那么您必须继续下一步。

接下来，Nginx会将动态请求转发给FastCGI客户端，FastCGI会将请求转发给PHP-FPM，也就是PHP的进程管理器。
这就好比告诉服务员你要点东西，服务员就去厨房下单。

PHP-FPM收到请求后，必须转发给FastCGIWrapper。
这个Wrapper就像一个中间人，负责与PHP解析器进行通信。
然后，Wrapper会生成一个新的线程，调用PHP解析器来执行PHP脚本，比如查询数据库中的数据，处理业务逻辑，最后生成动态内容。

这个过程就像厨师在厨房做饭，做好后拿出来。
PHP解析器通过FastCGI将动态内容返回给PHP-FPM，然后PHP-FPM将其传回Nginx。

最后，Nginx将PHP返回的动态内容封装成HTTP响应消息并发回给用户。
用户看到网页上的内容，整个请求-响应周期就完成了。

说到这里，有异步和同步两种模式。
在异步模式下，Nginx先处理其他请求，然后再回来处理PHP请求。
同步模式下，Nginx可以直接返回解析后的资源，但PHP动态内容仍然要依赖PHP-FPM进行处理。

在性能优化方面，PHP-FPM通常作为独立的进程池运行，通过UnixSocket或TCP端口与Nginx通信。
因此，配置进程数量以避免资源竞争非常重要。
FastCGI协议可以让Nginx和PHP-FPM高效处理动态内容，不仅保证了静态资源的快速返回，也让动态脚本的执行更加灵活。

我在这里可能有点极端，但我认为掌握这些细节对于优化网站性能和改善用户体验确实至关重要。