How to resolve Server side request forgery (SSRF) while using WebClient

Question

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();

Answer 1

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:

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

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.