分享一些服务端请求伪造SSRF的笔记

# 这个页面不错

之前为了看懂什么是服务端请求伪造，都是根据大模型回复的内容；去搜索了一下Server-side Request Forgery，看到一个f5公司的页面，链接https://www.f5.com/glossary/ssrf，读一下，加深加深印象。页面这个样：

上图红框说，SSRF exploit flaws in web applications to access internal resources，利用web应用的漏洞来访问内部资源。

【省时预警】我这里为了好理解，就用“英式中文”来写了，页面上已经足够好了。

SSRF就是攻击者利用web应用或API来访问内网的资源，这会潜在得导致未授权的访问、数据泄露、系统瘫痪、远程代码执行。攻击者绕过输入检查、强制应用去访问可疑的web地址，就算这些地址在防火墙/VPN的保护下。

这里有个背景，就是web应用的有些功能，可能导致服务端发起http请求的行为，比如OAuth第三方登录、使用url图片作为自定义头像的功能。如果应用不过滤这些用户输入的url，攻击者就可以操纵服务端访问任意的url。

如果目标资源和其它系统有信任关系，比如目标资源是云环境元数据（云平台为其上的虚拟机or容器提供的内部配置信息查询接口）、或内部API，这实质上就是允许攻击者访问这些敏感信息或进行非授权的操作。

接下来的内容就是说现在SSRF攻击的形势很严峻，不光web应用，APP以及API服务也受影响；咱们重点看这一段：

1、应用有这样的功能：允许用户决定让服务端访问某个URL或网络资源，可以是url输入的参数，也可能是表单，或者其它的网络数据

2、攻击者提交一个自己编写的请求地址，让服务端去访问自己感兴趣的资源；这里感兴趣的资源可以是内部服务，或者后台服务，或者API，或者其它（有防火墙保护从而无法从外网访问的）内部系统

3、服务端真的去访问了攻击者编写的资源，所以这叫“服务端请求”伪造

4、如果服务端被诱使请求的地址是在内网，攻击者可能就尝试访问或拿走敏感信息；也可以用来扫描内网系统开放的端口，如此就有了SSRF可以用来“帮助攻击者发现内部服务漏洞”的说法

5、SSRF攻击特别集中在云环境，因为云环境上的实例有可能有权访问敏感的服务

6、SSRF攻击后果很严重，比如导致针对敏感数据和内部系统的未授权的访问，甚至让整个云系统陷入瘫痪

网页上还举了例子，真贴心：比如某web应用允许用户上传图片处理，还很贴心得支持使用url图片。然而，攻击者向web服务端口提交的是一个精心制作的URL，url指向了web服务端的内部资源或数据库；服务端程序没有针对恶意URL的检测，而是根据攻击者的输入向指定的内部服务发起了请求，从而给攻击者返回了敏感信息或数据库查询结果。一旦服务端被攻陷，攻击者还可以向系统以外的地方发请求，探测内网的漏洞，或者访问内网的服务。

如何应对呢？
1、输入检查。
2、维护一个服务端可以访问的白名单
3、限制对内部资源的访问
   使用内网分区限制对内部资源的访问，确保对外网服务的服务器开通了最小的访问权限        
   配置web应用防火墙和访问控制，限制服务端可以访问的外部地址
   在应用和外部资源之间部署一个反向代理，让代理控制应用可访问哪些外部地址

这里没再说其它的应对手段，大概因为其它的手段和该公司的产品不高度相干；这个页面就先看到这里了。

# 分享一下从大模型查出来的一些东西

在查询上述页面之前，我是先问了下大模型，就SSRF是什么这个问题来说，我觉得看上述网页比看大模型更有快。可能是因为大模型说了更多更详细的内容，所以我读起来就陷入了一些细节。读了上文后，再看笔记，觉得有些就很好理解了，这里分享一下在我看起来是说得通的。

Server-Side Request Forgery，攻击者诱使服务器向指定的内部或外部系统发起非预期的请求，常用于：
- 通过服务器探测内网服务
- 访问云服务的元数据接口，窃取数据
- 利用file协议读取服务器文件- 攻击内网服务，比如redis

PS: 不看上文的话直接看这一段，，，指定不好懂。。

如何应对SSRF？

（1）输入验证
严格验证用户提供的url/主机名
使用白名单限制服务器允许访问的域名和端口
禁用危险协议：file://，ftp://等
启用对请求的签名验证

（2）从网络层隔离
从网络限制服务器出站流量，禁止其访问非必要的内网服务
云服务器要禁止公网访问元数据接口

（3）从应用层入手
关闭非必要的本地监听接口；必要的本地监听接口要实施身份验证/签名验证
使用白名单机制，只允许访问预定义的合法域名
禁用URL跟随，就是不直接访问url返回的重定向链接

（4）云环境
限制元数据服务访问。
云环境元数据是云平台为其上的虚拟机or容器提供的内部配置信息查询接口，
通常通过固定的ip来访问，用于动态获取实例自身的属性、网络配置、安全凭证等，
主要用来管理云平台的实例（虚拟机or容器）

如何测试是否有SSRF漏洞？

可以手动测试
有自动化工具可以扫描
时间延时测试
DNS回显测试

什么是时间延时测试？

假设应用可以提交一个url图片，那么测试一下，记录一下响应时间
尝试输入一个内网的，不可达的url，比如http://192.168.1.1:8080这种内网地址，正常的话，这个应用不因该有权限访问这个地址，只要应用尝试连接这个地址，就是存在SSRF漏洞
如果服务器花费了明显更长的时间才返回错误的响应，比如超时，就表明服务器可能真的尝试了去连接这个地址；
可以设置一个自己能控制的内网服务，该服务接收到请求后延时几秒才返回，然后把这个服务给目标应用，如果目标应用的响应时间包含了设置的延时，就基本可以确定存在SSRF漏洞

什么是DNS回显测试？

首先要知道一个DNS协议外带数据的概念，即利用DNS协议来传输原本不属于DNS查询和响应中的数据，这在网络安全领域中，特别是渗透测试与攻击中较为知名。
由于DNS是一个相对宽松且很少被过滤的协议，它有时会被恶意利用，作为一种隐蔽通道来绕过网络安全检测机制。例如，攻击者可能会使用DNS隧道技术将其他协议的数据封装在DNS查询和响应中，从而实现在看似正常的DNS流量掩盖下的数据窃取。

DNS回显测试利用了DNS协议的上述特性，核心原理是通过构造特殊的请求，使目标系统向攻击者控制的DNS服务器发起查询，从而通过DNS日志外带敏感信息。
让目标系统向可以控制的DNS平台发起解析请求，DNS平台会记录查询的子域名，其中可能包含外带的数据，如数据库名、命令执行结果；
既然攻击者可以这么干，那么我们就可以先这么测试一下看能否发现漏洞。

好了，先到这里了。