Vulnerability Detection: Spring DI and Factory Support in Java + C#8

Hello Java and C# developers,

We’re proud to announce that our taint analysis engine is now able to detect even more Security Vulnerabilities in your C# and Java code.

C# 8 Support

C# 8 comes with its set of new features/syntax. In order to work well the taint analysis engine needs to transform native languages into an abstract shared language used by the engine itself. Until now, each time a specific C#8 syntax was encountered, the engine was not exploring it. We fixed this limitation and the taint analysis engine understands C# 8 syntax such as default interface members, switch expressions, property patterns, using declarations, null coalescing assignment.

Spring Framework Dependency Injection (DI) Support

The Dependency Injection mechanism is a key feature of both Spring Framework and Spring Boot, which are used by a lot of Java developers. This feature lets you declare a variable with an interface type (to define the contract) and the framework injects the interface implementation at application startup. For example, in the following code, the variable “owners” is declared as being an implementation of type “OwnerRepository” but nothing in the OwnerController class indicates what particular implementation will be used at runtime:

When the only information known about a variable is its interface name, there’s not a lot we can get from it. Before now, analysis did not explore the potential implementations of a given interface, thus overlooking some potential Security Vulnerabilities. So in the previous example, the real type of “owners” was unknown, and the exploration of the call graph didn’t go any deeper than that.

Now the engine can explore implementations of the interface. In our example, we now see that the OwnerRepository interface is implemented by OwnerRepositoryCustomImpl class and this implementation is vulnerable to SQL Injection:

Factory Pattern Support

The Factory Pattern is a well known way in Java to create instances of classes to reduce the coupling between classes. With this pattern, you generally find a static method that is there to trigger the instantiation of the classes based on a parameter. If classes are created with the “new” keyword, there is no problem for the taint analysis engine to track that. But if classes are created dynamically using reflection, the engine previously stopped there.

We’ve just fixed this limitation too, so now in the same way we explore potential implementations of interfaces in a Spring context, we also look for concrete implementations of interfaces without known runtime types to see if a Security Vulnerability can be found on them if tainted data reaches one of these implementations.

You can already enjoy these new features on SonarCloud. For users of the SonarQube Developer Edition or above, these new features will be built in to the next version (8.1).