48. SSRF篇——SSRF原理+利用+防御

本文介绍了SSRF(Server-Side Request Forgery)漏洞的概念及其形成原因,列举了常见的SSRF漏洞应用场景,并详细阐述了如何查找和验证SSRF漏洞的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

SSRF概述

SSRF(Server-SideRequest Forgery:服务器端请求伪造)是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF攻击的目标是从外网无法访问的内部系统。(正是因为它是由服务端发起的,所以它能够请求到与它相连而与外网隔离的内部系统)

SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容,加载指定地址的图片,下载等等。

SSRF 漏洞的寻找

一、从WEB功能上寻找

我们从上面的概述可以看出,SSRF是由于服务端获取其他服务器的相关信息的功能中形成的,因此我们大可以列举几种在web 应用中常见的从服务端获取其他服务器信息的的功能。

1)分享:通过URL地址分享网页内容

早期分享应用中,为了更好的提供用户体验,WEB应用在分享功能中,通常会获取目标URL地址网页内容中的<tilte></title>标签或者<metaname="description" content=“”/>标签中content的文本内容作为显示以提供更好的用户体验。例如人人网分享功能中:

http://widget.renren.com/*****?resourceUrl=https://www.sobug.com

通过目标URL地址获取了title标签和相关文本内容。而如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞。

根寻这个功能,我们可以发现许多互联网公司都有着这样的功能,下面是我从百度分享集成的截图如下:

从国内某漏洞提交平台上提交的SSRF漏洞,可以发现包括淘宝、百度、新浪等国内知名公司都曾被发现过分享功能上存在SSRF的漏洞问题。

2)转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览

由于手机屏幕大小的关系,直接浏览网页内容的时候会造成许多不便,因此有些公司提供了转码功能,把网页内容通过相关手段转为适合手机屏幕浏览的样式。例如百度、腾讯、搜狗等公司都有提供在线转码服务。

3)在线翻译:通过URL地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等

4)图片加载与下载:通过URL地址加载或下载图片

图片加载远程图片地址此功能用到的地方很多,但大多都是比较隐秘,比如在有些公司中的加载自家图片服务器上的图片用于展示。(此处可能会有人有疑问,为什么加载图片服务器上的图片也会有问题,直接使用img标签不就好了?,没错是这样,但是开发者为了有更好的用户体验通常对图片做些微小调整例如加水印、压缩等,所以就可能造成SSRF问题)。

5)图片、文章收藏功能

此处的图片、文章收藏中的文章收藏就类似于功能一、分享功能中获取URL地址中title以及文本的内容作为显示,目的还是为了更好的用户体验,而图片收藏就类似于功能四、图片加载。

6)未公开的api实现以及其他调用URL的功能

此处类似的功能有360提供的网站评分,以及有些网站通过api获取远程地址xml文件来加载内容。

在这些功能中除了翻译和转码服务为公共服务,其他功能均有可能在企业应用开发过程中遇到。

二、从URL关键字中寻找

在对功能上存在SSRF漏洞中URL地址特征的观察,通过我一段时间的收集,大致有以下关键字:

如果利用google 语法加上这些关键字去寻找SSRF漏洞,耐心的验证,现在还是可以找到存在的SSRF漏洞。

 

SSRF 漏洞的验证

1)基本判断(排除法)

例如:    

http://www.douban.com/***/service?image=http://www.baidu.com/img/bd_logo1.png

排除法一:

你可以直接右键图片,在新窗口打开图片,如果是浏览器上URL地址栏是http://www.baidu.com/img/bd_logo1.png,说明不存在SSRF漏洞。

排除法二:

你可以使用burpsuite等抓包工具来判断是否不是SSRF,首先SSRF是由服务端发起的请求,因此在加载图片的时候,是由服务端发起的,所以在我们本地浏览器的请求中就不应该存在图片的请求,在此例子中,如果刷新当前页面,有如下请求,则可判断不是SSRF。(前提设置burpsuite截断图片的请求,默认是放行的)

此处说明下,为什么这边用排除法来判断是否存在SSRF,举个例子:

http://read.*******.com/image?imageUrl=http://www.baidu.com/img/bd_logo1.png

现在大多数修复SSRF的方法基本都是区分内外网来做限制(暂不考虑利用此问题来发起请求,攻击其他网站,从而隐藏攻击者IP,防止此问题就要做请求的地址的白名单了),如果我们请求

http://read.******.com/image?imageUrl=http://10.10.10.1/favicon.ico

而没有内容显示,我们是判断这个点不存在SSRF漏洞,还是http://10.10.10.1/favicon.ico这个地址被过滤了,还是http://10.10.10.1/favicon.ico这个地址的图片文件不存在,如果我们事先不知道http://10.10.10.1/favicon.ico这个地址的文件是否存在的时候是判断不出来是哪个原因的,所以我们采用排除法。

2)实例验证

经过简单的排除验证之后,我们就要验证看看此URL是否可以来请求对应的内网地址。在此例子中,首先我们要获取内网存在HTTP服务且存在favicon.ico文件的地址,才能验证是否是SSRF漏洞。

找存在HTTP服务的内网地址:
一、从漏洞平台中的历史漏洞寻找泄漏的存在web应用内网地址
二、通过二级域名暴力猜解工具模糊猜测内网地址

可以推测10.215.x.x此段就有很大的可能: http://10.215.x.x/favicon.ico 存在。

在举一个特殊的例子来说明:

http://fanyi.baidu.com/transpage?query=http://www.baidu.com/s?wd=ip&source=url&ie=utf8&from=auto&to=zh&render=1

此处得到的IP 不是我所在地址使用的IP,因此可以判断此处是由服务器发起的http://www.baidu.com/s?wd=ip请求得到的地址,自然是内部逻辑中发起请求的服务器的外网地址(为什么这么说呢,因为发起的请求的不一定是fanyi.baidu.com,而是内部其他服务器),那么此处是不是SSRF,能形成危害吗?  严格来说此处是SSRF,但是百度已经做过了过滤处理,因此形成不了探测内网的危害。

SSRF 漏洞中URL地址过滤的绕过

1http://www.baidu.com@10.10.10.10http://10.10.10.10 请求是相同的

此脚本访问请求得到的内容都是www.baidu.com的内容。 

2ip地址转换成进制来访问

115.239.210.26 = 16373751032

此脚本解析的地址都是 115.239.210.26,也可以使用ping 获取解析地址:

如果WEB服务简单的过滤参数中获取的URL地址,没有判断真正访问的地址,是有可能被此两种方法绕过的。

### 1. CSRF漏洞原理 CSRF(跨站请求伪造)是一种欺骗性的攻击方式,其核心在于让受害者在不知情的情况下执行某些操作。这种攻击通常发生在用户已经登录某个网站并保持会话状态时。攻击者通过诱导用户访问恶意页面,在该页面上嵌入指向目标网站的操作链接或表单提交脚本。由于浏览器会在发送请求时自动附带当前用户的认证信息(如Cookie),从而使得这些请求被当作合法请求处理。 例如,假设某银行网站允许用户转账的接口如下: ```http POST /transfer HTTP/1.1 Host: bank.example.com Content-Type: application/x-www-form-urlencoded to=attacker_account&amount=1000 ``` 如果用户已登录此银行网站且未退出,则攻击者可以通过构造类似的HTML代码诱使用户触发转账行为: ```html <img src="https://bank.example.com/transfer?to=attacker_account&amount=1000"> ``` 当受害者的浏览器加载上述`<img>`标签时,实际上向银行发起了一个GET请求,并携带了用户的Session Cookie[^1]。 --- ### 2. SSRF漏洞原理 SSRF(服务器端请求伪造)是指攻击者能够操控服务器去发起对外部或者内部网络资源的HTTP请求。这类漏洞通常是因程序设计缺陷引起——即开发者未能充分验证来自客户端输入的数据便将其用于构建远程调用逻辑。比如文件上传功能可能接受外部URL作为参数下载图片到本地存储;又或者是缓存预热机制定期抓取指定网页内容等等场景都可能存在风险点。 具体来说,假如存在这样一个API用来获取第三方数据: ```python @app.route('/fetch') def fetch(): url = request.args.get('url') # 用户可控制变量 response = requests.get(url) # 使用未经校验的 URL 发起 GET 请求 return response.content # 返回响应体给前端展示 ``` 此时,若无任何防护措施的话,那么攻击者就可以轻易地传入任意地址,包括但不限于私有子网范围内的IP地址或者其他敏感服务的位置,进而实现对内网资产扫描探测甚至进一步渗透的目的[^4]。 --- ### 3. 区别与联系 #### **主要区别** - **发起方不同**: - CSRF 是由 客户端 (User Agent, 如 Web 浏览器卡) 所发出的请求; - 而 SSRF 则完全是在 后台 Server 层面产生的动作。 - **影响对象差异**: - 对于前者而言主要是针对那些依赖 Cookies 或其他形式的身份标识来进行身份确认的服务造成威胁; - 至于后者更多时候涉及到的是对企业内部架构安全性的挑战,因为它可以让黑客突破防火墙限制接触到原本隔离起来的重要设施和服务实例[^3]. - **技术层面特点对比**: - 在 CSRF 中,整个过程都需要借助真实用户的交互才能顺利完成(点击链接、浏览特定网页等),而且最终所形成的危害程度取决于目标站点赋予该名下的实际权限大小; - 反观 SSRF ,一旦成功利用之后即可直接绕过常规意义上的边界保护策略,无论是否有正常用户的参与均能达成预期效果. #### **共同之处** 尽管两者之间存在着诸多显著的不同特征,但也共享了一些相似属性: - 都属于典型的Web应用层面上存在的安全隐患类别之一; - 成功实施的前提条件都是要找到合适的入口点以及具备一定的可控因素可供操纵调整 ; - 解决方案方面也都强调采用多层次综合手段相结合的方式来提升整体系统的安全性水平 , 比如说引入验证码机制对抗自动化工具生成虚假流量现象; 加强输入过滤规则防止非法字符混入业务流程当中等等举措都可以有效降低遭受此类攻击的概率 。 --- ### 示例代码片段 以下是两种常见防御方法的一个简单例子: 对于CSRF,可以在每次表单提交前加入动态Token验证: ```javascript // 前端部分 function csrfSafeMethod(method) { var token = $("meta[name='_csrf']").attr("content"); return /^(GET|HEAD|OPTIONS|TRACE)$/.test(method) || !!token && arguments.length === 2 ? { _csrf_token : token } : {}; } $.ajax({ type: 'POST', data: $.extend(csrfSafeMethod(), { key: value }), ... }); ``` 而后端需同步检查这个额外传递过来的信息是否匹配预先设定好的值[^2]: ```php <?php if ($_SERVER['REQUEST_METHOD'] === 'POST') { $expectedToken = $_SESSION['_csrf_token']; if (!hash_equals($expectedToken, $_POST['_csrf_token'])) { die('Invalid CSRF Token!'); } } ?> ``` 至于SSRF,最基础的做法就是限定允许访问的目标域名列表: ```python import urllib.parse ALLOWED_HOSTS = ['example.com', 'api.example.org'] @app.route('/proxy') def proxy(): target_url = request.args.get('url') parsed_url = urllib.parse.urlparse(target_url) if parsed_url.netloc not in ALLOWED_HOSTS: abort(403) # Forbidden access resp = requests.get(target_url) return Response(resp.content, content_type=resp.headers['content-type']) ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值