I’ve started up work again on the OWASP .NET ESAPI. Since a few months ago, when I translated the OWASP ESAPI from Java to C#, I’ve decided to change course a bit.
Java and .NET are architecturally and semantically similar – a lot of the direct code translation I did could be automated. But they are drastically different platforms. ASP.NET has a lot more security functionality built-in around authentication, authorization, and user management (Forms Authentication, the RoleManager, and the Membership API, respectively). Including a whole new user model makes sense in the Java ESAPI because JEE doesn’t give you APIs for the typical web site security architecture. ASP.NET does, and so re-inventing the wheel has become low priority.
Instead, I am going to focus on what I think will be helpful to ASP.NET developers. The .NET ESAPI will continue to mirror the Java ESAPI. But I’d like to spend my time extending rather than aligning, because there are some big opportunities to improve ASP.NET security.
Here’s a list of things I’d like to build:
- Web Controls that can validate and encode data. Web controls are central to ASP.NET (at least pre-MVC). ValidatorControls can be attached to most regular controls - why combine them into a “SecureControl”? While we’re at it, let’s make it easy by solving some common validation problems through regular expressions. Also, it’s a shame that we still haven’t addressed data encoding issues more cleanly than this. Integrate AntiXss and AntiSamy.NET into the control output!
- A web.config file that contains default secure settings, with directions and discussion of risk. This could replace the default web.config file.
- Cross-site request forgery prevention. ViewStateUserKey isn’t enough - perhaps use .NET CSRF Guard.
- Fix the default ASPNETSESSIONID session cookie to support regeneration and the secure property. Find out how to uproot the plumbing and make it seamless for everyone else.
- Several other small fixes and gotchas that I’m sure I’ll think of after I hit publish.
I’d also like to polish some things that already exist:
- Make horizontal and vertical authorization rules easy to integrate into any application. How about instrumenting reads and writes in data-bound controls with authorization checks?
- Make a simple cryptography library for .NET. It must be possible, but I still haven’t seen it. Let the user worry about a password, and securing that - the library does everything else.
Some things I won’t be looking into anytime soon:
- A new user model for ASP.NET for performing authentication and authorization. See above.
- Error handling, logging, exception management. See the Enterprise Library.
- The implementation of encoding for different contexts. See AntiXss and AntiSamy.NET
Overall, I’m hoping to solve problems rather than follow a spec. The OWASP ESAPI is great and growing, and I think it’s time that the OWASP .NET ESAPI do the same.
I’ll be travelling to various OWASP Chapters in the next two months (Columbus, Buffalo, Denver, Boulder) to talk about the OWASP .NET ESAPI project. Hopefully I can drum up some support so that we can get some great ideas and the great minds to build them. If you reading and are interested in helping or have some feedback, please leave a comment and let me know.
