SonarQube not detecting authentication issues in HTML files

  • I am using the latest SonarQube docker image to analyze my Java project with maven(3.3.9).
  • Analysis completes with 1 warning (about file blame)

I am able to detect authentication issues (like hardcoded passwords) in java and javascript files, but it doesn’t detect the same authentication issues in HTML files although it detects normal bugs in HTML files.

Any idea, what I can do to fix this?

Update: I have read the docs and there is no such rule defined in the HTML file scanner unlike in Java and Javascript. Do I need to write a custom Java plugin for this?

Hey Sahil,

thank you for the feedback!

Indeed, there is currently no such built-in rule for HTML. Of course, in principle you can develop your own plugin that will raise the issues you want, but could you give us a concrete example of what you have in mind? We will then be able to discuss it internally and, if we consider it a good rule, we will be happy to implement it as part of our HTML analyzer and release this rule in a future version. :slight_smile: A small code example would be very helpful!

Hey Malte,

Thanks for the response. Some of the usecases I encounter are:

When we are passing credentials as params to login urls like

ar iframePath = ‘/xyz/abc.php?name=’+userId+’&password= mypass123&enter=Sign%20in&request=hello.php?form=update&newname=james&fullscreen=1’;

Or when we are hitting API’s

“authorization”: "Basic " + btoa(“autologin:mypass123”)

I think even some basic regex search around password will do until we have something concrete, or is there any way I can configure my Sonarqube to check for certain regex patterns?

Hey Sahil,

thank you!

I understand the first example and I will suggest it internally. :slight_smile: Basically, we could match hardcoded credentials anywhere where a URL is used in HTML code (such as in href or src attributes).

The second example is a little bit different: If I understand correctly, this is not HTML code, but rather JavaScript code embedded in an HTML file, is this correct?

Let me take a little step back here to explain how SonarQube works: Essentially (a bit simplified), SonarQube contains a bunch of analyzers, and each analyzer is responsible for detecting and raising issues for a particular language. For example, there is a Java analyzer for Java code, an HTML analyzer for HTML code, and a JS analyzer for JS code. So while your first example (HTML code) would have to be detected by the HTML analyzer (and today this analyzer has no such rule), for your second example (JS code) it is the JS analyzer that should raise the issue. As you have correctly observed, in fact there is already a rule for JS that detects hard-coded credentials. The reason (or, at least, one fundamental reason) why your second example is not detected is that your JS code is embedded inside HTML code. Indeed, the decision which analyzer should analyze which file is based on the file extension. That is, the HTML analyzer will analyze .html files, while the JS analyzer will analyze .js files. Unfortunately, HTML files may also contain JS, which means that in reality, the JS analyzer should also analyze .html files (but focus on the JS code inside them, while the HTML analyzer focuses on the HTML code inside them). As of today, unfortunately this is not yet supported and JS code inside HTML files is still ignored. We are aware of this and we plan to fix that soon so that you can also detect issues in JS code inside HTML files.

As for your last question: There is no way to configure SonarQube to check for certain regexes in general, but what you can do is write your own mini tool (say, a script that uses grep and just looks for some regex) and then creates generic issue reports that can you can then import into SonaQube. I hope that this can be useful to you as an intermediate solution. :slight_smile:

Hey Malte,

Thanks for the insights. Indeed second example is from <script> tag embedded inside html files. I will write a custom grep script for now as you suggested. Will be waiting for the future releases.

Thanks :slight_smile:

1 Like

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