问题标签 [ssrf]

我API Gateway Pattern在一个Micro services架构中Front End Angular app使用HTTP request我的API Gateway项目，这只是一个ASP.net Core 3.1 Web API项目。目前我只有 2micro services和一个API Gateway，它们都是ASP.net Core 3.1 Web API项目类型。该API Gateway项目具有我的所有控制器micro services。的目的API Gateway只是接收来自适当的请求Front end并发出请求。HTTP RequestMicro service

现在在AccountController.cs我的API Gateway项目中，我有以下代码

在 stackoverflow 上搜索问题后，我在Veracode 社区SSRF找到了以下建议。

Veracode Static Analysis 将报告 CWE 918 的缺陷，如果它可以检测到来自应用程序外部的数据（例如来自用户的 HTTP 请求，也可能是用户上传的文件、数据库数据、Web 服务数据等） ) 能够改变网络请求的性质。

在Stackoverflow我发现了以下修复

对于 CWE ID 918，除非您有静态 URL，否则很难让 Veracode 识别您的修复程序。您需要验证成为请求 URL 一部分的所有输入。

这意味着我必须清理我的输入参数OrganizationId，AccountId然后再将它们附加到请求 URL。

还建议了有关veracode 社区的另一个问题

Veracode 静态分析会自动检测到作为此缺陷类别的补救措施的唯一一件事是将输入更改为硬编码

他们提出了查询字符串的解决方案

给定的示例似乎采用模型标识符并将其放在内部请求中使用的 URL 中。我们建议根据您对此数据类型的规则验证 ID（通常应该是字母数字且少于 255 个字符）并在将其附加到 URL 之前对其进行 URL 编码。

在所有这些东西之后，我对我的代码进行了以下更改

1. 确保 OrganizationId 和 AccountId Guid 不为空
2. URL 编码字符串

这是更改后的代码

这就是我可以做的所有事情来清理我的输入参数OrganizationId，AccountId但是在所有这些更改之后veracode仍然可以在线识别SSRF缺陷

使用 var result = await _client.GetAsync(url);

问题：如果我有一个不受信任的、用户提供的文件 URL，当我下载该文件时如何保护自己免受服务器端请求伪造？.NET Framework (4.8) 基类库中是否有工具可以帮助我，或者是否有一些针对此用例的规范参考实现？

详细信息：我们的网络应用程序（在线产品数据库）允许用户上传产品图片。我们要求应允许用户提供（自托管）图像的 URL，而不是上传图像。

到目前为止，一切都很好。但是，有时我们的 Web 应用程序必须从（外部、用户提供的）URL 中获取图像才能对其进行处理（例如，将图像包含在 PDF 产品数据表中）。

这使我的 Web 应用程序面临Server-Side Request Forgery的风险。OWASP 备忘单将此用例记录为“案例 2”，并提出了一些缓解措施，例如验证 URL 和将已知的内部 IP 地址列入备份列表。

这意味着我不能使用内置方法来下载文件，例如WebClientor HttpWebRequest，因为这些类负责 DNS 解析，并且我需要在 DNS 解析之后但在执行 HTTP 请求之前验证 IP 地址。我可以自己执行 DNS 解析，然后使用（经过验证的）IP 地址和自定义 Host 标头创建一个 Web 请求，但这可能会弄乱 TLS 证书检查。

长话短说，我觉得我在这里重新发明了轮子，因为这听起来像是一个足够常见的用例。（我肯定不是第一个必须从用户提供的 URL 获取文件的 Web 开发人员。） .NET Framework 具有防止内置 CSRF 的工具，所以我想知道我是否有类似的工具可用于 SSRF只是还没找到。

注意：在ssrf标签中有类似的问题（例如这个），但是，与它们相反，我的目标不是“摆脱警告”，而是真正保护我的系统免受 SSRF。

我正在使用restTemplate微服务架构中的同步服务间通信。

当我们完成Veracode扫描时，我们正在进入Server-Side Request Forgery (SSRF) (CWE ID 918)方法getForEntity。

不知道为什么我会遇到这个SSRF问题？
对此有什么可能的解决方法？

一个 Django 应用程序使用名为 ALLOWED_HOSTS 的内置设置，将请求主机标头列入白名单。这是必需的，因为 Django 在某些情况下使用客户端提供的 Host 标头来构造 URL。

fakehost.com我向 Django 端点发出了十个带有假主机头（我们称之为）的请求： /example.

在应用程序日志中，我看到django.security.DisallowedHost错误出现了十次。但是，根据 的日志fakehost.com，它确实收到了/example.

据我了解，这是一个服务器端请求伪造 (SSRF) 漏洞，因为可以使 Django 服务器向任意 URL 发出请求。

它使调试变得困难，并且奇怪的是问题不会始终如一地发生。同样奇怪的是，假主机似乎被 Django 识别，但仍然以某种方式达到了一个请求fakehost.com。

有没有人知道我可以进一步调查什么来修复这个 Django 应用程序中的明显漏洞？问题可能在服务器级别而不是应用程序级别？

我的应用程序中有一个要求，其中 API 接受一些外部网站 URL 作为输入正文参数。然后，服务器调用 URL 并读取响应标头。

由于我们不能对作为输入传递的 URL 进行任何域限制，因此 API 容易受到安全攻击（通常是 SSRF 攻击）。

有没有办法可以识别在 body 参数中传递的 URL 是否来自安全网站？注意 - 我只从 URL 响应中读取标题数据。

如何维护外部请求服务和主机的白名单并阻止任何未出现在白名单上的交互？

我正在寻找一些代码片段来实现这一点。

在我的应用程序中，实际上可以诱导应用程序执行任意域名的服务器端 DNS 查找，因为 X-Forwarded-For 请求标头值被服务器盲目信任。

当有人将带有 X-Forwarded-For 请求标头的请求作为“易受攻击的服务器”（例如：X-Forwarded-For:evilsrver.net）截获时，如何在此处防止 DNS 查找。

我发现这张有趣的票https://github.com/akka/akka/issues/19388 建议进行主机过滤。

有没有其他方法可以解决这个问题？