SonarQube TLS 8.9.0
Trying to detect Security hotspots
We have identified a JavaScript file (.js) with the following:
/**
* Expose all properties available in the application, and make them
* available in a query to be used in GraphQL
*/
/**
* Read property.prop files
* @returns
*/
const readJsonFromFile = async () => {
try {
const propertiesFromFile = await fs.readFile('./property.prop', 'utf-8');
return JSON.parse(propertiesFromFile);
}
And yup, you guessed it, some of those properties would identified as Security Hotspots if they were simply defined in the code.
It’s seems if the static code is traced through to see the context where the properties are used that they are security sensitive. Why is this not detected?
They were not detected as Security Hotspots. Hard those items been defined inside the JavaScript file as properties, they would have been flagged as " potentially hardcoded credential".
var mysql = require(‘mysql’);
Hardcoding credentials in source code directly is, per se, a security-sensitive scenario. On the other hand, storing properties in a file and reading them into memory is a good approach and does not constitute, per se, a security-sensitive scenario. There are other factors to consider:
The question is (1) where is that file stored, (2) who has access to it and (3) is the file encrypted or not. Based on those 3 elements, it may be perfectly fine and actually best-practice to read the properties from a file in your JS source code. And most importantly, SonarQube scans source code files written in 27 supported programming languages: this does not include plain properties files with no actual “programming language”. SonarQube is not scanning your “properties” file because it is not a source code file.
GitHub’s Secret Scanning detects it as an issue because you are storing the file, unencrypted, in the repository - and they have decided to implement such a feature, which may come in handy in combination with SonarQube.
I understand your explanation, but I disagree with the conclusion. It was my understanding the approach of moving security-sensitive information from the “Vulnerabilities” category to the “Security Hotspots” category was:
With a Hotspot, a security-sensitive piece of code is highlighted, but the overall application security may not be impacted. It’s up to the developer to review the code to determine whether or not a fix is needed to secure the code.
SQ should be able to trace from the use of the password in a connection string, for example, to where that password was populated from and see that it is in clear text the entire time. That makes is a Security Hotspot that needs to be brought to the developer’s attention fro review, in the same manner as if it were embedded in the source file in clear text.
I have yet to extensively examine the detection capabilities of 8.9.0 since we are just getting started, but past experience seemed to be SQ would flag almost any occurrence of the word password as a Hotspot. eg: public static final String GET_ONE_TIME_PASSWORD_STATUS = "<restendpoint>";
‘PASSWORD’ detected in this expression, review this potentially hard-coded credential. public static final String PASSWORD_MIN_CHAR_SETS= "<somevalue>";
‘PASSWORD’ detected in this expression, review this potentially hard-coded credential.
Same for PASSWD and PWD (even when PWD implies Present Working Directory) ,
The number of “Not an issues” made this feature less valuable than we believed the potential a static analysis tool can deliver. We expect better given the prominence "Security Hotspots are given in the latest release. I believe the failure to flag the import and use of plain-text credentials is a defect/bug. At the very least this should be called out.
I would appreciate if there is any detailed information available on the operational aspects of flagging the “Hard-coded credentials”, what it looks for, where, in what context and depth, such that we can understand the gaps.
This is not a defect or bug, but a functionality that may be implemented one day and that I would suggest communicating via the New features - SonarSource Community category to bring up the Product team’s attention.
Detailed information on the Security Hotspots rules flagging potentially hard coded credentials can be found in the rule description in the rules catalog under https://rules.sonarsource.com/.
This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.
It’s recommended to customize the configuration of this rule with additional credential words such as “oauthToken”, “secret”, …
What are the " the patterns from the provided list." that SonarQube has defined? PASSWORD, PASSSWD, PWD, what else ?
How are they evaluated? Does " hard-coded credentials in connection strings" literally mean a quoted string, a statically declared string declared in the same file, another code method ( *.java) file? Evidently it does not extend to reading static values from a property file.
Where/How does one " customize the configuration of this rule with additional credential words"?
Does it actually trace through the variables used in methods (eg: mysql.createConnection() / connection.connect() ) or just scan for the credential words?
the hard-coded credential checks are done on a per-analyzer basis, so for example you can find the relevant source code for Java in sonar-java here. In the case of Java the default keywords we are looking for are password,passwd,pwd,passphrase,java.naming.security.credentials. To modify this list you have to create a quality profile. If you activate the rule in the quality profile you will see the following popup where you can modify it:
