OWASP Enterprise Security API

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.

Jeff then went on to show the “map” for the ESAPI — including fitting into existing systems. One important facet is that use of the API will still allow use of enterprise resources — just protected by the API. Jeff then went on to discuss several key features of the API that solve “hard to solve” problems for the developer. One of the ways that the API solves these hard problems is the combined experience and knowledge of not only Jeff (who has been doing application development and security for a staggering 15 years or more, in a field where most people have only been doing it a few at most), but a peer review group of other very experienced people, both in OWASP and in the web application security field.

Jeff showed that ESAPI provides methods for handling extremely different issues such as sanitizing input, canonicalizing, and encoding at multiple points in the application process, both inbound and outbound, which are things which are very hard to do properly even for someone who is an experienced security developer or architect, and problems that application developers constantly face.

ESAPI provides methods for handling users and authentication, including having a user object that is accessible to any other part of the API, so that the application no longer has to struggle with passing user sessions around to various parts of itself.

ESAPI also applies the ability to apply access control at different levels of the application, to provide tiered protection to the sensitive parts of the application — so you can determine not only if a person is authorized, but if they should be making the type of requests that they are based on where they are in the application. This can also, again, be applied to output as well as input, with the central ESAPI objects keeping things in sync.

ESAPI has a unique method for handling direct object references, which are always potentially dangerous, and can reveal information or allow for attack vectors — ESAP uses a reference map, which can translate between external and internal identifiers, or encrypt references so that they can’t be easily used. This also allows for the application to detect if someone is trying to access a reference that they are not entitled to — a normal users shouldn’t be “guessing” objects, and the reference mapping will detect this.

ESAPI also has built in tools for handling sensitive data — by Jeff’s own admission it doesn’t do “everything” crypto, but it has objects for most commonly needed functions for crypto, hashing, user tokents, etc.

Handling exceptions properly, including logging and detecting problems is something that almost no application code does well natively — Jeff has sought to change that. If you use ESAPI, you will have verbose logging capabilities, including a dual-sided exception, that throws a “polite” message publicly while logging specific details privately. Various parameters can be configured as to how much to log, and thresholds for logging and system responses.

The HTTP utilities section of ESAPI has a variety of web function handlers, that cover sessions, use of cookies and tokens (and in turn CSRF prevention and other goodies).

One intriguing facet of ESAPI that goes along with its error handling is the fact that it has code that can be used for built-in intrusion detection. Thresholds can be set for errors in any part of the application to set flags, log, or even take responses to too many errors in a period of time or other parameter. Judicious use of this would make any type of application scanner useless, as too many errors would lock out a user account. This doesn’t have as may applications for unauthenticated sessions, but it does allow for anomaly detection, and/or alerts based on logging. Jeff said that he did not feel the need to build in notification via email or the like, but it would be an easy add on with a log-tailing utility of some sort, due to the rich logs that ESAPI turns out.

Configuration of ESAPI is handled in one central configuration file, and is easily implemented into projects in supported languages. Another “simplification” feature of ESAPI is that all of the methods and calls are named “simply” referring exactly to what they do, so that there is little confusion as to what should be used for what purpose. ESAPI also maps nicely to covering almost all of the current OWASP Top Ten in terms of providing solutions — way more than any other existing API or framework.

Jeff is adamant that ESAPI is NOT a framework — but he would love to see it built into existing frameworks. It is at a “release” point in its lifecycle, potentially ready to start being used for real applications. It has been tested in a variety of ways and had great peer review. As with many open source projects, it is still “in development,” but Jeff feels pretty good about where it is at right now.

One limiting factor to the deployment of ESAPI is that the current working version is for Java, and it has not been finished in any other languages. The one resounding chord from the audience during the Q and A after the presentation was that availability in other languages is a must. Jeff said that there is a .net implementation that is underway and near completion, and there is a php implementation that is just being begun, but is being headed by Andrew van der Stock (also of OWASP fame), and Andrew is putting a lot of work into getting it done as soon as possible.

Some other points of interest are that ESAPI can be used to replace certain java API calls that are “banned” due to being unsafe — ESAPI replaces them with it’s own “safe” calls. ESAPI can also be used in a filtering mode, to put in front of an existing application and catch data going to and from it, without completely recoding the app. There was not time to discuss this in detail, but I’m sure that Jeff would happily give people information for follow-up.

Jeff also stated that if there are developers for other languages out there (such as Ruby) who are interested, he would happily work with them to try to get ESAPI working in their languages as well. Several people in the room stated that Ruby on Rails has a few minor points like ESAPI built into the framework, but its nowhere near as robust or featured. There was also some discussion by one of the meeting attendees that they saw some issues with large scalability in some Java application types, and was going to discuss it with Jeff after the meeting.

All in all, ESAPI looks to be a portent of things to come, and if not a “solution” to a problem that has seemed unsolvable for years, it’s at least a bold step in the right direction going further than anything has before.

If you want to see the slides, the presentation is here.

  1. David says:

    I have gone through the presentation, and it is a great presentation. I wish though that it would go into a little more detail on how it integrated with the likes of SpringSecurity/ACEGI, JAAS, and the like.

    I can see from the diagram that they say that it is an API that will sit in between these layers, but I guess I am looking for a little more information on how exactly this is achieved and if the API calls from within Spring will be intercepted by the ESAPI calls, or if no matter what framework you are using you must use the ESAPI directly, and then it will call the lower-level APIs.

    I can just imagine that there are alot of high-level API calls that do security at a lower level in spring, and that the ESAPI would need to be weaved in order to activate its code (probably through Aspect-Oriented Programming….I really should check and see if Aspect Software utilizes Aspect Oriented Programming, or if it is just a coincidence.) or if a Spring based application with ESAPI would leave a developer saying “Well, some of our application uses ESAPI, expect perhaps some Spring API calls that happen at a lower level that I don’t know about”

    Hopefully as I delve into it more, I will be able to answer my own questions.

Leave a Reply