使用 WebClient 时如何解决服务器端请求伪造 (SSRF)答案

【问题标题】：How to resolve Server side request forgery (SSRF) while using WebClient使用 WebClient 时如何解决服务器端请求伪造 (SSRF)
【发布时间】：2022-07-08 16:23:47
【问题描述】：

我有以下代码。名称是从 application.yaml 文件中注入的。我在运行静态代码分析时遇到了 SSRF 问题。如何解决这个问题？还是误报？

@Value
private String name;

Integer id = webClient.get()
             .uri("api/v1/student/"+name)
             .retrieve()
             .bodyToMono(Integer.class).block();

Integer marks= webClient.get()
             .uri("api/v1/marks/"+id)
             .retrieve()
             .bodyToMono(Integer.class).block();

【问题讨论】：

SSRF 意味着有人可以更改您的 application.yml 以向不想要的东西发出请求。您应该通过限制可以写入“名称”的值和其他从外部读取的参数来保护这一点。例如通过添加白名单

标签： spring spring-boot spring-webflux ssrf

【解决方案1】：

对于 SSRF，静态代码分析通常是错误的，这就是其中一种情况。该工具认为以下请求可以被攻击者控制：

.uri("api/v1/student/"+name)

如果攻击者可以控制它，那么请求可能会到达任意内部路径。但是，正如您所提到的，名称变量来自您的 application.yaml，它不受攻击者控制。因此这是误报。

如果这是一个真正的问题，那么解决方案将是 @Toerktumlare 在评论中提到的：限制到可能端点的允许列表。但是，当您提供正确的解决方案时，并非所有 SAST 工具都能理解。

备注：SAST 工具经常将配置文件视为攻击者控制的问题。一个著名的 SAST 供应商甚至为 log4j vuln (CVE-2021-44832) 申请了 CVE，因为当攻击者可以控制配置文件时可能会出现 RCE，并因此受到公众的批评。许多 SAST 工具的目标是结果的数量而不是质量，这在历史上对他们的销售有利，但现在客户对这样的结果越来越不满意，并要求更好的质量。手指交叉，SAST 的未来会改变其报告结果的策略。

【讨论】：