What I mean is that we need to codify (in a SAST rule) how a particular feature should be used in a secure and insecure way.
Spring and AutoBinding Vulnerabilities
It is all nice and good to say that Frameworks should be secure, but in the real-world , a very practical problem (Framework developers have) in baking security by default into their Frameworks, is the sheer number of user-scenarios that they need to cover.
Take for example the Spring MVC Autobinding vulnerability (also called 'Mass Assignment' or 'OverPosting').
Ultimately, the AutoBinding capabilities of Spring (and just about every other MVC Framework) is a feature! It is loved by developers and one of the reasons of its success.
So saying to developers to 'dont code using AutoBinding' is as stupid as telling an Internet user to 'not click on a link!'
On the other hand, this vulnerability can be devastating and I have found critical vulnerabilities caused by its misuse.
And here is the key concept. The problem is not in the AutoBinding capabilities, the problem is in its insecure use (like the examples in Spring's Framework sample applications JPetStore and JPetClinic who are vulnerable to the Spring MVC Autobinding vulnerability).
The same can be said for Html encoding, 'Secure Encoding' libraries (like AntiXSS, ESAPI), Authentication , etc..... (the key is how they are used)
Using SAST rules to handle the shades of grey
In most Frameworks, there is already a 'secure way' of using them, and an 'insecure way'.
The key is in identifying (via SAST rules) the code that created security vulnerabilities, and to allow developers/architects to customize those rules (or the engine that runs them) in order to take into account the target application's Architecture, Risks, Threats and Trust levels.
And some times, the difference can be minor.
A security vulnerability might be created (or mitigated) via a simple:
- config file setting,
- method's attribute,
- variable assignment,
- if statement,
- etc...
