SSRF/文件上传详解

发布于:2024-12-22 ⋅ 阅读:(19) ⋅ 点赞:(0)

文章细节及靶场资源

WuTongSec

文件上传

Content-Type

提交 HTML 表单时,浏览器通常会在 POST 请求中发送提供的数据,其内容类型 application/x-www-form-url-encoded 为 .这适用于发送您的姓名或地址等简单文本。但是,它不适合发送大量二进制数据,例如整个图像文件或 PDF 文档。在这种情况下,首选内容类型 multipart/form-data

上传的文件回显文本

用户提供的文件上载到的目录可能具有更严格的控制。如果能找到一种方法将脚本上传到不应该包含用户提供的文件的其他目录,那么服务器终究可能会执行脚本 ../exploit.php在文件这里加一个../跳出当前目录

image-20241219190530012

将 filename 参数的值更改为 .htaccess。
将 Content-Type 标头的值更改为 text/plain。
将文件的内容(您的 PHP 有效负载)替换为以下 Apache 指令:
AddType application/x-httpd-php .l33t
这会将任意扩展名 (.l33t) 映射到可执行的 MIME 类型 application/x-httpd-php。
由于 server 使用 mod_php 模块,因此它已经知道如何处理此问题。
我们在上传一个exploit.l33t 的webshell就行了

后缀名操作

提供多个扩展。根据用于解析文件名的算法,以下文件可能会被解释为 PHP 文件或 JPG 图像:exploit.php.jpg
添加尾随字符。一些组件会去除或忽略尾随的空格、点等:exploit.php。
尝试对点、正斜杠和反斜杠使用 URL 编码(或双 URL 编码)。如果在验证文件扩展名时该值未解码,但稍后在服务器端解码,则还允许您上传恶意文件,否则这些文件将被阻止:exploit%2Ephp
在文件扩展名之前添加分号或 URL 编码的空字节字符。例如,如果验证是用 PHP 或 Java 等高级语言编写的,但服务器使用 C/C++ 中的较低级别函数处理文件,这可能会导致文件名末尾的末尾出现差异:exploit.asp;。JPG 或 exploit.asp%00.jpg
尝试使用多字节 Unicode 字符,这些字符在 Unicode 转换或规范化后可能会转换为 null 字节和点。如果文件名解析为 UTF-8 字符串,则 xC0 x2E、xC4 xAE 或 xC0 xAE 等序列可以转换为 x2E,但在路径中使用之前转换为 ASCII 字符。
​
双写后缀
 .p.phphp

文件的完整性【图片】

有的服务器会验证上传的图片是否是真的图片 图片里面也有一些标签 什么的验证

用ExifTool 将一个 PHP 代码片段作为注释嵌入到 PNG 图像文件
exiftool -Comment="<?php echo 'START ' . file_get_contents('/home/carlos/secret') . ' END'; ?>" <YOUR-INPUT-IMAGE>.jpg -o polyglot.php

可以用exiftool看我们的文件里面元数据

image-20241219210323870

image-20241219210303106

ssrf

简单的利用

一种场景 我现在需要检查 我的商品库存还有多少,

image-20241219213432801

一种方案就是我点击的时候 去另一个接口查一下还有多少 就像下面这样

image-20241219213641277

这种就是典型的ssrf漏洞 我们可以把接口改为其他的

image-20241219213611660

但是我们不知道他本地的接口有那些 比如admin接口 可以1-255爆破

image-20241219213758922

ssrf绕过

有时候直接127.0.0.1会显示不安全等

image-20241219214251238

可以访问了

image-20241219214410705

敏感接口/admin 又提示不安全 说明还有过滤

image-20241219214530671

我们对admin这个单词进行双重url的编码即可绕过

image-20241219215329743

ssrf白名单绕过

你提到的这些技术确实可以用来绕过某些基于白名单的输入过滤器,尤其是在 URL 解析和验证过程中存在不一致的情况下。让我们详细解释一下每种技术的工作原理,以及它们如何被利用来绕过过滤器。

1. 使用 @ 字符嵌入凭证

工作原理
  • 标准 URL 格式https://username:password@hostname:port/path?query#fragment

  • 嵌入凭证:你可以使用 @ 字符将用户名和密码嵌入到主机名之前。例如:

    • https://expected-host:fakepassword@evil-host

绕过方式
  • 解析差异:某些应用程序或库在解析 URL 时可能会忽略 @ 之前的部分,只关注 @ 之后的主机名。因此,即使你提供了 expected-host:fakepassword@evil-host,应用程序可能会认为主机名是 evil-host,而忽略了前面的部分。

  • 应用场景:如果你知道应用程序会检查 expected-host 作为允许的白名单值,但实际请求会被发送到 evil-host,这可能会导致安全漏洞。

2. 使用 # 字符指示片段

工作原理
  • URL 片段# 字符用于指示 URL 的片段部分(也称为锚点),通常用于浏览器内的导航,不会被发送到服务器。

  • 示例https://evil-host#expected-host

绕过方式
  • 解析差异:某些应用程序或库在解析 URL 时可能会忽略 # 之后的部分,只关注 # 之前的内容。因此,即使你提供了 https://evil-host#expected-host,应用程序可能会认为主机名是 evil-host,而忽略了后面的片段。

  • 应用场景:如果你知道应用程序会检查 expected-host 作为允许的白名单值,但实际请求会被发送到 evil-host,这可能会导致安全漏洞。

3. 利用 DNS 命名层次结构

工作原理
  • 完全限定域名 (FQDN):DNS 命名层次结构允许你创建子域名。例如,expected-host.evil-host 是一个有效的 FQDN,其中 expected-hostevil-host 的子域名。

  • 示例https://expected-host.evil-host

绕过方式
  • 解析差异:某些应用程序或库在解析 URL 时可能会逐级解析域名,或者只检查顶级域名。因此,即使你提供了 https://expected-host.evil-host,应用程序可能会认为 expected-host 是一个允许的白名单值,而忽略了 evil-host

  • 应用场景:如果你控制了 evil-host,并且知道应用程序会检查 expected-host 作为允许的白名单值,你可以通过这种方式绕过过滤器。

4. URL 编码和双重编码

工作原理
  • URL 编码:将特殊字符转换为 % 加上两位十六进制数的形式,以便它们可以在 URL 中安全传输。例如,a 编码为 %61

  • 双重编码:对已经经过一次 URL 编码的字符串再次进行编码。例如,%61 编码为 %25%36%31

绕过方式
  • 解析差异:某些应用程序或库在处理 URL 编码时可能会有不同的行为。例如,前端的输入验证代码可能只会进行一次解码,而后端的 HTTP 请求处理代码可能会进行多次解码。这种差异可以被利用来绕过过滤器。

  • 应用场景:如果你知道应用程序会检查未编码的 admin 字符串,但你通过双重编码将其变为 %25%36%31dmin,前端验证可能会忽略这个编码,而后端处理时会正确解码并执行请求。

5. 结合使用多种技术

工作原理
  • 组合攻击:你可以结合使用上述多种技术,以增加绕过过滤器的成功率。例如,你可以同时使用 @ 字符、# 字符、DNS 层次结构和 URL 编码,构造一个复杂的 URL 来绕过多个层级的过滤。

https://expected-host:fakepassword@evil-host#expected-host/admin
  • 解析差异:在这个例子中:

    • expected-host:fakepassword@evil-host 可能会被解析为 evil-host

    • #expected-host 可能会被忽略。

    • /admin 可能会在后端处理时被正确解析。

ssrf重定向绕过

具体的

next product 功能点击后会跳转到下一个接口是一个重定向的功能【这个功能可以用来进行ssrf的绕过】

image-20241219222122639

image-20241219222051580

这个next product的接口可以跳转

而check stock的接口是ssrf 在ssrf这里请求跳转接口 /product/nextProduct?path=http://192.168.0.12:8080/admin

这样请求就不会出现认证失败的情况