What is the purpose of ESAPI?

Question

We use Veracode Static Code Analysis for finding and fixing code vulnerabilities. One reoccurring theme is, that they reference ESAPI as recommended solution for fixing them, such as CW117 (How to fix Veracode CWE 117 (Improper Output Neutralization for Logs))

However, I really do not understand the point of having a separate library that does nothing else but being some kind of security layer on top of other libraries. If a library (such as logging API) has a vulnerability, why would I use it in the first place? I would just contribute to that particular open-source community and fix the vulnerability there. Or use another library that could solve the very same issue but is already part of my dependencies. Yet, tools like Veracode recommend using it and don't have much flexibility in alternative solutions.

Answer 1

Let us have a common ground. In order to achieve that, we need to have some objective terms. So, instead of "purpose", I will focus on objective advantages.

Having a layer that protects you against some security issues reduces the reasons of worrying. You could of course write your own security protection layer, but that is time-consuming and due to that, in many business models it's not an option. So, let's see some scenarios:

Using an insecure library

You expressed that you would not like to use insecure libraries. However, a boss or some objective necessities might force you to do so. If you very much need to implement something ASAP and it would take a very very long time to implement it, yet, existing solutions might (!!!) have security issues, then you have to use them and since you do not know the exact implementation, it might have some security issues unkown yet and you might become the next big news of insecure project accidentally leaking out private information.

Writing code

While writing code you have a number of worries. If there is no layer above your code that secures your code, then you will constantly have to pay attention to ALL possible security issues that may arise from your code.

Accidental bugs

Some new developer in your team may make some mistakes, accidentally introducing security issues and an oversight by a reviewer may allow it to go viral. If there is no additional layer protecting against security-problems, then your project becomes unprotected.

Appearance of new kinds of security issues

If you have implemented your code and it was pretty much secure at the time of implementation, at some point a problem may arise which was either unobserved by the scientific community or non-existent. You will regularly need to review your code if it deals with sensitive information/resources to refactor wherever these new problems might apply. If there is a security layer above your code, then you may have the luxury of just downloading and installing a new version, or, occasionally contribute to it if it's open-source.

Responsibility

Would you like your person to be responsible of preventing ALL POSSIBLE KINDS of security issues? That's quite a large responsibility and necessitates a lot of knowledge and a lot of time/energy/money spent. And it will likely fail, because a single human is hardly capable of coping with everything. Instead, maybe you can deal with just the specific problems you think that these tools are not protecting against as they should and letting they do their job where they are effective.

Answer 2

I think @Lajos Arpad's answer should be accepted, but as I'm a co-lead on the esapi project I feel compelled to add my thoughts.

However, I really do not understand the point of having a separate library that does nothing else but being some kind of security layer on top of other libraries.

What about design patterns? So web applications as a whole operate on the Model-View-Controller design pattern, where your application logic is split (at least) into a data layer (Model) a presentation layer (View) and a business logic layer (Controller) that mediates between the other two pieces. This is extremely successful in the web as your View is a browser, the Model is your RDBMS or NoSQL platform, and the controller is the application code sitting on the server. That server code is usually further abstracted into an "ORM" layer (think Hibernate) that translates Java code to SQL code, and then say, ten years ago might also generate the view code as well. (Think GWT.) Nowadays the controller is mostly a RESTful web service that handles asynchronous requests from what I will call a "thick client" in the GUI. This MVC abstraction is already so ubiquitous that you might not realize that this is an abstraction!

At minimum, this allows you to neatly separate javascript code for the View, Java code for the server, and seperate database or ORM code for your Model.

Separating out a security layer creates a single layer in your application within the controller logic, that allows you to make security decisions as a programmer. But we usually separate things out further: Controllers usually rely on services: Those services are often needed by multiple parts of the application--so there's an abstraction right there. Security is one of those. You might also define a user service, a role service, any number of things common to represent a user interacting with your application.

Which leads into another point...

If a library (such as logging API) has a vulnerability, why would I use it in the first place? I would just contribute to that particular open-source community and fix the vulnerability there. Or use another library that could solve the very same issue but is already part of my dependencies.

This is wishful thinking. I'll get to why in a moment.

Yet, tools like Veracode recommend using it and don't have much flexibility in alternative solutions.

Well, because in Java-land there aren't any. There's a paid solution called HDIV. And that's about it. Some frameworks have integrated ESAPI as a security layer, if you only need output escaping there's the ESAPI Encoder project as well as the HTML Sanitizer project if you need to work with user-generated HTML. But log injection?

So ESAPI has its flaws. It's singleton-based. It's monolithic.

It provides encoding capabilities better served by the owasp-encoder project. It provides a mechanism with Antisamy to filter user-generated HTML tags. It has a software-based Web Application Firewall. (That from what we can tell, isn't used much if at all.) The validation framework is solid and has been used in other frameworks. Then there's the Auth API--which as far as we can tell has never been used by anyone, even as a reference toy application. Lastly there's secure logging, and this is where your criticism is well-deserved and has a lot of traction: It's basically an interface wrapping slf4j, which itself codes to yet another logging implementation of your choice. (You code to slf4j as an interface but swap in logging replacements underneath.) So this feels sketchy, and we recognized that in our internal development conversations. But there isn't (to my cursory knowledge sweep of 5min of google) a better replacement for the secure logging feature in 2021. On the particular issue you reference--CWE-117--the issue was then and still is now NOT the library as much as the bad practice of injecting unvalidated and unsanitized user input directly into the logs. ESAPI solves this problem in a way that Veracode was able to resolve by data flow analysis against the compiled binary. You could achieve this yourself, by copying what we do. The code is freely available.

ESAPI was originally designed to be a secure, emergency drop-in replacement library for applications that just paid the ultimate price--they got hacked. Hence the monolithic singleton design that will give you all functions even though you might only need one. That it became an OWASP flagship product and the de-facto choice of tools like Veracode is mostly an accident by virtue that ESAPI was (and still is) the only open-source java library that provided web security remediation techniques. I've described the few others.

As to whether this could have been designed better or differently, of course, but you're winding the clock back to 2008 at this point and have the liberty of hindsight. (None of the original developers work on the library, myself and one other developer maintain it now.)

Answer 3

I'm the other ESAPI project co-lead. I will try to add a few things to augment the information that @Lajos Arpad and @avgvstvs have mentioned.

If anything, your gripe should be with Veracode and Fortify and other SAST tools that only recommend ESAPI. It requires work on the part of those SAST tool vendors to have their tools remove their taint flags from certain vulnerabilities because the recognize that those libraries properly remediate. It takes a significant continued investment on the part of the tool vendors to do that.

That said, for the specific CWE-117, commonly referred to as "Log Injection", is generally considered a 'low' risk vulnerability so there are not a lot of other off-the-shelf FOSS logging libraries that care to address it. One could write a custom appender for whatever logging library that you are using to prevent Log Injection. As Matt mentioned, one could even more or less steal that code from ESAPI's GitHub repo. (ESAPI is licensed under the 3-clause BSD license, which is a very liberal license, so you wouldn't even have to contribute it back if you didn't want to.) But to my knowledge, there's no one else that bothered to implement this, and largely, as Matt explained, that's because it's really more of an application issue than it is a library problem. So for remediation of CWE-117, SAST tools may not have a lot of other options for Java libraries other than ESAPI. But for things like XSS vulnerabilities, they should at least also recognize the OWASP Java Encoder project. But if (say) Veracode doesn't do that, you may want to mention it to the vendor.