8. April 2012

  • Some proposed Visions for next OWASP Summit
  • Why ASP.NET MVC is ‘insecure by design’ , just like Spring MVC (and why SAST can help)

Some proposed Visions for next OWASP Summit

Since Summits must be part of OWASP’s DNA , and in case some of you are thinking of putting energy in creating the next OWASP Summit, I really think that the ‘Summit Proposal’ concept I detailed here is a good model.

So starting from the point that first we need a strong theme/vision, here are a couple ideas:

  • OWASP Summit on OWASP Projects - This would actually be at least one or more ‘mini-Summit(s)’ followed by a bigger one. The mini-summit(s) would be focused on very specific OWASP project’s activities (project review, project’s normalization/mapping, project XYZ, work, project’s consolidation, GIT migration, etc…) with the bigger Summit the one where the results (of those mini-summits) would be presented, and the main stakeholders (i.e. the OWASP Projects users) would come together to learn, share and collaborate
  • **OWASP Summit on Web Frameworks - **This would be the location where the key players of Web Frameworks (like Spring, Struts, Apache Shiro, RoR, ASP.NET, J2EE Stack,Grails etc…) would come together with OWASP’s community, AND developers AND their ‘clients’. The key objective would be to figure out how to help to make those frameworks/platforms ‘secure by default’ or at least to allow developers to easily code them in a secure way. In fact we could even be a bit radical and do a **OWASP Summit on Apache Shiro **(http://shiro.apache.org/) since those guys are clearly doing something right and have the momentum in working with key frameworks
  • OWASP Summit on Static Analysis - This is one that I’m specially very interested in, and would be focused on figuring a way to really make Static Analysis work in a web security world. There is so much potential with SAST technology which currently is not fulfilled because the multiple parties (from tools developers, to security consultants, to users, to clients, to regulatory bodies, etc…) are not collaborating and working together to figure out a number of Open Standards which we call all use to communicate (for example why can’t we feed static analysis data to a web proxy/scanner like ZAP?)
  • OWASP Summit on Web Privacy - Privacy is becoming more and more a big issue in the Web World, and with: a) Browsers adding features like the Do not track header (http://donottrack.us/ ), b) new laws being passed, c) recent big privacies breaches, d) governments regulatory bodies wanting to do something about it , and … {many more recent developments} … Privacy is definitely a topic which will draw a good crowd (and although one day it might be big enough to have it’s own dedicated ‘Brower Summit’, I think in the short them, the Browser track (following the work done at the last Summit) should be part of this Summit).

Of course that there are many other hot topics or OWASP Projects we could create a Summit around (ESAPI, OpenSamm, Guide Trilogy, Cloud, DAST, Secure Coding, Code Review, PenTesting, etc…), what is needed to make it happen is a core team with passion and energy for it.

On the financial side of things, one thing that OWASP could do is to say:_ “Here is 50k seed money, the rest you need to find from other sources (including internally like OWASP Chapers)”_. And maybe even that 50k is not needed (if there is enough energy and supporters willing to buy ‘20k Summit tickets’ )

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

In a way Microsoft’s (and Spring’s) decision to chose the insecure default (see Spring MVC Autobinding Vulnerability) is probably the correct business decision.

Choosing the secure alternative, would introduce a hit to development (Joshbw thinks this would be marginal, but I’m not so sure), which these Framework developers felt could create a bad user experience (their users are the developers) and could potentially drive away users into other frameworks that had such ‘by default’ AutoBinding features.

This is why I say that We need Security-focused SAST/Static-Analysis rules so that we can deal with the cases where AutoBinding creates vulnerabilities.

In fact, a good example of security adding value to developers would be if those SAST rules (via an security engine) would actually automatically introduce those ‘Declarative Bindings’ without requiring a developer’s intervention (this could happen behind the scenes , ‘invisible’ to a developer, unless that was creating business impact (i.e. side-effect).

To see an example of what this could look like, take a look at The future of secure code? Fixing/Encoding .NET code in real time (in this case Response.Write)

On the commercial SAST front, as far as I know, only Armorize ventures into this ‘code fixing territory’