如何在使用WebClient时解决服务器端请求伪造（SSRF）
我有以下代码。名称是从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();
I have the following code. name is injected from application.yaml file.
I am getting the SSRF issue while running the static code analysis. How to resolve this? Or is it a false positive?
@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();
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
静态代码分析对于SSRF通常是错误的，这就是其中一种情况。该工具认为可以由攻击者控制以下请求：
如果攻击者可以控制它，则该请求可能会碰到任意的内部路径。但是，正如您提到的，名称变量来自您的应用程序。yaml，这不是受到攻击者的控制。因此，这是一个假阳性。
如果这是一个真正的问题，那么解决方案将如评论中提到的@toerktumlare：仅限于可能的终点列表。但是，并非所有的SAST工具都可以理解正确的解决方案。
注释：Sast工具将配置文件像受到攻击者的控制一样，通常是一个问题。一位知名的SAST供应商甚至为log4j vuln（CVE-2021-44832）申请了CVE，因为当攻击者可以控制配置文件并因此而受到公众批评时，可能会有RCE。许多SAST工具旨在进行数量的结果，而不是质量，从历史上看，这使他们的销售受益，但现在客户对这种结果感到不满，并要求提高质量。手指交叉说，萨斯特的未来改变了报告结果的策略。
Static code analysis is often wrong about SSRF, and this is one of those cases. The tool thinks that the following request can be controlled by the attacker:
If an attacker could control it, then the request could hit an arbitrary internal path. However, as you mentioned, name variable is coming from your application.yaml, which is not attacker controlled. Therefore this is a false positive.
If this was a real problem, then the solution would be as @Toerktumlare mentioned in the comment: restrict to an allow list of possible endpoints. However not all SAST tools understand when you provide a correct solution.
Remark: it is frequently a problem that SAST tools are treating configuration files as if they are attacker controlled. One well known SAST vendor even filed for a CVE for a log4j vuln(CVE-2021-44832) due to the possibility of an RCE when an attacker can control a configuration file, and got criticised by the public for doing so. Many SAST tools aim for quantity of results rather than quality, which historically has benefited their sales, but now customers are becoming unhappy with such results and are asking for better quality. Fingers crossed that the future of SAST changes it’s strategy for reporting results.