Hi @Sohlae (Community Member)​ ,

Veracode Static Analysis reports flaws of CWE-918: Server-Side Request Forgery (SSRF) when it can see that dynamic data is going into the URL being used to perform an HTTP Request by the application.

This is regardless of whether the dynamic data is going into the BaseAddress or the URI for a method such as `GetStringAsync`.

With regards to the reported CWE-918, they are identical as they both end up influencing the URL to be called.

Veracode Static Analysis will only automatically close this flaw when there is no dynamic data (as strings, integers are fine) going into this URL.

You may need to have dynamic components to the URL in which case we recommend:

1. Being very careful with the hostname, if you have dynamic data there you must ensure it is validated against an allow list (such as allowing only "db1", "db2" or "db3").
2. Being very careful with the path, using allow lists and URL encoding the dynamic data.
3. Ensuring you URL encode the dynamic data placed in the query string.

Afterwards, this must be manually reviewed and as such must document this in a mitigation proposal ( https://docs.veracode.com/r/improve_mitigation ) and have it reviewed by someone in your organization with the 'Mitigation Approver' role.

Thank you,

Boy Baukema

PS: From a best practices standpoint I would not recommend updating the "BaseAddress", it is meant for unchanging parts of the URL such as a hostname, so you could do something like:

var veracodeHttpClient = httpClientFactory.CreateClient();  

veracodeHttpClient.BaseAddress = "https://api.veracode.com/appsec/v1";

    var response = await veracodeHttpClient.GetAsync("/applications/?name=verademo").Result.Content.ReadAsStringAsync();  

    Console.WriteLine(response);

    Console.WriteLine(Environment.NewLine);  

Hi @Sohlae (Community Member)​ 

Untrusted input is used in the creation of a web-request which possibly allows an attacker to perform unauthorized requests to internal or external systems. An attacker can use this to interact with internal services or disclose information or even local server files

-Many app will take URL from user and do processing with it (for e.g. imagine a reporting dashboard, with ability to take URI and pull CSV data, it makes web request and updates your dashboard.)

-it can go wrong many for e.g. if entered URI is "file:///etc/passwd" , you may be able to directly read files from the server,if it is not handled properly.

-this may also lead to requesting some internal services that the attacker would never be able to ordinarily access due to firewall rules

-attacker can also port scan the entire network. (if the req is returned immediately, it means port is closed, if it hangs for few seconds it means port is open but cannot handle http requests.) -->> this can leads to extensive map of the network infrastructure and provide attackers with the information required to jump to other hosts.

-They are pretty common but difficult to find them.

Well the issue is that the request's URL is provided by a configuration setting which is considered untrusted since the file would need to have appropriate access controls and follow a principle of least privilege. On top of that, since this is a configurable URL, it may be worth adding additional input validation on the base URL provided, such as ensuring the expected protocol is used (HTTPS), however, at the end of the day the issue boils down to is the host correct, so ensuring the constructed URL has the expected domain and port.

Mitigations can be combined to severely limit these attacks:

a) Validate the untrusted data used to create the web-request and, additionally, validate the end-result URL before performing the request.

b) Whitelist a small number of domains & hosts and allow requests only to those.

c) Limit connections to only port 80 (For Http URL) and port 443 (for https) to prevent port scanning.

d) DNS Resolution: Resolve the IP of the target host, to ensure that IP is for that external host. (and not the internal IP)

e) Disable access to any protocol other than HTTP and HTTPS

If you still have questions I would recommend you schedule a consultation call to discuss.

You can check out this knowledge article (https://community.veracode.com/s/article/How-to-schedule-a-consultation-call) on how to schedule a consultation call with us.

Regards,

Kashif