I was privileged to make it to the March OWASP DC meeting up in Columbia Maryland, to see Jeff Williams give a talk about the OWASP Enterprise Security API, or ESAPI. This is a project that Jeff has been working on for a while, with a variety of collaborators in the web application security field. The public last saw a preview of this at last years “Live O” conference, and it has shaped up nicely since then.
I often comment on how the real answer to most web app security questions is in prevention, and preventative measures are usually “non-sexy” in the InfoSec world. This presentation was probably a step towards making prevention accessible on a historic scale in that it starts to really answer a question that previously has been unanswerable in any concrete manner — “So how do I write secure code?” ESAPI may be the turning point for developers who are looking for an answer to this question that is concrete and accessible, as opposed to the general and unhelpful ones that security professionals (including myself) have had to give to them up this point (such as “learn to write secure code”). ESAPI should be looked at by almost any developer out there as an example of what is possible, even if it’s not something that they can adopt right away. Hopefully, if the project grows, it will become something they can use down the road. But listening to Jeff talk about it really feels like history in the making.
After a short round of general discussion common to all OWASP meetings, Jeff began his presentation. He described the current application development environment developers are in today, and the massive problem that most developers face when they are told to “write secure code,” especially when they are given already existing code to have to fix or include in their application. There are millions of choices in terms of what technologies can be used or combined, and each one is multi-faceted, giving the developer an impossible amount of information to learn in a finite amount of time — and the environment is ever evolving to further complicate this. And, usually, the developer is supposed to do this task on limited time and budget.
Many times, Jeff said, in this situation, in attempting to fix or write secure applications, developers who are not security experts, and may have no experience with security what so ever then attempt to build security controls. Often, between their lack of experience and the fact that some of the problems here are very hard to solve, they do it poorly.
Vulnerabilities stem from either missing, broken, or ignored security controls. Jeff put forth the idea that application security should follow the same model as cryptography — do NOT roll your own. Security controls are very hard to get right, and developers should “leave it to the experts.” Up until now, however, there has been nothing for developers to turn to — the answer is always “learn how to code securely,” which has the problems outlined above. Unless the developer is really savvy and really motivated, this is often going to be a losing proposition.
If an API is suddenly available that does a lot of the security controls for the developer, however, the situation changes. The developer is able to solve the issues of missing or broken code by simply using the APIs. The new API can not solve developers ignoring security controls, but having a standard, simple API allows for a variety of situations that make developers less likely to ignore (or be able to ignore) security controls. With a standard set of API calls to look for, static analysis tools suddenly become worth their weight in gold — every X type of call should use Y, and if you find an instance where it does not, you fix it. Training for developers on how to incorporate security becomes much shorter and sweeter, there is less to learn and it is easier to master — all things which will make developers much more likely to implement security in their applications.
(more…)
