Hard-Coded Passwords Secuirty Hotspots not checking appsettings.development.json

SonarCloud
,
1

I noticed that the c# hard-coded password secuirty hotspots is not picking up my appsetting.Development.json file.
Not sure the reason why not. I’d like to know if I can enforce it as its working fine for test and production files. I want to enforce that no appsettings/config files store secrets and passwords.

1 Like
2

Hello Craig,

Can you share a code sample, so that I can better understand the situation? Thanks!

5

We are also facing this issue. Looking at this code, the appsettings.development.json file is deliberately excluded? Why is that?

sonar-dotnet/analyzers/src/SonarAnalyzer.Common/AnalysisContext/SonarCompilationReportingContext.cs at 95d954ff03f825310adfc5454dc87942a98f78ab · SonarSource/sonar-dotnet (github.com)

7

Hey George,

I found this comment. I can only speculate about the reasoning. My speculation would be that many users are fine with having hard-coded passwords for their development environment, so it was excluded to avoid the noise. From your perspective, do you think it should be included?

9

Hi Hendrik, yes I think those files should be included, and an exclusion filter be used to allow people that want to avoid scanning them. At the moment I simply can’t scan them for secret values which is not acceptable to me.

I appreciate that many developers may simply state that dev environment secrets are safe to leak, but a) developers will definitely use production secrets in these files, and b) third party services won’t always have development environments; leaking access to those secrets (either via a key that provides access to a development secrets vault or directly in the file itself) means rotation is a problem.

In either case, as SonarCloud users, we’ve found that the secret scanning is not really capable of doing what we need, as this snippet of an appsettings.json file passes the built in hard coded secret scanning rules anyway, it is only when we add password to the simulated connection string that anything is highlighted:

“ClientSecret”: “jinasd8923u8hewfbuifc_KiC-h27fdhdfjk”,
“Client-Secret”: “8saj93ehsoidsu8w3ins”,
“Secret”: “8edn3inii2nd”,
“ConnectionStringAzure”: “Server=myServerAddress;Database=myDataBase;User Id=myUsername;”

1 Like
10

Hi George,

Thanks for the feedback! I have pinged the security PM about this. Personally, I agree with what you wrote.

About your last point, by default the rule only searches for those keywords: “password, passwd, pwd, passphrase”. You can extend the keywords by creating a custom quality profile. Select the rule there and click on “change”. If you add “secret” as well, the credentials are found (in the non-development file).