Doubt about not detected hotspot in web.config about hardcoded credentials

mvillanueva · October 1, 2024, 11:07am

Dear all,

I have a C# project with a web.config file that does not have a project solution file. For this reason, I am analyzing this project with sonar-scanner-cli (versión 5.0.1.3006) with Server SonarQube Enterprise 9.9.6

The reason of this post is to ask why the xml scanner does not detect a hotspot regarding hard-coded passwords. I have another project that indeed has sln file and when I use the MsBuild Scanner, the hotspot is detected. See screenshots.
Hotspot detected with MSBUILD

Hotspot not detected with sonar-scanner:

Thank you.

Colin · October 2, 2024, 2:41pm

Hey @mvillanueva

Detecting issues on web.config files involve rules coming from GitHub - SonarSource/sonar-dotnet: Code analyzer for C# and VB.NET projects, which are only executed when using the Scanner for .NET (because they use the Roslyn framework, which are executed at build time). So this is expected behavior.

To be clear, none of your C# files are getting analyzed when you do this.

mvillanueva · October 10, 2024, 1:28pm

Dear Colin,
I am aware that those files are not analyzed with C# rules. Since the project does not have sln and I wanted to analyze the .config file, I configured the project so that this extension to be analyzed with the xml language. Thus, what I expected is the XML scanner to be able to detected the homonym rule regarding passwords. My doubt was why the xml scanner does not detect this hotspot (xml rule nor c#). In summary, the file is analyzed by the xml profile but the hotspot is not detected.

Best regards and thank you for your response.

Colin · October 11, 2024, 6:36am

That’s a good question. I assumed that our XML analyzer didn’t care about web.config files but it looks like I’m wrong.

github.com

SonarSource/sonar-xml/blob/4cf7d9838d4d446f7c5e6db4631f470ecee68f23/sonar-xml-plugin/src/main/java/org/sonar/plugins/xml/checks/security/HardcodedCredentialsCheck.java#L154


      
            }
            if (isCredentialNode(node, credentialWordsSet())) {
              reportIssue(node);
            }
          }
          
          private static boolean isValidCredential(String candidate) {
            return candidate.trim().isEmpty() || VALID_CREDENTIAL_VALUES.matcher(candidate).find();
          }
          
          private static boolean isValidWebConfigCredential(String candidate) {
            return isValidCredential(candidate) || VALID_WEB_CONFIG_CREDENTIAL_VALUES.matcher(candidate).matches();
          }
          
          private void checkSpecialCases(XmlFile file) {
            specialCases.forEach(specialCase -> specialCase.accept(file));
          }
          
          private void reportIssue(Node node) {
            reportIssue(node, String.format(ISSUE_MESSAGE, node.getLocalName()));
          }

I’ll flag this for some expert eyes.

Leonardo_Pilastri · October 15, 2024, 3:34pm

Hello there,
as you mentioned, in the analysis performed with the MsBuildScanner, the rule raising the issue belongs to the .NET analyzer, while in the sonar-scanner-cli case it’s the SonarXML analyzer that is checking that file, and apparently fails to spot the issue.

I think it’s a false negative, but I am not sure I got the correct reproducer, on my end I am trying with something like this

<configuration>
  <appSettings>
    <add key="somekey" value="Password={ConnectionCredentials.Password}" />
  </appSettings>
</configuration>

Does this example resemble your use case?

mvillanueva · October 16, 2024, 8:08am

Dear Leonardo,
Yes, the example you provided resembles my case. Is this a false positive? Can you explain me why?
If that is a false positive, it should not be spotted in .NET, isn’t it?

Best regards, and thank you for your help.

Leonardo_Pilastri · October 29, 2024, 4:37pm

From your original thread, I understood that you were reporting a false negative on the sonar-xml side (the sonar-xml analyzer is not able to detect an existing issue), so just to clarify, do you expect to see an issue reported for the example I provided or not?

I am not 100% familiar with the context of your example, so I am unsure if on the C# side that should have not been reported, since there is some kind of string processing being used (Password={ConnectionCredentials.Password}) and I don’t see an actual hardcoded password

mvillanueva · October 31, 2024, 3:56pm

Dear Leonardo,
I am not an expert in C# nor security, but my doubt is more related with consistency in scanner detection. What I expect is the same detection both in xml and c# language (since both have the same rule regarding hardcoded passwords):

If the code does have a hotspot I expect to be detected in both languages
If the code does not have a hotspot I expect that neither of them show any issue.

However, what I have observed is that if the .config is analyzed with the c# the issue is shown and if I analyze it as xml it does not.

Did I explain myself?
Best regards and thank you for your response.

gregory.paidis · November 22, 2024, 2:57pm

Hey there!

As my colleagues mentioned, the discreptancy comes from the fact that this diagnostic is implemented across many languages, and the .NET ecosystem is very tightly related with web config files, so we have some custom logic for them in the C# analyzer.

Now, I agree that the behavior should be consistent across the board, and I would suggest that your case is a False Positive, as you do not seem to leak any hard-coded credentials.

I made an issue in our internal backlog to track this case and fix it in some upcoming hardening sprint.

For now, you can safely dismiss the issue as a false positive.

Thanks for raising this!

mvillanueva · November 25, 2024, 12:59pm

Thank you a lot for your responses.
Ok, I will mark this issue as false positive.
Best regards.

system · December 5, 2024, 3:09pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.