ESoby214016 (Community Member) asked a question.

False positive CWE-918: Server-Side Request Forgery?

False positive CWE-918: Server-Side Request Forgery?

I'm working on an ASP.NET Core MVC application, and our static security scan flagged a CWE-918: Server-Side Request Forgery (SSRF) vulnerability. However, based on the implementation, this appears to be a false positive.

 

 

 

1. Input validation:

 

The query parameter is strictly validated to match a prefix and digit format:

 

private bool IsValidLoanNumber(string loanNumber)

 

{

 

 return !string.IsNullOrWhiteSpace(loanNumber) &&

 

   Regex.IsMatch(loanNumber, "^ABCDE\\d+$", RegexOptions.IgnoreCase);

 

}

 

 

 

 

 

2. URL validation:

 

In our case, the base url is also stored in a config file within the application

 

The constructed endpoint (from a config template like

 

APISettings:UnityDeal

 

) is checked against an explicit allow-list of hostnames:

 

 

 

private bool IsValidUrl(string url)

 

{

 

 if (string.IsNullOrWhiteSpace(url)) return false;

 

 

 

 var uri = new Uri(url);

 

 var allowedHosts = new List<string> { "api.dev.example.com", "api.qa.example.com", "api.example.com" };

 

 return !string.IsNullOrEmpty(uri.Host) && allowedHosts.Contains(uri.Host);

 

}

 

 

 

 

 

3. Fail-fast checks:

 

If either validation fails, the request short-circuits and returns a

 

400 Bad Request.

 

 

 

The scan still reports:

 

"Untrusted input is used in

 

HttpClient.GetAsync(), which may allow SSRF."

 

 

 

 

 

 

 

Is this a typical false positive due to static analysis not evaluating conditional logic?

 

 

 

Are there any industry-standard patterns to prove that a URL is trusted?


  • SamHouston (Veracode)

    Hi @ESoby214016 (Community Member)​ - We have an answer to a similar question in this post, which could be helpful: https://community.veracode.com/s/question/0D52T00004s161DSAQ/how-to-fix-cwe918-serverside-request-forgery-ssrf-

     

    The approach and design you've outlined would require a mitigation proposal to resolve the finding.

     

    It is not so much to do with not being able to evaluate conditional logic, but rather it has to do with Veracode static not having the capability to recognize your config file as a trusted, reliable source for retrieving the base URL from at runtime. Also, Veracode static cannot evaluate the allow-list and regex validation strategies that the customer has shared here.

     

    If Veracode still sees that the request/URL string set in the GetAsync call has external taint, even after this input passes through the helper validation methods described, it shall continue to report a flaw.

     

    For Veracode to no longer report a flaw, the input needs to not have any external taint identified and so must be fully hardcoded in the scanned submission.

    Expand Post

Topics (6)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.