Unable to trigger injection flaws for C# with Developer Edition

Hi all,

Sonarqube version:
Sonar scanner: sonar-scanner-msbuild-
SonarC#: 7.12 (build 8217)

I wanted to see Sonarqube detection capabilities on security side as a SAST. I installed Sonarqube 7.6 Developer edition with demo license.

And used Webgoat.net project that born to be vulnerable. It has many vulnerabilities like XSS, SQLi, RCE etc.

The projects:

The result was worse than expected.
Hardcoded passwords, ReDos(Regex Dos) as blocker and also
Cookie with httponly flag and dangerous eval usage issues found.

Attached sonarway and issues file.

Is there something wrong for scanning, profiling?

1 Like


You should use SonarQube 7.7 DE because it adds 11 injection vulnerability rules on top of the existing Vulnerabilities and Security Hotspots.

WebGoat.NET is a very special benchmark because there are multiple clones of it and I’m not sure to know which one is the “official” one.
On SonarSource’s side, we are analyzing this version: https://github.com/rapPayne/WebGoat.Net which received recently some commits. But there is also:

We don’t raise a lot of issues on rapPayne/WebGoat.Net, that’s true. Here what we have as of now:

On my side, I did not manage to find a full list of all the vulnerabilities that are in the WebGoat.Net project.
If you have such list, I’ll be happy to look at it.



I see rules for SQL injection, XSS, OS Command injection already included in 7.6 Version. So should it be expected to find them?

I’ve downloaded and scanned Webgoat repo you mentioned. Similar results I got. But only one SQLi on one file. There is more

There is TODO.txt in one of the project and it seems following vulns exists:

  • Command Injection (DONE)
  • Debugging leaks (DONE)
  • Insecure message digest (DONE)
  • Unsafe (DONE)
  • Not using SSL (DONE - already present when logging in)
  • Insecure random # gen (DONE)
  • Hard coded seed (For when using random functionality) (DONE)
  • Hard coded salts, keys (Done)
  • XSS (Done)
  • Information disclosure (Done)
  • Session id to the screen / log (Done)
  • Trace (Done)
  • XPATH Injection (Done)
  • Header injection (Done)
  • Custom crypto (args have to use a byte array and do a bitwise operation) (Done)
  • Readline (denial of service) (Done)
  • Hard Code Passwords (PWD in source code) (Done)
  • Denial Of Service (RegEx) (Done)
  • Httponly (cookie flag) (Done)
  • Secure (cookie flag) (Done)
  • XML Injection(Done)
  • Verb tampering (changing POST/GET etc. request to something different) (Done)
  • Session timeout (config setting) (Done)
  • Dir traversal (Done)
  • Cleartext passwords (commonly used config files) (in web.config) (Done)
  • Debugging enabled (Done)
  • Password disclosure to screen or to log (Done)
  • Unchecked redirects (already in there) (Done)
  • Unencrypted viewstate (Done)

Hi all,

I’m using SonarAnalyzer.CSharp Version= (latest available as nuget package) (https://www.nuget.org/packages/SonarAnalyzer.CSharp/) directly as an analyzer in visual studio. I also ended up using WebGoat (https://github.com/rapPayne/WebGoat.Net) as a benchmark for sanity check on using sonar analyzer to checkout how it works (I start using sonar very recently).

Likewise @enderhb, I’ve got very few feedbacks on security and vulnerabilities. Issue S3330 (Cookies HttpOnly property should be true) was the only security-related issue I got, even though this project should have plenty of security issues (on SQL queries, for example, like @Alexandre_Gigleux posted above).

@Alexandre_Gigleux suggested the usage of sonarqube 7.7. I’m not using sonarqube, but I’m using the latest available C# analyzer (I believe it’s the same sonarqube uses on the background, can I assume that?). So I’m up to date with newer rules.

Does anyone knows why can’t I get the same outputs (like reporting issues on sql queries)? Can it be only versions mismatching?

Thank you