Why ASP.NET MVC is 'insecure by design' , just like Spring MVC (and why SAST can help)

In the recent Secure coding (and Application Security) must be invisible to developers post Joshbw posted this great comment on the reasons why we end up with 'insecure by default Frameworks'

'...On top of that the frameworks are being developed with the same mindset of all of the other products out there - "What makes the customer happy first, and then maybe if security doesn't interfere with that". A great example is that MVCs really should employ declaritive binding rather than auto binding; it really is a marginal hit to development and ensures that the only fields that can be set are those explicitely exposed by the dev. Despite this problem being known for years even MS has taken the stance that devs should opt into declaritive binding despite the fact that MVCs are default allow....'

We need Security-focused SAST/Static-Analysis rules

While making the case that we need to bake security into Frameworks (in Secure coding (and Application Security) must be invisible to developers) I mentioned that SAST rules are needed if we are to scale.

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...

Secure coding (and Application Security) must be invisible to developers

At OWASP a while back we come up with the idea that '...Our [OWASP] mission is to make application security visible...' and for a while I used to believe in the idea that if only everybody had full visibility into 'Application Security' then we would solve the problem.

But after a while I started to realize that what we need to create for developers, is for 'Application Security' / 'Secure Coding' to be INVISIBLE 99% of the time. It is only the decision makers (namely the buyers) that need visibility into an application secure state

We will never get secure applications at a large scale if we require ALL developers (or even most) to be experts at security domains like Crypo, Authentication, Authorization, Input validation/sanitation, etc...