当前位置：首页 > article >正文

SSRF漏洞学习总结

article 2025/1/31 1:22:50

一、SSRF漏洞

1.原理

SSRF（Server-Side Request Forgery，服务器端请求伪造）是一种安全漏洞，攻击者利用这个漏洞可以诱使服务器端发起由攻击者构造的请求。这种攻击通常发生在应用接受来自用户的输入，并且该输入用于构建请求的某个部分而未经充分验证或过滤时。通过这种方式，攻击者可以让受害服务器发送请求到一个原本不应该访问或者未被授权访问的内部系统、外部系统或者其他资源。

2.危害

内部网络扫描：攻击者可能利用存在SSRF漏洞的应用程序来探测或扫描内部网络，发现内网中的其他服务或主机。
端口扫描：确定特定主机上开放了哪些端口。
读取本地文件：在某些情况下，如果协议支持（如file://），攻击者可能能够使用SSRF漏洞来读取服务器上的本地文件。
攻击内部系统：因为服务器通常位于防火墙内部，它可能能够访问一些仅限内部访问的服务。攻击者可以利用SSRF攻击这些服务。
绕过IP白名单检查：如果应用程序基于请求来源进行访问控制，攻击者可能通过SSRF来绕过这些限制。

3.检测点

Webhook配置：
- 应用程序允许用户设置回调URL(webhook)，当特定事件发生时会向该URL发送通知。如果未对这些URL进行验证，则可能存在风险。
图片或文件加载功能：
- 当应用提供从用户提供的URL下载图片、文档或其他资源的功能时，如果没有适当的验证，攻击者可以利用这个功能来触发内部请求。
第三方服务集成：
- 与第三方API交互的应用程序，如果直接使用了用户输入的数据作为API请求的一部分（如查询参数、路径参数等），可能会遭受SSRF攻击。
远程文件包含(RFI)：
- 某些编程语言和框架支持通过URL加载远程文件（例如PHP中的include语句）。如果这种功能基于用户输入且没有适当限制，就可能被用来执行SSRF攻击。
OAuth回调处理：
- 在OAuth认证过程中，客户端应用需要重定向到授权服务器并接收一个回调。如果处理不当，攻击者可以通过构造恶意的OAuth授权请求来进行SSRF攻击。

4.绕过方法及防御

使用IP地址代替域名：
- 绕过：一些应用可能只检查了URL中的域名是否属于白名单，但没有考虑到直接使用IP地址的情况。例如，http://127.0.0.1/ 或 http://[::1]/。
- 防御：确保对所有输入的URL进行解析，并验证其主机部分，包括IP地址。
采用短网址，进制转换：
- 绕过：采用短网址绕过（免费短链接生成器 | 即时创建短网址）；采用进制转换；采用可以指向任意域名的xip.io，127.0.0.1.xip.io可以解析为127.0.0.1。
- 防御：展开短链接，限制短链接服务；解码所有输入，确保处理逻辑涵盖各种编码格式；禁用xip.io服务。
DNS Rebinding：
- 绕过：攻击者可以控制一个域名，并配置其DNS记录。初次解析时返回一个允许的外部IP地址，但在实际发起请求时改变DNS记录指向内部网络或本地主机地址。
- 防御：确保在每次请求前都重新解析DNS名称，而不是缓存DNS结果。同时，考虑使用DNS预取保护机制。
使用不常见的协议：
- 绕过：除了常见的http://和https://之外，还存在其他协议如dict://, gopher://, ftp://等，这些也可能被用来访问本地文件系统或其他敏感资源。
- 防御：严格限制允许使用的协议，通常仅限于HTTP和HTTPS。
编码技巧：
- 绕过：通过对URL的部分内容进行URL编码或使用不同的字符集来混淆过滤器。例如，将localhost写成%6c%6f%63%61%6c%68%6f%73%74。
- 防御：在验证之前对输入进行全面解码，并确保过滤逻辑能够处理各种编码形式。
IPv6与特殊域格式：
- 绕过：利用IPv6地址或特殊域格式（如0::1代替::1）以避开基于字符串匹配的过滤规则。
- 防御：实现全面的IP地址解析与验证机制，支持IPv6并正确处理所有合法表示形式。

二、实际攻击例子

一个典型的SSRF漏洞利用案例可以发生在当一个Web应用允许用户提交一个URL，然后服务器端会尝试获取该URL的内容（例如，为了生成网页预览或者从外部资源中提取数据）。如果这个功能没有对输入进行适当的验证或限制，攻击者就可以构造恶意的请求来利用这个漏洞。

实际例子

假设有一个在线图书管理系统，它提供了一个功能：允许管理员通过输入书籍封面的URL来自动下载并显示封面图片。这个功能的实现方式是，后台服务器接收管理员提供的URL，然后使用HTTP请求去访问那个URL以获取图像内容。

攻击步骤如下：

发现漏洞：攻击者注意到，在添加书籍封面时，系统接受一个完整的URL作为输入，并似乎直接请求该URL来获取图片。
构造恶意请求：攻击者决定测试是否可以通过提供一个指向内部网络地址比如http://127.0.0.1:8080/admin 或者 http://localhost/）的URL来访问内部服务。此外，攻击者可能还会尝试其他协议如`file://`来试图读取服务器上的文件。
执行攻击：
- 攻击者在添加书籍封面的地方输入类似http://127.0.0.1:8080/admin这样的URL。
- 后台服务器接收到这个请求后，尝试根据给定的URL获取数据。由于缺乏对外部请求的有效验证，服务器实际上向自身的管理接口发出了请求。
- 如果响应未被正确处理，攻击者可能无法直接看到结果，但如果服务器将响应中的任何信息泄露出来（例如错误信息），攻击者就可能收集到关于内部网络结构的信息。
进一步攻击：一旦确定存在SSRF漏洞，攻击者可能会进一步探索，比如尝试访问敏感的内部服务、执行端口扫描或是利用本地文件访问协议（如file:///etc/passwd）来读取服务器上的重要文件。

三、术语理解

1.Webhook

Webhook的工作原理：
- Webhook是一种让用户指定一个回调URL的方式，当某些预定义的事件在应用中发生时（例如，代码推送、问题创建等），该应用会向这个指定的回调URL发送HTTP请求作为通知。这种方式常用于实现不同服务之间的实时通信和自动化工作流。
漏洞示例
假设有一个在线商城平台，它允许商家注册并设置Webhook URL，以便在订单状态更新时接收通知。每当有新订单、订单取消或发货等事件发生时，系统会向商家预先设置的Webhook URL发送包含订单详情的HTTP POST请求。
商家后台界面：商家可以在后台管理页面输入任何URL作为Webhook回调地址。例如：https://myshop.com/webhook-endpoint
攻击者行为：假设攻击者发现这个功能，并且知道该商城平台没有对Webhook URL进行严格的验证和限制。攻击者决定利用这一点来进行攻击。

攻击者在自己的服务器上设置了一个监听端点（比如http://attacker-server.com/log），然后将Webhook URL设置为指向这个端点，如：http://attacker-server.com/log。此外，攻击者可能还会尝试一些内部网络地址，以探测内网服务的存在，例如：http://localhost:8080/admin 或使用非HTTP协议访问本地文件系统，如 file:///etc/passwd。
漏洞利用过程：
- 当商城平台上的某个订单状态发生变化时，平台会根据商家设置的Webhook URL发起HTTP请求。
- 如果商城平台未对这些URL进行校验，则会直接向攻击者指定的任意URL发送请求，包括那些可能指向内部网络或使用了不安全协议的URL。
- 攻击者的服务器记录到来自商城平台的请求，可以从中获取敏感信息，或者进一步利用此通道执行更复杂的攻击（如扫描内部网络）。
潜在后果：
- 数据泄露：如果商城平台在Webhook请求中包含了敏感信息（如订单详情、客户个人信息等），这些信息可能会被发送到攻击者的服务器。
- 内部网络暴露：攻击者可以通过构造特定的Webhook URL来探测或访问内部网络资源，这可能导致更多的安全隐患。
- 文件读取：如果支持其他协议（如file://），攻击者甚至可以从服务器上读取文件内容。

2.OAuth

在OAuth认证过程中，如果客户端应用对回调URL的处理不当，确实可能存在SSRF（服务器端请求伪造）的风险。下面结合一个具体的例子来解释这种潜在的安全威胁。

场景描述

假设有一个在线服务A，它允许用户使用第三方平台B（如社交媒体平台）进行登录。为了实现这一点，服务A需要与平台B进行OAuth认证流程交互。在这个过程中，服务A会重定向用户到平台B的授权页面，并指定一个回调URL，用户同意授权后，平台B会将用户重定向回这个回调URL，并附带授权码或访问令牌。

漏洞示例

OAuth授权流程：
- 用户点击“使用平台B登录”按钮。
- 服务A生成一个包含回调URL（例如https://servicea.com/callback）的OAuth授权请求，并重定向用户到平台B的授权页面。
- 用户在平台B上登录并授权服务A访问其数据。
- 平台B将用户重定向回到服务A指定的回调URL，并附加授权码或访问令牌。
攻击者行为：假设服务A在OAuth授权请求中允许用户直接输入或控制回调URL，并且没有对该URL进行严格的验证或限制。攻击者可以构造恶意的OAuth授权请求，其中包含一个由攻击者控制的回调URL（例如http://attacker-server.com/fake-callback）。
漏洞利用过程：
- 攻击者创建一个指向服务A的链接，该链接包含了恶意的回调URL参数。
- 当受害者点击此链接时，他们会被重定向到平台B的授权页面，但使用的回调URL是攻击者指定的。
- 如果用户同意授权，平台B将会尝试向攻击者指定的回调URL发送响应（包括授权码或访问令牌）。
- 攻击者的服务器接收到这些信息后，就可以使用授权码或访问令牌代表用户与服务A进行交互，可能窃取用户的敏感信息或执行其他未经授权的操作。
潜在后果：
- 信息泄露：攻击者可以获得用户的授权码或访问令牌，从而能够访问用户的个人资料、联系人列表等敏感信息。
- 权限滥用：通过获取的访问令牌，攻击者可能以用户的身份执行各种操作，比如发布状态更新、发送消息等。

如何防止这种漏洞？

固定回调URL：最简单的方法是在OAuth配置中固定回调URL，不允许动态更改。这样可以确保只有预定义的、受信任的地址能接收授权响应。
严格的URL验证：如果必须支持动态回调URL，则应对其进行严格验证，包括但不限于检查域名是否属于已知可信域、确保只接受HTTPS协议等。
使用OAuth 2.0的最佳实践：遵循OAuth 2.0标准中的最佳安全实践，例如使用state参数来防御CSRF攻击，以及正确处理redirect_uri参数。

查看全文

http://www.kler.cn/a/523799.html