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

SonarQube Server / Community Build
, ,
1

Hi team,
this is a question related to this topic: Change this code to not construct the URL from user-controlled data - SonarCloud - Sonar Community (sonarsource.com)

@Pierre-Loup_Tristant based on your comment I open new thread.
Is this still an issue - if the end of the URL is based on user input, sonar will report it as potential SSRF vulnerability. Im having the same issue as in the topic I refer to in the beginning. I added additional validation but sonar still reports it as a vulnerability. I just want to make sure it’s okay to close it as false-positive as of today.

Thanks!

2

Hello,

I will let @Pierre-Loup_Tristant get back to you or someone else more qualified than me, but if you could provide more details about the version of SonarQube you are using that would definitely help to get an answer. A reproducer is also always appreciated.

Regards
Alex

4

Hi Alexandre, we use

the id is propagated via multiple functions from request body:

if (!uuidRegex.test(id)) {
            logger.error('Error:', convertToSafeError('SubscriptionId is not in UUID format'));
            throw new Error('SubscriptionId is not in UUID format');
        }
        const dsapiAxiosInstance = await getAxiosInstance();
        const { data } = await dsapiAxiosInstance.get(`${process.env.SOME_VARIABLE}/some-path/${id}`);

image

5

Thanks for the details.

Let’s be more precise: which version of SonarQube do you use? (it’s in the footer of the SonarQube UI).

Be sure to use the latest (as of now 10.1) to get the best results.

6

thanks for info related to location of version, we use

  • Data Center Edition * Version 9.9.1 (build 69595)
8

Hi Jan,

Thanks for sharing the code! I can confirm that if uuidRegex is correctly defined, then there is no vulnerability here. Please feel free to mark it as a false positive.

1 Like
10

Thank you team!

1 Like