I think I get your point.
var url = _rhiInstallationsLookupEndpoint + “mcs/”+ mcsnumber;
var request = RequestCreator.CreateGetRequest(url);
Here the left part of the URL is _rhiInstallationsLookupEndpoint is an internal value that can not be manipulated from the outside. Therefore the domain or port of the outgoing outgoing HTTP request can’t be change and the application is protected against Server Side Request Forgery on this particular example.
Rule S5144 raises an issue whenever an outgoing HTTP request is made using a tainted URL. As of today we are not able to filter out the use case where the tainted value is added at the end of the URL. SSRF are only possible is the attacker is in control of the beginnig part of the URL.
We are aware of this problem and we have plan to fix it:
In your case the rule raise an issue because the end of the URL is user controlled. An attacker can’t change the domain but he could add or tamper query parameters from the HTTP request: this is called HTTP parameter pollution. In general it’s less critical that an SSRF but if the integrity of these parameters is important then you should fix it.
Validating mcsnumber before using it to construct the URL should make the issue disappear. If it’s not the case let me know.
If you only care about SSRF and not about HTTP parameter pollution then you should mark the issue as “false-positive”.
Regards.