which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube 7.9.3 (build 33349),
what are you trying to achieve
I am new to SonarQube and am interested whether or how SonarQube helps to spot missing input validation in web applications, in particular when using C#/.NET.
First, I do know that SonarQube can detect some of the OWASP Top 10 vulnerabilities like XEE or some injections. But imho this is just the tip of the iceberg when looking at missing or incomplete input validations. Extending on the XEE example, SonarQube apparently validates that XmlResolver is initialized to null, but in fact I´d argue one is supposed to provide a non-null XmlResolver that either resolves external entities to an internal resource as needed, or throws an exception to indicate an unexpected external entity was referenced in the input.
Does SonarQube detect, that no validation (calls to XMLDocument.Validate) is taking place at all? that no Schemas are added prior to validation?
On What's New in latest releases | SonarQube you write “Tracking Untrusted Data from More C# Frameworks” and mention WCF. Can you please elaborate what exactly you are detecting? I´d be looking for tests that check whether How to: Perform Message Validation with Schema Validation in WCF | Microsoft Docs (or equivalent) was adhered to. In fact the tutorial looks so complicated to me - also a newbee on WCF - that I am wondering whether there is a better way to implement and enforce it.
what have you tried so far to achieve this
I looked around in existing code and reports, but didn´t find any rules violated even though I was hoping for that.
You are currently using SonarQube 7.9.3 which is the former LTS version. Especially when you are asking questions about “do you raise an issue in such context”, it’s highly recommended to use the very latest version which contains all our enhancements. So the best today is to rely on SonarQube 9.0 and a new version is released every 2-3 months.
Can you try this version and tell us if SonarQube still doesn’t detect what you expect?
If this is the case, then the best is to share code samples, reproducer, whatever you are using on your side to run your tests so we can reproduce on our side and provide you reasons why this is expected or not to raise in your context.
Finally, for C#, we have an almost full coverage of OWASP Top 10. We are at the stage to cover corner cases, so that’s why I’m interested to hear more from you.
Hello @Alexandre_Gigleux ,
thanks. I asked the IT folks why they are still on the old version and to upgrade asap otherwise.
But is there a public instance where you/we can demo code and the findings? A list of all checks?
Thanks
Joachim
The code in XmlNonValidatingInputController is very close to the bad code I typically see in real application code: construct an xml document, load with xml string, extract one or more values. Ok, the fact that I used Get to pass XML is not typical, but it was just easy that way.
By contrast, XmlValidatingInputController shows how to properly validate XML input using an (optional) DTD.
Todo: I want to create a similar example for SOAP/XSD validation, but didn´t yet have the time to do it.
My hope is, that SonarQube can help to spot missing validations. Unfortunately the code in XmlNonValidatingInputController does not trigger any rule so far. Did I overlook some configuration? Or is it not classifying arg in Get(arg) as an input? I am new to Sonar, thus might miss some details…
Thanks for the detailed report and the repo. This is exactly what we love here at SonarSource to be able to exchange about real test cases.
For the test case XmlNonValidatingInputController, this is expected that nothing is raised. The following syntax is not safe only for .Net Framework < 4.5.2:
XmlDocument parser = new XmlDocument(); // Noncompliant: XmlDocument is not safe by default
parser.LoadXml("xxe.xml");
Iin you project you are using Dot Core, so if you want to have an issue, you need to write that:
XmlDocument parser = new XmlDocument();
parser.XmlResolver = new XmlUrlResolver(); // Noncompliant: XmlDocument.XmlResolver configured with XmlUrlResolver that makes it unsafe
parser.LoadXml("xxe.xml");
For the test case XmlValidatingWithCachingResolverController.cs, this is really tricky. It’s complex to analyze the logic of the overrode method GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn) to finally determine that there is a path where no custom resolution is done and we are back to the default situation. Here, we decided to prefer to have False-Negatives instead of potential False-Positives.
If you market you are detecting missing input validation - “Tracking Untrusted Data” on your website, then you clearly missed out for XML at least in that scenario. I´d be interested to see examples where SonarQube spots issues.
Thanks for the list. Ok, looks like input validation is only supported where lack of would lead to a vulnerability, correct?
We do have a standard requirement to validate all input, thus checking for vulnerabilities only is not sufficient. Avoiding errors in subsequent process steps is also a clear goal. I think this is best practice, also looking at Input Validation - OWASP Cheat Sheet Series (and yes, injection errors are not just a matter of input validation but also of improper output encoding matching the target interface requirements.).
What exactly are you using to tag data as untrusted input? And I´d definitley think, using non-validated data for any other interface should be considered bad practice, no matter whehter the other interface is towards user output, framework, operating system, database or some other interface.
Our taint analysis engine detects 14 specific vulnerabilities and for them we are able to detect if the sanitization (which is somehow the same as saying the “input validation”) is performed. If it is performed correctly then we raise nothing and you have nothing to review manually.
Definitely there are some vulnerabilities we could add to our taint engine like the XML/XXE case you highlighted. Still as of July 2021, we provide a full coverage of the OWASP Top 10 2017 categories which should make you feel confident to release your software in PROD if nothing is reported by SonarQube.
Today, we don’t provide and we don’t want to provide a rule that will ask the developer to review all inputs and manually check if they are safely validated. That will require a lot of work for the developers and will conflict with what is done by our taint engine which do the job in 90% of the cases.
There is no special keyword to put so that the data is considered as untrusted. We support all the way to define inputs in C# for .Net Framework or .NET Core. By time to time, some users are reporting that we missed in our studies some corner cases and that’s OK: just wait the next release and you will be covered.
I created a ZipController in my test code, but it doesn´t yield a violation, even though both the path and zip are declared as input of a method marked [HttpGet].
Can you share a ZIP file containing your project with this false negative so we can work on it and tell you why nothing is raised?
