Question

The best way to discover SSRF vulnerabilities is through a review of the application’s source code, in which you check if the application validates all user-provided URLs. But when you can’t obtain the source code, you should focus your efforts on testing the features most prone to SSRF.

发现 SSRF 漏洞的最佳方法是通过审查应用程序的源代码，您可以检查应用程序是否验证了所有用户提供的 URL。但如果您无法获取源代码，则应将重点放在最容易受到 SSRF 攻击的功能测试上。

Step 1: Spot Features Prone to SSRFs

SSRFs occur in features that require visiting and fetching external resources. These include webhooks, file uploads, document and image processors, link expansions or thumbnails, and proxy services. It’s also worth testing any endpoint that processes a user-provided URL. And pay attention to potential SSRF entry points that are less obvious, like URLs embedded in files that are processed by the application (XML files and PDF files can often be used to trigger SSRFs), hidden API endpoints that accept URLs as input, and input that gets inserted into HTML tags.

SSRF 通常发生在需要访问和获取外部资源的功能中，包括网络挂接、文件上传、文档和图片处理器、链接扩展或缩略图以及代理服务。还应该测试任何处理用户提供的 URL 的端点。并且要注意潜在的 SSRF 入口点，如嵌入在应用程序中处理的文件中的 URL（XML 文件和 PDF 文件通常可用于触发 SSRF），接受 URL 作为输入的隐藏 API 端点以及插入到 HTML 标记中的输入。

Webhooks are custom HTTP callback endpoints used as a notification system for certain application events. When an event such as new user sign-up or application error occurs, the originating site will make an HTTP request to the webhook URL. These HTTP requests help the company collect information about the website’s performance and visitors. It also helps organizations keep data in sync across multiple web applications.

Webhooks 是自定义的 HTTP 回调端点，用作特定应用程序事件的通知系统。当发生诸如新用户注册或应用错误之类的事件时，来源网站将向 Webhook URL 发出 HTTP 请求。这些 HTTP 请求有助于公司收集有关网站性能和访问者的信息。它还帮助组织在多个 Web 应用程序之间保持数据同步。

And in the event that one action from an application needs to trigger an action on another application, webhooks are a way of notifying the system to kick-start another process. For example, if a company wants to send a welcome email to every user who follows its social media account, it can use a webhook to connect the two applications.

当一个应用程序的某个操作需要触发另一个应用程序的操作时，Webhooks 可以通知系统启动另一个进程。例如，如果一个公司想要向每个关注其社交媒体账户的用户发送欢迎邮件，它可以使用 Webhook 来连接这两个应用程序。

Many websites allow users to set up their webhook URLs, and these settings pages are often vulnerable to SSRF. Most of the time, an application’s webhook service is in its developers’ portal. For example, Slack allows application owners to set up a webhook via its app configuration page ( https://api.slack.com/apps/ ). Under the Event Subscriptions heading, you can specify a URL at which Slack will notify you when special events happen ( Figure 13-1 ). The Request URL field of these webhook services is often vulnerable to SSRF.

许多网站允许用户设置其 Webhook URL，并且这些设置页面经常容易受到 SSRF 的攻击。大多数情况下，应用程序的 Webhook 服务在其开发者门户中。例如，Slack 允许应用程序所有者通过其应用配置页面设置 Webhook（https://api.slack.com/apps/）。在事件订阅标题下，您可以指定一个 URL，Slack 将在特殊事件发生时通知您（图 13-1）。这些 Webhook 服务的请求 URL 字段经常容易受到 SSRF 的攻击。

On the other hand, proxy services refer to services that act as an intermediary between two machines. They sit between the client and the server of a request to facilitate or control their communication. Common use cases of proxy services are to bypass organization firewalls that block certain websites, browse the internet anonymously, or encrypt internet messages.

另一方面，代理服务指的是充当两台机器之间中介的服务。他们坐在请求的客户端和服务器之间，以促进或控制它们的通信。代理服务的常见用例是绕过组织防火墙，阻止特定网站的访问，匿名浏览互联网或加密互联网消息。

Figure 13-1 : Adding a webhook to Slack

图 13-1：将 Webhook 添加到 Slack。

Notice these potentially vulnerable features on the target site and record them for future reference in a list like this:

请注意目标站点上可能存在的易受攻击的特点，并将它们记录在类似于此的列表中，以备将来参考：

Potential SSRF Endpoints

潜在的 SSRF 终端点

1. Add a new webhook:

POST /webhook
Host: public.example.com

(POST request body)
url=https://www.attacker.com

1. File upload via URL:

POST /upload_profile_from_url
Host: public.example.com

(POST request body)
user_id=1234&url=https://www.attacker.com/profile.jpeg

1. Proxy service:

https://public.example.com/proxy?url=https://google.com

Step 2: Provide Potentially Vulnerable Endpoints with Internal URLs

Once you’ve identified the potentially vulnerable endpoints, provide internal addresses as the URL inputs to these endpoints. Depending on the network configuration, you might need to try several addresses before you find the ones in use by the network. Here are some common ones reserved for the private network: localhost , 127.0.0.1, 0.0.0.0, 192.168.0.1, and 10.0.0.1.

一旦您确定可能存在漏洞的终端点，将内部地址作为 URL 输入提供给这些终端点。根据网络配置，您可能需要尝试多个地址，才能找到网络正在使用的地址。以下是一些为私有网络保留的常见地址：localhost, 127.0.0.1, 0.0.0.0, 192.168.0.1 和 10.0.0.1。

You can find more reserved IP addresses used to identify machines on the private network at https://en.wikipedia.org/wiki/Reserved_IP_addresses .

您可以在 https://zh.wikipedia.org/wiki/保留 IP 地址找到更多用于识别私有网络上的机器的保留 IP 地址。

To illustrate, this request tests the webhook functionality:

例如，此请求测试 Webhook 功能：

POST /webhook
Host: public.example.com

(POST request body)
url=https://192.168.0.1

This request tests the file upload functionality:

这个请求测试文件上传功能。

POST /upload_profile_from_url
Host: public.example.com

(POST request body)
user_id=1234&url=https://192.168.0.1

And this request tests the proxy service:

这个请求测试代理服务：

https://public.example.com/proxy?url=https://192.168.0.1

Step 3: Check the Results

In the case of regular SSRF, see if the server returns a response that reveals any information about the internal service. For example, does the response contain service banners or the content of internal pages? A service banner is the name and version of the software running on the machine. Check for this by sending a request like this:

在正常 SSRF 的情况下，请查看服务器是否返回了显示内部服务信息的响应。例如，响应是否包含服务横幅或内部页面的内容？服务横幅是运行在计算机上的软件名称和版本。通过发送像这样的请求检查它：

POST /upload_profile_from_url
Host: public.example.com

(POST request body)
user_id=1234&url=127.0.0.1:22

Port 22 is the default port for the Secure Shell Protocol (SSH). This request tells the application that the URL of our profile picture is located at 127.0.0.1:22, or port 22 of the current machine. This way, we can trick the server into visiting its own port 22 and returning information about itself.

22 端口是安全外壳协议（SSH）的默认端口。该请求告诉应用程序，我们的个人资料图片的 URL 位于 127.0.0.1:22 或当前机器的 22 端口。这样，我们就可以欺骗服务器访问其自己的 22 端口，并返回有关自己的信息。

Then look for text like this in the response:

然后在响应中寻找类似这样的文本：

Error: cannot upload image: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4

If you find a message like this, you can be sure that an SSRF vulnerability exists on this endpoint, since you were able to gather information about the localhost.

如果您发现类似此消息，那么可以肯定该终端存在 SSRF 漏洞，因为您已能够收集有关本地主机的信息。

The easiest way of detecting blind SSRFs is through out-of-band techniques: you make the target send requests to an external server that you control, and then monitor your server logs for requests from the target. One way to do this is to use an online hosting service, such as GoDaddy or Hostinger, that provides server access logs. You can link your hosted site to a custom domain and submit that domain in the SSRF testing payload.

检测盲 SSRF 的最简单方法是使用带外技术：您让目标发送请求到您控制的外部服务器，然后监视您服务器日志中的目标请求。一种方法是使用在线托管服务，如 GoDaddy 或 Hostinger，提供服务器访问日志。您可以将托管网站链接到自定义域，并将该域提交给 SSRF 测试有效载荷。

You can also turn your own machine into a listener by using Netcat, a utility installed by default on most Linux machines. If you don’t already have Netcat, you can install it by using the command apt-get install netcat . Then use nc -lp 8080 to start a listener on port 8080. After this, you can point your SSRF payloads to your IP address on port 8080 and monitor for any incoming traffic. Another easier way of doing this is to use the Collaborator feature in Burp Suite Pro, which automatically generates unique domain names, sends them as payloads to the target, and monitors for any interaction associated with the target.

您也可以使用默认安装在大多数 Linux 机器上的实用程序 Netcat 将自己的机器变成侦听器。如果您尚未安装 Netcat，则可以使用命令 apt-get install netcat 进行安装。然后使用 nc -lp 8080 在端口 8080 上启动侦听器。之后，您可以将 SSRF 有效负载指向您的 IP 地址在端口 8080，并监视任何传入的流量。另一种更简单的方法是使用 Burp Suite Pro 中的 Collaborator 功能，它会自动生成唯一的域名，将它们作为有效负载发送到目标，并监视与目标相关的任何交互。

However, being able to generate an outbound request from the target server alone is not an exploitable issue. Since you cannot use blind SSRFs to read internal files or access internal services, you need to confirm their exploitability by trying to explore the internal network with the SSRF. Make requests to various target ports and see if server behavior differs between commonly open and closed ports. For example, ports 22, 80, and 443 are commonly open ports, while port 11 is not. This will help you determine if an attacker can use the SSRF to access the internal network. You can look especially for differences in response time and HTTP response codes.

然而，仅从目标服务器生成一个出站请求并不是一个可利用的问题。由于您无法使用盲目的 SSRF 读取内部文件或访问内部服务，您需要通过尝试使用 SSRF 来探索内部网络来确认其可利用性。向各种目标端口发出请求，看看服务器行为在通常开放和关闭的端口之间是否有所不同。例如，端口 22、80 和 443 是常见的开放端口，而端口 11 则不是。这将帮助确定攻击者是否可以使用 SSRF 访问内部网络。您可以特别寻找响应时间和 HTTP 响应代码的差异。

For example, servers use the HTTP status code 200 to indicate that a request has succeeded. Often, if a server is able to connect to the specified port, it will return a 200 status code. Say the following request results in an HTTP status code of 200:

例如，服务器使用 HTTP 状态码 200 来表示请求已成功。通常情况下，如果服务器能够连接到指定的端口，它将返回 200 状态码。假设以下请求的 HTTP 状态代码为 200：

POST /webhook
Host: public.example.com

(POST request body)
url=https://127.0.0.1:80

The following request instead results in an HTTP status code of 500, the status code for Internal Server Error. Servers return 500 status codes when they run into an error while processing the request, so a 500 status code often indicates a closed or protected port:

以下请求导致 HTTP 状态代码为 500，这是“内部服务器错误”的状态代码。当服务器在处理请求时遇到错误时，会返回 500 状态代码，因此 500 状态代码通常表示端口关闭或受保护。

POST /webhook
Host: public.example.com

(POST request body)
url=https://127.0.0.1:11

You can confirm that the server is indeed making requests to these ports and responding differently based on port status.

你可以确认服务器确实在这些端口上进行请求，并根据端口状态有不同的响应。

Also look for the time difference between responses. You can see in Figure 13-2 that the Burp repeater shows how long it took for the server to respond in the bottom right corner. Here, it took 181 milliseconds for Google to return its home page. You can use tools like SSRFmap ( https://github.com/swisskyrepo/SSRFmap/ ) to automate this process.

还要查找响应之间的时间差异。如图 13-2 所示，Burp Repeater 在右下角显示服务器响应所需的时间。在这里，Google 返回首页需要 181 毫秒。您可以使用 SSRFmap（https://github.com/swisskyrepo/SSRFmap/）等工具来自动化此过程。

Figure 13-2 : Burp repeater shows you how long it took for the server to respond to a request.

图 13-2：Burp 重复器显示了服务器响应请求所需的时间。

If a port is closed, the server usually responds faster because it drops the forwarded traffic immediately, whereas internal firewalls often cause a delay in the response. Attackers can use time delays as a metric to figure out a target’s internal network structure. If you can identify a significant time difference between requests to different ports, you have found an exploitable SSRF.

如果一个端口关闭了，服务器通常会更快地响应，因为它会立即丢弃转发的流量，而内部防火墙经常会导致响应延迟。攻击者可以使用时间延迟作为计量标准来确定目标内部网络结构。如果您可以在对不同端口的请求之间识别出重要的时间差异，则已经找到了可利用的 SSRF。