Change this code to not construct the URL from user-controlled data

SonarQube Cloud
1

Hi,

We are getting an error for “Change this code to not construct the URL from user-controlled data.” where we are passing the url for the request as a parameter. The example shows an external endpoint being passed the url. But we use in our internal .dll and all of the inputs are validated before the call. The same issue was discussed in Help SonarCloud with understanding the usage of untrusted and tainted input but there was no setting to control it.

The code sample suggest to validate the url passed.

// Match the incoming URL against a whitelist
if (!whiteList.Contains(url))
{
return BadRequest();
}

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); // Noncompliant

How can I configure that I have already verified the input or how would you suggest to handle this?

Regards,

J

2

Hi @jawahirlal,

I would like to have a better understanding of you problem. Could you share a code snippet to illustrate how inputs are validated before the call ?

Thank you.

3

Hi Pierre-Loup,

Thanks for the reply.

For us this is not a publicly exposed endpoint and this dll is used to call internally to call to defined endpoints. No external user passes those as parameters.

On the call _rhiInstallationsLookupEndpoint is an endpoint defined internally.

var url = _rhiInstallationsLookupEndpoint + “mcs/”+ mcsnumber;

var request = RequestCreator.CreateGetRequest(url);

Thanks,

J

4

Thanks for this code snippet.

Could you provide more detail information about mcsnumber? Where does this value come from ? Is this value coming from an HTTP request?

You say the endpoint is not exposed publicly. Could you be more precis ? Does it mean that the application is not exposed to the internet? Does it mean that this particular endpoint can only be reached with the proper authentication and access control?

Thank you.

5

Hi Pierre-Loup,

mcsnumber is passed as the parameter from an authenticated http request.

But the solution is suggesting that we should validate the url that it is one of the whitelisted urls. url endoint is not an external paramter.

Regards,

J

6

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.

7

Pierre-Loup_Tristant can you please look into this Change this code to not perform client-side redirection based on user-controlled data

8

Hi ayushcs,

I will close this thread since it’s more than two years old. If you want to share feedback on this rule please create a new thread.