What is the ESAPI?

It has been great to see so much buzz about the OWASP ESAPI in the tubes lately. It is very exciting for me to be involved in a project that has people excited and even more important it is fantastic to have people evaluating it and pointing out where it needs work. This is some of the most invaluable feedback a developer can get!

That being said, I have seen some questions floating around to the effect of "Why use ESAPI for authentication and access control when we already use *insert framework here*?"

This is a very valid question, and I think that some people may have gotten the wrong idea about what the ESAPI is really trying to accomplish.

There are some fantastic frameworks out there for logging, authentication, cryptography and all the things that the ESAPI does, and it is not the intention of the ESAPI to replace these frameworks, but rather to provide a central interface for developers to access the functionality of those frameworks in a simple fashion.

While we provide a reference implementation of ESAPI, a good deal of the code provided is to provide an example, or a plug and play environment for the ESAPI itself. It is not only intended but even reccomended that if you are using the ESAPI in a production application, that you use the pieces of the reference implementation that work for you, but also create wrapper objects to use your existing security controls through the ESAPI. This provides several things that are deeply important to having a secure application, especially in an agile environment.

1. Provides a standard and central API for developers to access security controls which makes the job of the developer simpler. If the developer knows that anytime he needs to log a user in he should call ESAPI.authenticator().login( request, response ) it makes it easier to remember and easy to implement.
2. Decouples the application from the security frameworks in use. This is probably the most important piece of the puzzle, at least in my mind. Things like access control checks, output encoding, and logging are sprinkled throughout the entire codebase of an application, which makes it a very painful process to migrate to a new framework if you ever need to. Imagine you have an application which consists of several hundred class files and and several hundred JSP files. One day you decide that you want to migrate from using Spring ACEGI to JAAS. You now have to change the code in every class file where you access that library to use the new library. If you were using the ESAPI, you would have a wrapper implementation of Authenticator and AccessController that delegated to your framework. Now you just have to write a new wrapper class and change a properties file and your job is done!

It has been said that ESAPI should be used to "fill in the gaps" where other security controls do not work, such as output and input encoding. I think that should be rephrased to reflect the Reference Implementation of the ESAPI and not the ESAPI itself.

That being said perhaps it would be helpful if there was an incubator project under the ESAPI umbrella that provided wrappers for the more popular frameworks. Having that could allow the developers have the ability to drop in the ESAPI then use wrapper jars as *plug-ins* to the API. So if you were using JAAS under the covers for your authentication and access control framework, you could drop in ESAPI.jar and ESAPI-JAAS.jar into your classpath, update your ESAPI.properties to use org.owasp.esapi.provider.authentication.JAASAuthenticator and you are off to the races.

What do you think?

More on Context Based Access Control

So I have been doing some thinking about how a good way to implement a context based access control system might look. The one thing that keeps breaking interface is how exactly does one define a context in terms of code. Then it came to me, what if context was not defined in terms of code at all, but was defined in terms of a natural parsable language?

Let's start at the beginning, first let's talk about what the interface for this CBAC might look like. Since my last post on this subject used java, I will continue with that language:

public interface AccessController {
   boolean hasAccess( User u, Request request, Context ctx );
}

Pretty simple interface I would say. And pretty self explanatory to boot. Now, to define the parameters. User is obvious, this is the user making the request. Request is the request itself and the pertinent details of the request. Context is the tricky one to define here, but perhaps the interface will make things a little clearer.

public interface Request {
   String getAction();
   Object getParameter(String key);
}

public interface Context {
   T getSubject();
   void setSubject(T);
   User getRequestOnBehalfOf();
   void setRequestOnBehalfOf(User u);
}

The Subject is a generic reference to the subject of the request. For example, the subject could be a Customer record or a MenuItem on the UI. You'll notice that I have also introduced the idea of performing actions on behalf of another user. This is something that I think is lacking from most AC implementations, and is something that is very important. To illlustrate let's take the example of a Medical Records System in a hospital. HIPAA places strict rules on who has access to a patients medical records. Although I am not 100% up on what all the rules around this are, let's say for example that only Patients and their physicians (any physicians that have seen the patient and thus added records) shall have access to that patients records. This is fine and great, but when a patient walks into the medical records department and wants their records, should we just have them sit down at the desk and fetch them by themselves? This is probably less than ideal. A Medical Records employee will probably need to get those records on behalf of the patient. Now, the flipside is that we don't really want to allow any old MedRecs employee to be able to pull up all the information about any patient at any time they want. So really what we need is a 2-tier access control check that not only checks the requesting employee is in medical records, and that the request is made on behalf of the patient; we also want to verify that the patient has indeed approved the request for the employee to access their records. So, perhaps there is an approval code, for simplicity sake, we will say it is the last 4 digits of the patients SSN, and for the Medical Records employee to access that patients records, the patient will have to authorize the transaction by entering the last 4 of their SSN on a keypad on the counter.

I dare you to show me a RBAC system that solves that problem. :)

This is where we get into the rules part of the system. This is the part that I am most excited about, as not only is it the most complex part of the system, but the answer is so simple. Let's dive right into it:

define action ACCESS_PATIENT_MEDICAL_RECORD {
   # The requesting user is one of the patients physicians
   User in Patient(Physicians) OR
   # The requesting user is the patient logged into the web access system
   User is Patient OR
   # User is a MedRecs employee on behalf of the patient with patient authorization
   (User on behalf of Patient AND User in Role(MedRecs) and Request(AuthCode) is Patient(AuthCode))
}

Kinda pretty isn't it?

While this is by no means the complete solution, I feel like it has promise as a system that is not overly complex to implement but allows the flexibility that a true CBAC needs to allow.

I would love to hear your thoughts on the subject, so share!

09 - The year of Toolz

I found myself using tools a lot more in my day to day job this year than I am used to. It is amazing how far some of the software breaking software tools have really come in the last few years. So that being said, I am going to focus on some of the tools that I have found myself using regularly.

Wireshark
Tried and true, Wireshark has been there for me, through thick and thin, since I got into this game long ago. I have used Wireshark for everything from dissecting RIP packets to troubleshooting TLS/SSL connection issues with SOAP Web Services. This tool is an absolute MUST HAVE for anyone in the security field. Be they hacker, hobbyist, or analyst - Wireshark will be one of your best friends.

Cain and Abel
It's interesting - I actually have a Windows XP VM that exists for no other purpose than to run Cain & Abel. This tool is invaluable when you need to capture network packets and have them analyzed and organized in real-time. It is great for sniffing out cleartext credentials (Telnet, FTP, SMTP), and one of the absolute best features is the ability to capture and essentially *bug* VOIP calls.

Metasploit
I remember when I first heard about MSF. I thought to myself, great, a new tool for Skiddies to annoy me with. At first glance it is nothing more than a glorified over-powered version of BO95. However, when you really dig deep under the covers, MSF is more like an IDE (that's Integrated Development Environment for you non-developer types) built specifically for hackers! It is a self-contained runtime where you can discover vulnerabilities and test exploits and shellcode all in a single environment. Really, this is an ingenius tool that's power far exceeds what most people are using it for.

JBroFuzzer
This has become one of the most used tools in my toolkit - I use JBroFuzzer against any new development in any of the applications that I maintain to test Regex patterns, request parameters, cookie values, and more than anything else, RESTful web services. It is amazing how many ways there are to break webservices and with some custom payloads and JBroFuzz you can create some very powerful scans that can be run against your app to dig out even the most obscure bugs that most ordinary testers would never think of.

JMeter
The quickest way to DoS your own application is by firing up a JMeter test. This is an extremely powerful tool from the Apache team that is written in Java. Load Testing, automated crawl tests, whitebox testing, and much, much more are possible with this extremely easy to use and powerful tool.

BurpSuite
The great thing about BS is it is an entire suite of tools that work together and allow you to run a quick (and surprisingly accurate) audit of an entire application. The interface is simple to use and most importantly, it is extendable. It is Java based so it is platform agnostic and works with any browser. One of the cooler features is the ability to suspend and save state then restore and continue later. Great stealth scanning feature.

There are other tools that I find myself using, but I use these almost every day, and absolutely use each extensively when doing an audit. Take this list for what it's worth, but if you haven't tried a couple of these, do yourself a favor and give them a shot.

Almost There - Sealed Objects in JavaScript

The last blog entry I wrote last week was a huge call out to anyone that could help me find the solution to the problem of writing secure objects is JavaScript. Unfortunately, the call went unanswered so I set out over the weekend to see if I could find the answer, and well, I haven't completely found the solution yet - but I am close.

Let me jump right into it:

Step 1 - We need to implement a "watch" function for browsers that don't support it

        Object.prototype.watch = function (prop, handler) {
            var oldval = this[prop], newval = oldval,
            getter = function () {
                    return newval;
            },
            setter = function (val) {
                    oldval = newval;
                    return newval = handler.call(this, prop, oldval, val);
            };
            if (delete this[prop]) { // can't watch constants
                    if (Object.defineProperty) // ECMAScript 5
                            Object.defineProperty(this, prop, {
                                    get: getter,
                                    set: setter
                            });
                    else if (Object.prototype.__defineGetter__ && Object.prototype.__defineSetter__) { // legacy
                            Object.prototype.__defineGetter__.call(this, prop, getter);
                            Object.prototype.__defineSetter__.call(this, prop, setter);
                    }
            }
        };

Step 2 - Now that we have that in place, we can create our seal method

        Object.prototype.seal = function() {
            for ( var e in this ) {
                this.watch( e, function(newVal,oldVal) {
                    var caller = arguments.callee.caller;
                    throw 'Attempt was name to alter a sealed object [' + this + '] from [' + oldVal + '] to [' + newVal + ']' + 'from [' + caller + ']';
                });
            };
        };

VIOLA!


That is it. This solution is currently working in FF3.5 and Chrome for Linux, I haven't gotten it to work at all in IE7 or 8 yet (Once again, thank you Microsoft) but I suspect once I throw this over the fence to some of the hardcore IE/Compatibility gurus at the office tomorrow, I will have the answer to that problem.

If you would like to see a working demo of this in action, you can checkout the demo page I put together for it at http://software.digital-ritual.net/js-secure-demo/.

I absolutely welcome any and all comments, and will test this out on more browsers as time permits tomorrow. Hopefully this could solve the problem, at least provided something doesn't stop the JavaScript RTE from running the Object.seal method on all objects that need to be sealed; but that is for load testing. For now this seems to be the best approach I can come up with.