ESAPI 2.0GA IS RELEASED!

Friends, Romans, Countrymen - Lend me your ears!

It is my pleasure to announce the official release of ESAPI 2.0GA!

This release features some key enhancements over ESAPI 1.4.x including, 
but not limited to:

     * Upgrade baseline to use Java5
     * Completely redesigned and rewrote Encryptor
     * New and Improved Validation and Encoding Methods
     * Complete redesign of the ESAPI Locator and ObjectFactory
     * More unit tests
     * ESAPI Jar is now Signed with an OWASP Code Signing Certificate
     * ESAPI Jar is Sealed
     * And much, much more

We understand that a lot of you have been waiting a very long time for 
this, and so have we! It was important that we take our time with this 
release to make sure we had addressed everything possible prior to it 
going out. Included in that process was:

     * Peer review of the ESAPI Codebase
     * Code and Architecture Review of new Encryption
     * Adding and fixing unit tests
     * Tons of discussion and interaction with the OWASP Community and 
ESAPI Users

Without the feedback from our users, we could have never accomplished 
some of the awesome enhancements that have been made to the library 
since the last major release, so we owe you all a debt of gratitude for 
helping us design and implement controls that will ultimately help you 
write more secure applications.

We are currently in the process of getting a whole new suite of 
documentation, with a focus on integration tasks and actually using 
ESAPI in real applications - look for those documents over the next 
couple monthes, as well as a whole new contribs section in our 
repository aimed at providing turnkey components and solutions to some 
of the more commonly encountered integration points for ESAPI.

You can download the full distribution of ESAPI 2.0GA from our home on 
Google Code at:
http://code.google.com/p/owasp-esapi-java/downloads/list

The latest API Docs can always be found at:
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/index.html

Within the next 24-48 hours the distribution to Maven Central should be 
updated as well and you should be able to start using 2.0GA in your 
Maven projects as soon as that happens. Maven dependency will be:

<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.0GA</version>


As always, we would love to hear your feedback on the release and if you 
have any questions at all, you can join the ESAPI-User Mailing List here:
https://lists.owasp.org/mailman/listinfo/esapi-user

Thanks again to the OWASP and ESAPI Community for helping us build and 
release the tools that help make the internet just a little bit more sane!

Sincerely,
The ESAPI Development and Management Teams

P.S. Please forward this along to any colleagues or distribution lists 
that may be interested.

Firefox Plugins for Security Professionals - Top Ten for Twenty-Ten

Better late than never, is the saying I am searching for I believe. I have been slacking on this list for the last couple months, and now that it is nearly March I have decided I had better get off my dead (but very shapely) behind and get 'er done! So without further ado, the ever popular and still far better than any of Letterman's top ten lists - Top Ten for Twenty-Ten! *insert applause here*

10. iMacros
This plugin has absolutely nothing to do with security, however, it is all about automation these days - you can write handy macros to probe every page you go to for happy little bugs that you can later play with (responsibly, of course)

9. Tamper Data
Still among my favorite plugins. This is like having a version of WebScarab or BuRP right in your browser! Every request goes through this plugin and you can modify or alter each one on it's way to the server. Handy for bypassing those pesky client-side validations without having to disable JavaScript on the page.

8. Wappalyzer
Remote web app fingerprinting plugin that does a good job picking out what technologies web applications are using by analyzing the code for particular fingerprinting signatures. I haven't been using this for a terribly long time, but so far it beats the hell out of trying to manually determine the technology stack that an app is using.

7.JSONView
Very handy for inspecting what is *really* going on it AJAX applications. This prints out JSON responses in a very readable way. Pretty self-explanatory plugin.

6. Javascript Deobfuscator
Curious about what GWT is really doing in your JavaScript Engine? What to see how the Javascript Engine interprets a specific jQuery function? Needs to be able to monitor what obfuscated JS code is doing? Then this is the plugin for you. It slows down the JS engine *alot* - but it is far better than any other deobfuscator I have tired because it deals directly with the Javascript Engine!

5. Poster
Very handy little tool for playing around with RESTful web services. Far more intuitive than using Curl or writing custom clients to muck around with webservices.

4. Advanced Dork
Plugin to aid with the well-understood and vastly practiced art of Google Dorking. Do I really need to go into how useful this can be?

3. CryptoFox
Replacing both FireEncryptor and Leetkey this year is the *awesome* CryptoFox plugin which encrypts, decrypts, and even has a built in dictionary attack for MD5 passwords. Really, this is one of the coolest plugins I have seen to date for crypto related activities in the browser.

AES-256 (cryptofox)
uD5sTYKCgoI/cZ8YCOik9gnCWMS/qOR8grD4Kpez41WHIq5YPek+R/yiOKEKf/Q5Zu3SIXFlfD2QUaoxClzSFPTQue8qLogV7XEZypIQ9UzhX3n6zyXljGw=

2. FireQuery
Normally this would be listed in the same place as Firebug, however - this add-on add-on really, truly deserves it's own spotlight. With the popularity of jQuery on the web for doing, well, basically *everything* you can possibly do client-side - this greatly simplifies the art of discovering just where the developers did it wrong and find that DOM-XSS bug in their jQuery code! If you are testing rich-ui applications, this is a must-have.

1. The Firebug Family
Firebug is one of those truly interesting add-ons for Firefox that really became a platform unto itself. At some point, a bunch of developers decided that writing add-ons for the firebug add-on was more fruitful than writing add-ons for the host container, firefox. If you really need to know more about this plugin - just go click the link and read for yourself. This plugin is an absolute must-have for anyone who has ever come within 100 miles of security or development in their life. If you great uncle's wife's sister's dog's former owner happened to be a security guy, you had better have this plugin installed - or else the interwebz police are gonna come revoke all your internets and you won't be allowed to read my blog anymore.

So that's it for this years (last years) top ten - I hope to see this continue to be my most popular annual post, since I enjoy doing it so much and it brings lots of people to the blog to read my other really cool blog posts :)

CSRF - How much is enough?

One of the hot topics at AppSecDC this year seemed to be CSRF attacks and protecting against them. CSRF was brought up at least once in virtually every session that I attended at the conference (including several questions in my own ESAPI Presentation)

This spawned some great hallway conversations and got me really thinking about how we solve CSRF issues today. I kept coming back to an application I was working on recently that uses GWT and how I had to solve CSRF for that particular situation. See, normally the solution is to append a parameter on to the GET or POST request with a unique token that the server can verify against. Depending on who you talk to - sometimes this token has a lifespan of a session, and sometimes it is only a single request. Some would argue that for more sensitive applications you should use a per-request token and per-session tokens could be used in other places.

With that in mind, let's look at the GWT problem. You see in GWT, everything is handled by the Java -> Javascript compiler; which makes it very easy for Java Developers to create Rich UI Webapps. The flipside to this is that there is very little visibility (without a lot of research) into what is actually happening to your java code when you use GWT. Most developers just know that they put Java in and get a web app out.  This presents an interesting dillema for security in general, but specifically for things like CSRF and DOM Based XSS.

Google has posted an article all about securing GWT Applications - while I normally commend google on their suggestions as they pertain to security in software, I could not believe what they were suggesting as a solution to CSRF. The full article can be read here - but here is an excerpt outlining the proposed solution.

"A common countermeasure for XSRF attacks involves duplicating a session cookie.  Earlier, we discussed how the usual cookie-based session management model leaves your application open to XSRF attacks.  An easy way to prevent this is to use JavaScript to copy the cookie value and submit it as form data along with your XMLHTTPRequest call.  Since the browser's Same-Origin Policy will prevent a third-party site from accessing the cookies from your site, only your site can retrieve your cookie.  By submitting the value of the cookie along with the request, your server can compare the actual cookie value with the copy you included;  if they don't match, your server knows that the request is an XSRF attempt.  Simply put, this technique is a way of requiring the code that made the request to prove that it has access to the session cookie."

Wait... what?

First thought that popped into my mind when I read that (and maybe you had the same thought) was that the proposed solution of duplicating a session cookie doesn't solve the problem at all. I suppose this could be the case in a Framejacking CSRF Exploit, that this would solve that issue - but if I send a crafted link to a handful of users to their bank to transfer 1 million dollars to my account like:

"Dear Sir or Madam, I am writing you from EvilHacker Bank and Trust to let you know about a new policy regarding our interest rates - please click the evil link below to get pwned.

 http://evilbank.com/xfer?from=12345&to=12345&amt=1000000&forceApproval=1

Sincerely, 

Doctor Evil

EvilHacker Bank and Trust"

How does a cookie protect the user who is possibly already authenticated to the EvilHacker Bank application with a session cookie in their browser (and said duplicate session cookie). The browser is going to send both cookies because it does in fact, have access to them.

Well, that's completely unacceptable, I thought to myself. That doesn't protect the application or users of the application at all from CSRF. So I set out to come up with my own solution.

The answer, which turned out to be quite simple after a lot of research into how GWT builds in RemoteService interfaces and the javascript it uses to call services exposed to the client, was to make a slight modification to the ProxyGenerator (creates a Proxied implementation of the RemoteServiceAsync interface created by the developer). If you think of GWT Services in terms of RPC's this should make sense. I will likely post a follow-up detailing the solution and how to integrate it, but the meat of it is really this:

1. App Server needs a filter or some means to setup the session on the first request made to the application. This is standard CSRF protection behavior. 
1. Caveat with GWT - GWT generally uses static HTML files and the Javascript generally doesn't have any reference to any existing interpreted code (ie: JSP, PHP, etc.)  So the question became how do I tell the client application what the CSRF token should be. I chose to go with a cookie, but this could also be done as a separate RPC call to get the token (this presents it's own set of problems - they are not overcome-able) 
1. Created a filter (CSRFFilter) to generate a CSRF nonce when the session is created and set that as a cookie that gets sent back to the client. 
2. Client application reads the nonce from the cookie and alters the request to add a custom header containing the nonce. 
3. Server checks for either the presence of a request parameter or request header containing the CSRF nonce and verifies it against the value stored on the session (not in the cookie)
4. A new nonce is generated every time a new session is created.

So what does this really mean?

It means that since SOP rules won't allow a Java Applet (post 1.6 update 8) or Flash App (unless it is setup completely incorrectly) to make a cross-domain request - you are safe from the attack embedded in a flash or java applet, and since an e-mail client can neither predict the nonce, nor can it send request headers - you are safe from CSRF.

It also means that you cannot have entry-point actions in your application. So if your model is to allow people to accomplish some action by clicking a link from their e-mail - you will want to exclude that service from this solution (or just about any other CSRF protection - here you have are probably going to have to resort to a hash that can be calculated as your CSRF nonce, which still provides ample protection against most threat agents and situations, but is slightly less evil-hacker-proof then using something completely random)

Now on to the argument about sensitive data and the per-request token model. I think this is severely overcomplicating an otherwise simple and elegant solution. A distributed phishing style CSRF attack would have to not only count on a pre-authenticated session but would also have to predict the nonce (which is tied to the authenticated session) which while not completely impossible is so improbable that it equalizes the threat completely. In other words, with this solution - you may have a single successful attack inside millions of years (depending on the width and PRNG used to create the nonce)

The complexity introduced in managing a per-request model in an Ajax application becomes a nightmare full of bugs.

So, in summary - I contest that the per-request model of CSRF nonces is overcomplicated and a complete overkill in 99.9% of cases (there may be the small edge-case where this makes sense).

Remember, the more complicated a Security Control is - the more likely there is a bug in the control that can be exploited to circumvent it.

Cross Pollination; it's not just for bees...

While I was at AppSecDC 2010 - I got into a great conversation with John Steven from Cigital about a great number of things. One of those, and something that I have been openly preaching for years now, is the need for the developers and security professionals to start talking to each other, start interacting, and most importantly start teaching each other.

There are a select few people, like myself, that are kind of double-agents. I have spent the last 5 years as a Senior Software Engineer and I did security - now I am an Application Security Engineer and I do development. At no one point in time have I seen these as opposites, and I think they compliment each other quite well.

What I would really like to see in both communities is people branching out and not only learning but working to solve problems in both. Developers attending security conferences, giving talks at security conferences about subjects like agile/xp, build systems, continuous integration, frameworks, and writing good code - conversely security professionals at development conferences, giving talks on code review, security testing, tools and frameworks, and giving cool demos.

I have started to see this adopted slowly by both OWASP conferences and the NFJS tour. Uberconf had a day long track that was almost purely security related information - but we need more community involvement. It is hard to justify an entire track dedicated to development at an OWASP conference if there will only be 5-10 people attending it. It is up to the community to start expressing an interest in this concept of cross pollination.

I envision a conference with the following people attending:

* Developers
* QA Analysts
* Security Engineers
* Configuration Managers
* IT Managers

And the following tracks:

* Development and Architecture
* Offensive Security
* Defensive Security
* Metrics and Reporting

Moreover, I would love to see more coming out of these tracks then just a bunch of people sitting around talking. I want to see people actually working together to accomplish things. Presenters designing a project that can be done - or taking an existing project and working on it.

It's funny because almost every conference I have been too - I almost always think to myself, here we have a building with 100-200 of the smartest people in and we are missing the opportunity to build things - make cool new discoveries - and invent technologies.

After my conversations with John last week I am convinced that we can start to make some of these things happen and a couple of us have already taken the first steps in putting some pretty cool ideas together.

If you would like to see this happen too, raise your hand - we can always use more people in the community bringing in new voices and ideas.

Whats new?

So - as you may have noticed, it has been a while since I have posted on my blog. There is a good reason - a lot of things have been changing and there are lots of wheels and cogs spinning all over the place right now. But I do have some updates and now that the dust is starting to settle, I will have the opportunity to post more regularly again.

First order of business, after a great 5 years at ServiceMagic as a Software Engineer, I have decided to take the next step in my career and accepted an offer from Aspect Security. This actually occured over a month ago, but as I said - things have been a little crazy. My new official job title is Application Security Engineer, and I will be working on a lot of really cool things at Aspect Security. I am excited to see where my new path takes me and looking forward to becoming more and more involved in Application Security.

Next order of business, OWASP and specifically ESAPI. I was recently (along with Kevin Wall) promoted to be a Project Manager of the ESAPI projects - and I have set some pretty high goals for myself with the project. Some of these goals have already been realized, however, there is still a great deal to be done. Here is a high-level overview of some of the things that I am working on right now with the ESAPI project and some things that are done -

1. ESAPI distribution in Maven Central.

You may have seen my tweets regarding ESAPI now being available from Maven Central. This was a huge step for the team and something that was desperately needed. There are a lot of large projects out there using Maven for dependency management, and with the somewhat complicated footprint of ESAPI - it was a fairly painful process to get it integrated into large projects that were using Maven (or anything else that using Maven repositories)

Now, you can integrate ESAPI into your Maven project painlessly and without having to worry about manually managing the dependencies and deploying them into your local repository.

<dependency>
   <groupId>org.owasp.esapi</groupId>
   <artifactId>esapi</artifactId>
   <version>2.0_RC10</version>
</dependency>

Repository management has been graciously shared by Sonatype OSS.

2. Continuous Integration

I am currently working with the guys over Coveros on getting a public instance of SecureCI setup to handle our continuous integration needs. The instance will be hosted on Amazon EC2.

The idea behind this is that having continuous integration will solve 2 distinct problems with ESAPI:

1. Transparency
2. Regular Releases

Both of these topics are, IMHO, integral to the success of any open source software project of ESAPI's size. By using continuous integration we will be regularly running our full test suite against the ESAPI codebase (nightly) and making the results of those tests publicly available - thus addressing the concern of transparency. To address the concern of regular releases, the CI process will push a nightly snapshot of the ESAPI build to the Snapshot Repository on Sonatype.

3. Alignment of the API's

One other large undertaking is to get all of the various language implementations in-line as far as the API itself. The concept here is that I should be able to define a set of language agnostic tests that verify that an implementation of ESAPI conforms to the specification (which also needs to be defined in a cross-language format)

In the past, each language has implemented the ESAPI in whatever way they saw fit to do so - which worked well when ESAPI was still in it's infancy - however, as the project grows it is imperative that the interface be well defined and tests can be run against an implementation of a specific control to validate the control performs as expected. This will become increasingly important as the codebase continues to grow and users integrate the API with other frameworks and tools (Spring Security, Struts Validators, Siteminder Authentication, etc.)

4. Splitting at the seams

Another sensitive issue in the Java implementation is the footprint of the ESAPI. A great deal of implementers are using pieces and parts of ESAPI to solve specific problems, and as such there are a large amount of dependencies that are quite simply taking up space. I aim to split the ESAPI into it's core functionality that will consist of the interfaces designed to specification and what is considered to be the core functionality of the existing reference implementation - ie. Encoders, Validators, Logging, HttpUtilities.

As you can probably guess, none of these goals are small and quick to be realized and there are a lot of issues yet to be resolved in getting them implemented. I will be posting updates here as things come to fruition.

Last order of business - I was given the opportunity to present my talk on Solving Real World Problems with an ESAPI at AppSecDC last week and the reception of the talk was fantastic. I got some great feedback from people looking to use ESAPI for their clients and in their code and had some great conversations with people regarding where ESAPI is today and where it is going in the future. If you would like to see the slides (and video coming soon) of the talk - they are available from the AppSecDC Schedule Page.

That is all for now, but watch my Twitter Feed and blog for additional updates over the next several months!

There and back again

So you may have been wondering if I disappeared from the face of the planet for a while, or where I have been - well, I am still here and I have been extremely busy! Lots of things to share, both in development and application security. So I will jump right in!

At the beginning of the year I came up with a couple of goals that I wanted to achieve this year. The first of which was to speak at come conferences. I spoke at the Front Range OWASP Conference (FROC) at Auraria on June 2nd. It was a great experience, despite the technical difficulties incurred midway through my demo and now I am hooked.

I presented on using the OWASP Enterprise Security API to solve REAL WORLD security problems. The presentation was very well received and I got some great feedback from those in attendance. My presentation slides and video are available on the OWASP FROC Site and I encourage anyone to take a look at the slides and video and let me know what you think.

In addition, just this week I was at The Uberconf where I had the opportunity to co-present with Ken Sipe on both Security Code Review and the ESAPI. Needless to say I am pleasantly exhausted from the 4-day onslaught of talks and workshops that was UberConf.

The second goal I set was to start a book - and I will be using my blog as a venue to test run some ideas that I have for the book. It will be on Application Security - specifically aimed at software developers. It may or may not feature the ESAPI, but you can be assured I will be using the ESAPI in examples code samples.

I am hoping to speak at AppSecUS 2010 in September, will be attending DefCon in LV for the first time - hanging with the DC303 Crew, and am submitting to do an ESAPI BootCamp at AppSec DC and AppSec Brasil.

So as you can tell, it has been very busy.

I will begin a new series to test-run for the book called Secure Development Recipes (working title) sometime in the next week or two, so look for those here.

More to come soon! Time now for some sleep!

ESAPI4JS - v0.1.3 Now Available

The newest installment of the ESAPI4JS is now available! In light of that, I decided it may be helpful to throw out some examples of how this framework can be used to help protect clients from browser based attacks like DOM Based XSS, and how the API could help to provide some additional client side security.

First let's take a look at the biggest benefit to using ESAPI4JS - The ability to mitigate client-side DOM Based XSS attacks. This is something that no other framework that I am aware of is yet to tackle, and as such, I think that we will begin to see this vector being exploited more and more in the wild.

Let us start at the beginning.

What is DOM Based XSS?

Who better to answer that question, than the experts at OWASP?

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. That is, the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. - OWASP

The most common type of vulnerable code that this affects is code which uses the information that is in the window.location global object.

Let's work through an example of the vulnerable code, and how it could be mitigated using ESAPI4JS.

<html>
<head>
   <title>My Vulnerable Webpage</title>
   <script type="text/javascript">
      var getParameter = function( name ) {
         var startIdx = window.location.href.indexOf( name ) + name.length + 1;
         var endIdx = window.location.href.indexOf( '&', startIdx );
         if ( endIdx = -1 ) endIdx = window.location.href.length;
         return window.location.href.substring( startIdx, endIdx );
      }

      var firstName = getParameter('firstName');
   </script>
</head>
<body onload="function(){document.getElementById('nameplace').innerHTML = firstName; }">
  <h1>Hello <div id="nameplace"></div>, Welcome to my Vulnerable Page!</h1>
</body>
</html>

If you were to hit this page with the following URL: http://host.com/vulnerable.html?firstName=Chris

The resultant page would display: Hello Chris, Welcome to my Vulnerable Page!

However, what if you were to hit this page with a URL that looked like: http://host.com/vulnerable.html?<sript>alert('xss');</script>

You guessed it! You will get a pretty little popup. So what you say, server-side XSS controls can mitigate that risk easily, and you would be correct, however, what if the url looked like this: http://host.com/vulnerable.html#firstName=<script>alert('xss');lt;/script>

If you said that server-side mitigation wouldn't catch this, you are right! When a browser sends a request to the server, anything after the '#' is not sent as part of the request, as this is meant for browser control to jump to an anchor in the page.

So how do we fix this problem? Simple with ESAPI4JS - the page could be rewritten as follows:

<html>
<head>
   <title>My Vulnerable Webpage</title>
   <!-- Dependencies -->
   <script type="text/javascript" language="JavaScript" src="/js/esapi4js/lib/log4js.js"></script>
   <script type="text/javascript" language="JavaScript" src="/js/esapi4js/resources/i18n/ESAPI_Standard_en_US.properties.js"></script>
   <script type="text/javascript" language="JavaScript" src="/js/esapi4js/esapi.js"></script>
   <script type="text/javascript" language="JavaScript" src="/js/esapi4js/resources/Base.esapi.properties.js"></script>
   <script type="text/javascript">
      org.owasp.esapi.ESAPI.initialize();
      var firstName = $ESAPI.httpUtilities().getParameter("firstName");
      try {
         // Will throw an exception if there are multiple encodings in the value
         firstName = $ESAPI.encoder().canonicalize(firstName);
      } catch (e) {
         $ESAPI.logger('VulnerablePage').warn( org.owasp.esapi.Logger.EventType.SECURITY_FAILURE, e.getLogMessage() );
         alert( e.getUserMessage() );
         firstName = 'Guest';
      }
   </script>
</head>
<body onload="function(){document.getElementById('nameplace').innerHTML = $ESAPI.encoder().encodeForHTML(firstName); }">
  <h1>Hello <div id="nameplace"></div>, Welcome to my Vulnerable Page!</h1>
</body>
</html>

We have successfully mitigated DOM Based XSS attacks against our vulnerable page. Of course, in the real world, the vulnerable code will not be *quite* as obvious in most places, but the resolution is still the same.

Let's move on to the next piece, using ESAPI logging. You probably noticed the call in the above section of code to $ESAPI.logger

There are a few things to deal with when setting up logging for ESAPI4JS. The first is to pick your Logging framework. The Log4JS framework is used by the Reference Implementation and so that will be used for the first part of this demonstration. A subsequent blog post will discuss how to implement other logging frameworks into your ESAPI.

The first step is to setup your logging configuration. For the purposes of this example, we will only be setting up a single logger, and we will continue to use our vulnerable.html example from above. Without further ado:

Base.esapi.properties.logging["VulnerablePage"] = {
    Level: org.owasp.esapi.Logger.ALL,
    Appenders: [ new Log4js.AjaxAppender('/jsLog') ],
    LogUrl: true,
    LogApplicationName: true,
    EncodingRequired: true
};

// Since we specify that we want the application name logged in our configuration, let us give our application a name:
Base.esapi.properties.applicaton.Name = 'Vulnerable Application'; 

Now this will POST your log entry to the path /jsLog which should be mapped to some handler servlet or php controller on the server side. More details on using this appender can be found here

Now any calls to $ESAPI.logger('VulnerablePage') will go to this logger.

There are six methods for logging (trace, debug, info, warn, error, fatal) each with the signature .method( org.owasp.esapi.EventType eventType, String message, Exception exception );

You can define custom event types by instantiating new instances of the org.owasp.esapi.Logger.EventType class or reference the static predefined events

• org.owasp.esapi.Logger.EventType.SECURITY_FAILURE - Used to log when something fails to pass a security control
• org.owasp.esapi.Logger.EventType.SECURITY_SUCCESS - Used to log when something passes a security control
• org.owasp.esapi.Logger.EventType.EVENT_FAILURE - Used to log when something fires an event, and that event does not complete successfully.
• org.owasp.esapi.Logger.EventType.EVENT_SUCCESS - Used to log when something fires an event, and that event completes successfully.

Creating a custom EventType is simple.

var customEventType = new org.owasp.esapi.Logger.EventType( "Custom Event", false );

// ... later

$ESAPI.logger('VulnerablePage').info( customEventType, "Something happened!" );

HTTPUtilities

The HTTPUtilities object is meant to provide shortcuts for doing common tasks that have to do with the browser and the response. Right now, the available methods are:

• addCookie( org.owasp.esapi.net.Cookie cookie )< - Adds a single cookie to the cookie jar/li>
  
• getCookie( String name ) - Gets the String value of a cookie



• killCookie( String name ) - Deletes a cookie if it exists in the current cookie jar



• killAllCookies( String name ) - Removes all the cookies from the current cookie jar



• getParameter( String name ) - Gets the value of a parameter on the URL

This should be enough to get you started using ESAPI4JS. I will make a seperate post at a later time going over the i18n framework.

Enjoy and feel free to share comments!

ESAPI4JS - The new hotness!

So I have been hard at work on the ESAPI4JS code for the last couple of weeks, and have gotten it to a point where people can start to play with it. It will be in alpha for a bit yet, as not all the functionality is there, but here is a little of what you can do with it so far.

Download the script(s)
http://owasp-esapi-js.googlecode.com/files/esapi-compressed.js
http://owasp-esapi-js.googlecode.com/files/esapi.js

Import the Compressed or Uncompressed JS File on your page

<!-- Uncompressed Version -->
<script type="text/javascript" language="JavaScript" src="esapi.js"></script>
<!-- Compressed Version -->
<script type="text/javascript" language="JavaScript" src="esapi-compressed.js"></script>

Initialize the ESAPI

$ESAPI_Initialize();

Do some cool stuff!

var val = "<div&gt;Test</div>";
alert( $ESAPI.encoder().encodeForHTML( val ) );
try {
   alert( $ESAPI.encoder().canonicalize( val ) );
} catch (e) {
   alert( e.getUserMessage() );
}

I should be getting some documentation written up this weekend that explains how to configure the ESAPI for JavaScript and how to use the functionality that is complete.

In the meantime, you can see the source for the ESAPI4JS Encoder which is fully implemented.

If you are interested in getting involved in the project, shoot me an email and we will see how you can help out!

Development conversation about the ESAPI happens on the esapi-dev mailing list

User support is available on the esapi-user mailing list.

Firefox Plugins for Security Professionals - Best of 2009

Due to the overwhelming popularity of my first post back on my old blog called "Firefox Plugins for Security Professionals" ( apparantly it was even referenced in a book called 'Dissecting the hack: the f0rb1dd3n network' ) I have decided to put together a new list, highlighting the best security related plugins from 2009.

10. Fire Encryptor
The only reason this one isn't higher on the list is because it hasn't been updated to work with Firefox 3.5. However, it allows you to do quick realtime encryption, decryption, and hashing in your browser. Among the really useful scenarios where this comes in handy is when you are accessing a sensitive application on the web. You can enter a password that you will remember into the plugin, hash it, and use the hashed version of the password to login to the site.

9. Leet Key
Similar to Fire Encryptor, only this allows you to do realtime conversion to ROT13, BASE64, HEX, and URL encoded strings. Invaluable when working with injection attacks and trying to bypass filters in an application. For fun it also will convert any text into l33tspeak, morse code, binary, all upper, all lower, and BIN - as well as do simple DES encryption.

8. Tamper Data
Extremely useful plugin that allows you to tamper with a request just before it is sent to the server. Allows such useful things as changing headers (for request splitting fun), modifying POSTed parameters, adding parameters to a POST, adding/removing headers and other such goodness. You can guarantee that the bad guys are using this plugin, so you better be too!

7. ShowIP
Handy little plugin that displays the IP address of the server that you are actually on in the lower right hand corner of the browser status bar. Allows quick one-click access to whois data as well as the ability to copy the ip address to the clipboard for a quick paste into your favorite port-scanner.

6. Passive Recon
This is probably one of the most complete information gathering plugins that has ever been for a browser. A right click context menu allows you to find a wealth of useful and useless information about a target server. You can discover public services available on a server, all servers in the domain, what architecture the server is using, what commonly used ports are open, and a good deal more.

5. Hackbar
A CLI type interface for messing with URLs. This toolbar is mainly aimed at discovering SQL Injection flaws, but also has several built-in macros for XSS, Encryption, and Encoding flaws as well. Any serious analyst or security-focused developer should definately have this little gem in their toolbox.

4. Torbutton/FoxyProxy
Oldie but goodie! While the TOR network is by no means perfect for anonymizing internet traffic it is light years ahead of most every other easily accessible anonymyzer. TOR is one step down from a pwn'd proxy chain (although it is a very big step down) and although it is generally slower than molassis, if you are stealth scanning an application, it is extremely powerful and easy to use.

3. UrlParams
A quick easy access sidebar plugin that gives you complete access to all the POST and GET parameters on a request. Probably the most useful feature is the ability to replay a modified request to a new tab. It also gives you quick access to the referer header for black-hat SEO spamming if your into that kind of thing.

2. Web Developer
This plugin is an absolute MUST-HAVE for anyone using firefox to break applications. It puts a wealth of information about the current page at your fingertips. If you haven't seen this plugin you have probably been living under a rock for the last 5 years.

1. Firebug/Firecookie
Still at the #1 spot for the third year running is the Firebug plugin. Teamed up with Firecookie there is virtually nothing you can't do to a running webpage. Debug the javascript served from the server to find exploitable bugs, grep all the in memory javascript for evals, examine ajax requests and responses, monitor load times for time-based attacks, and on and on and on. Like the web developer plugin, if you have heard of at least firebug, chances are you have been living under a rock for the last few years!

That does it for my 2009 list. And they are all available as a collection from my shared collections on the Mozilla Add-Ons site:

Best of 2009 - Security Plugins

What are your favorite plugins?

A new type of security testing...

I am not sure if this is really a new idea, it probably isn't, but I haven't seen anything in the tubes about it and it is a concept that I have been slowly rolling around my brainpan while working on the ESAPI.

When we write unit tests for ESAPI, what we are doing is giving the API inputs and looking for the correct outputs, or looking for an exception. This is nothing new, this is what unit testing is really all about - but it is all based around business functionality.

My idea is to take that idea, of testing business functionality and apply the same philosophy to a new set of test cases.

Traditionally, there are 3 main types of assessments of an application to uncover security flaws:

1. Vulnerability Scanning: This is usually the first step in an application assessment. It generally consists of an automated scanner, such as Nessus. If the assessment is being done by someone competent, it will also include a manual review of the site. The problem with vulnerability scanners is they are really good at finding the really obvious flaws, but they have no context to the application. The only way to do a full assessment of an application is to sit down in front of it and try everything you can to break it by hand.
2. Static Analysis: There are some great static analysis tools out there that are great at finding common coding errors that lead to security flaws. For Java there are things like FindBugs and PMD. There are also services online that will scan the code in your repository for security related code issues. These can find some bugs that would otherwise be very difficult to find, but require a lot of tuning to limit the number of false positives that are reported.
3. Manual Code Review: If you come into an existing application that already has an existing codebase, this can be one of the most daunting tasks you will ever encounter. Especially if you come into a codebase that has had a lot of hands in the pot (so to speak) with a lot of different coding philosophies. This process is exactly what it sounds like, sitting down in front of the code and analyzing every line of it looking for coding errors and bugs. To date, this is the most effective form of assessment, but it is rare for everything to be caught unless this process is implemented by a very good developer or architect from day 1 of coding.

What I am proposing is using the concept of automated integration testing in the runtime by writing code to test your code for security vulnerabilities.

Imagine the following situation. You have a simple guestbook web application. The application consists of a single JSP file, a servlet and a facade that sits in front of a DAO. Let's illustrate this with some pseudo-java below.

Value Objects to represent the data

public class Entry implements Serializable, Comparable<Entry> {
   private long id;
   private String message;
   private String fromName;
   private String fromEmail;

   // ... declare getters and setters
}

Data Access Layer

public interface GuestbookDAO {
   List<Entry> getEntries() throws DAOException;
   void saveEntry(Entry entry) throws DAOException;
}

public class MySQLGuestbookDAO implements GuestbookDAO {
   public List<Entry> getEntries() throws DAOException {
      Connection con = null;
      try {
         List<Entry> entries = new ArrayList<Entry>();
         con = JDBCHelper.getConnection();
         Statement st = con.createStatement( "select * from entries" );
         ResultSet rs = con.executeStatement();
         while ( rs.next() ) {
            entries.add( new Entry( rs.getLong(1), rs.getString(2), rs.getString(3), rs.getString(4));
         }
      } catch (Throwable t) {
         throw new DAOException(t);
      } finally {
         if ( con != null ) con.close();
      }
   }

   public void saveEntry(Entry entry) throws DAOException {
      Connection con = null;
      try {
         con = JDBCHelper.getConnection();
         PreparedStatement st = con.createPreparedStatement( ... );
         // ... standard jdbc code
      } catch (Throwable t) {
         throw new DAOException(t);
      } finally {
         if ( con != null ) con.close();
      }
   }
}

public class GuestbookDAOFactory {
   public static GuestbookDAO getDAO() {
      return new MySQLGuestbookDAO();
   }
}

Facade

public class GuestbookFacade {
   private GuestbookFacade() { /* Singleton */ }
   private static final GuestbookFacade myInstance = new GuestbookFacade();
   public static GuestbookFacade getInstance() { return myInstance; }
   private static final Logger log = Logger.getLogger( GuestbookFacade.class );

   private final GuestbookDAO dao = GuestbookDAOFactory.getDAO();

   public List<Entry> getEntries() {
      List<Entry> out = new ArrayList<Entry>();
      try {
         out = dao.getEntries();
      } catch (DAOException e) {
         log.error(e);
      }
      return out;
   }

   public void saveEntry(String message, String fromName, String fromEmail) {
      Entry entry = new Entry( message, fromName, fromEmail );
      try {
         dao.saveEntry(entry);
      } catch (DAOException e) {
         log.error("Unable to create entry: " + message + ", from: " + fromName + "<" + fromEmail + ">", e);
      }
   }
}

Controller

public class GuestbookServlet extends HttpServlet {
   public void doPost(HttpServletRequest req, HttpServletResponse resp) {
      String action = request.getParameter( "action" );
      if ( "SAVE".equals( action ) ) {
         String message = request.getParameter( "message" );
         String fromUser = request.getParameter( "fromUser" );
         String fromEmail = request.getParameter( "fromEmail" );
 
         GuestbookFacade.getInstance().saveEntry( message, fromUser, fromEmail );
      }

      List<Entry> entries = GuestbookFacade.getInstance().getEntries();
      request.setAttribute( "entries", entries );
   }
}

View

<html>
<head><title>Guestbook</title></head>
<body>
   <%
      List<Entry> entries = request.getAttribute( "entries" );
      for ( Entry e : entries ) {
   %>
   <div class="entry"><%= e.getMessage() %> - From <a href="mailto:<%= e.getFromEmail(); %>"><%= e.getFromUser() %></a>
   <%
      }
   %>
</body>
</html>

This is a very basic application (that is full of security flaws I might add, but we will ignore that little tidbit for now and let our test catch them) that we will now write an example SecurityTestCase for.

public class SecurityTestGuestbook extends TestCase {
   private MockHttpServletRequest request;
   private MockHttpServletResponse response;
   private HttpServlet servlet = new GuestbookServlet();

   public void setup() {
      request = new MockHttpServletRequest();
      response = new MockHttpServletResponse();
   }

   public testSQLInjection() throws Exception {
      final String[] injections = new String[] { "' or 2=2--" };
      request.initialize();
      response.initialize();
      request.setParameter( "action", "SAVE" );
      request.setParameter( "fromUser", "Beef" );
      request.setParameter( "fromEmail", "email@domain.com" );
      for ( String test : injections ) {
         request.setParameter( "message", test );
         try {
            servlet.doPost( request, response );
            fail("No exception thrown - SQL Injection Possible" );
         } catch (Throwable t) {
            // Success
         }
      }
   }
}

This is just a single quick example, but it illustrates the point nicely. We will leave verifying functionality works to our standard unit tests, but write another test suite specifically to test your security controls. You should probably have more granular tests that just testSQLInjection - maybe testRequestSQLInjectionMessage, testRequestPersistentXSSMessage, etc.

I would love to hear what people think about this as a development concept, especially those who work in TDD and Agile environments. I would also be interested to hear from people who have used some of the macro based front end testing tools to see if they have created similar view test suites.

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!

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.

JavaScript? Hello? Is anyone there?

So I am still in the architectural design phase of ESAPI4JS, and have come across an interesting problem. Well, to be honest, there are lots of problems with JavaScript and trying to make it secure - but there is one that I have yet to find a way to overcome. This, in my opinion, is one of the biggest shortcomings of JavaScript that I have encountered to date.

On with the problem...

Say that you have a class that you are creating with JavaScript. You want to ensure that the "private" methods and properties of that class cannot be altered by code running in the same window.

This is a relatively trivial thing to do in javascript using closures:

var MyUnchangeableClass = function(){
   var MyUnchangeableClassImpl = function() {
      var _myPrivate = "Private";

      return {
         getPrivate: function() {
            return _myPrivate;
         }
      };
   };

   var _singletonInstance = new MyUnchangeableClass();

   return {
      getPrivate: function() {
         return _singletonInstance.getPrivate();
      }
   };
}

var unchangeableClass = new MyUnchangeableClass();
alert( unchangeableClass.getPrivate() ); // alerts 'Private'

Using a closure like this creates an interesting scoping situation where the property _myPrivate is locally scoped to the constructor and the 'Object' being returned by the function thus privatizing it both from the global scope and the scope of the closure itself. This scoping situation is called Closure Scope.

This is all fine and great, however, the top level globally scoped reference is always vulnerable to be altered. For instance, we know now that calling getPrivate() on the instantiated closure object will return the innermost value which happens to be "Private", but what happens if I alter the outermost globally accessible reference like this:

unchangeableClass.getPrivate = function() { return "Overwritten"; };
alert( unchangeableClass.getPrivate() ); // alerts 'Overwritten'

We have effectively subverted the entire point of the closure by substituting what the outermost function actually does (coincedentally, the references to anything Closure Scoped will disappear in this case as well, and will be ultimately GC'd, effectively removing the data from the Runtime entirely)

The one thing that is truly holding JavaScript back from being a language that has any hope in a secure world is the fact that there is NO RELIABLE way to SEAL an object. In Java, you can make a class final to ensure that the class cannot be extended to alter it's behavior, you can make properties and methods private to ensure that their behavior and values cannot be altered. There are similar strategies in just about every language that provides OOP or OOP-Like functionality (even PHP!).

I have come up with some somewhat hacky ways to accomplish this, but they can all be subverted by other code running the same runtime. I have even thought about creating a trusted JS plugin for browsers that basically keeps the JavaScript inside a sealed/signed jar after it has been downloaded (so processes outside of the browser cannot modify the cached javascript) and having the initial javascript source tell the plugin which object should be sealed, then have the plugins use the underlying C API to ensure that they cannot be changed. This is a huge undertaking and frankly is open to a ton of potential attacks.

The idea behind the ESAPI4JS library is good - basically providing end users with protection from server side code that has been compromised as a second level of defense. This is something that I think will become increasingly important as time goes on, but without the ability to create secure JS code that cannot be altered, it simply won't live up to it's full potential.

It will provide a second level of defense that can ultimately in most cases still protect the end user, afterall, the code to subvert the server-side code will be the main focus of the nefarious individual doing so, and they may not even realize that there is another layer of protection against potential front-end victims that also needs to be subverted.

I still think it is a great idea, and am excited to see where it goes, but I throw this out to the JavaScript community as both a challenge and a plea. This is something that JavaScript sorely needs (I am sure most JS library writers will agree) and the only way that we will ever see it is if the community demands it.

So Testify! To Securify!

Onward!

GET vs POST in Java Servlets...

This is an issue that has come up many times before, and something that really grates on my nerves as a developer and makes the appsec part of me angry. If you have developed Servlets in Java you may or may not be aware of a design issue in the way HTTP Requests are processed. Here is the issue.

Data from the query string and the post body are aggregated into the request parameter set. Query string data is presented before post body data. For example, if a request is made with a query string of a=hello and a post body of a=goodbye&a=world, the resulting parameter set would be ordered a=(hello, goodbye, world).

So what is the issue here? It is quite simple really, if you POST to a Servlet it should ONLY return the value(s) for the parameter that were part of the POST Request, ignoring the GET values! The same is true for the opposite.

Even PHP has gotten this right by seperating parameters out into the $_POST and $_GET globals (the use of globals here is a whole seperate issue)

So why is this a big issue? Well for one, it makes it much easier for would-be hackers to try to do mean things to your application. There are lots of reasons that this is a bad idea, but the main one is that when you are posting parameters to a servlet, a great deal of the time, you are posting operational information, which can be changed by adding a GET parameter to the URL, maybe. And that's the kicker, you really have no idea whether the parameter(s) you are looking at were passed in on the URL or were part of the POST without additional work.

I suppose there are ways around this that could be implemented into a wrapped request, but he fact of the matter is that this is something that absolutely should be part of the spec. It is no secret that a lot of people want this to be added, and frankly it really irritates me that the community has not listened to the user base in the respect.

Invocation is E.V.I.L., Mmkay?

This post is especially for anyone using Apache Tomcat for their application server. Today we will be discussing the EVIL InvokerServlet. What is so evil about the InvokerServlet? I mean it ships with Tomcat and has for a long time?

Let's analyze that question for a second. If you're like me, you have seen a lot of sci-fi and fantasy movies. I can think of very few examples where something being invoked was a good thing. As a matter of fact it is almost always the bad guys doing the invoking and they are almost always trying to do so to undermine and take over the world, or some other nefarious purpose in line with that.

So what does that have to do with Tomcat?

invoke (synonym: conjure)

to call forth by incantation

Let's apply this to Java:

invoke (synonym: conjure)

to call forth by FQN (Fully Qualified Name)

This is what the InvokerServlet allows you to do. By itself, in a controlled environment, it is not such a bad thing. But this is a servlet, which means, when enabled, is accesible to the entire internet, good guys and bad guys alike. All they need to do is discover the incantation, or in this case the FQN that need be uttered or passed in to make things happen.

Say for example you have a page on your site that contains a form that submits to a servlet by way of the invoker servlet. This code looks like this:

<html>
<head>
<title>This is the secret incantation page</title>
</head>
<body>
<form action="/servlet/com.yoursite.servlets.DoSomethingServlet" method="POST">
<!-- Form Elements go here -->
</form>
</body>
</html>

Any bad guy who has discovered the Right Click -> View Source option in every browsers context menu will be able to discover the secret incantation to invoke something which may be innocent enough. However, what this tells the attacker more than anything is that in your universe (website) he can learn all the secrets of your universe by trying different incantations.

Now, let's take this one step further and let's invoke the power of Google (God of the land of Search) to see what universes will easily allow us to start trying out some incantations.

Google Dork: inurl:servlet/com

Of course you can try this with net.*, org.*, or any other package descriptors you can think of. The sheer amount of results of people that are doing this and allowing this to happen are crazy.

So we still haven't really seen anything "dangerous" yet, you might be saying to yourself at this point. Well, actually you have. I have already demonstrated that you are exposing the internal structure of your source code by simply being forced to reference a class by it's FQN in a manner that is publicly accessible.

Things get even more interesting when you start tuning your query a little bit to get you more interesting results.

Google Dork: inurl:servlet/com +admin

Wow, that definately gives you some interesting stuff. Including the direct paths and information required to get admin access on a couple of sites, database usernames and passwords, and the aforementioned structure of your source code.

So let's keep going with this. Maybe using the invoker servlet, I can try to load a class that isn't a servlet at all, rather is just a POJO that lives in the classpath somewhere. To test this theory, let's try to load something that we know exists.

Url: http://hax0r-universe.org/servlet/java.lang.Object

Well, it tried to load and run the class as a servlet... Isn't that interesting. I wonder if what happens if I try to access something that I know isn't an object.

Url: http://hax0r-universe.org/servlet/java.lang.SecretIncantation

Hey, look at that, we got a 404 back from the server instead of the 500 we got when we tried to load a valid object that wasn't a Servlet.

Things are getting interesting now. I wonder if we could fingerprint and detect what libraries are running in the app server. Let's pick something that almost every application uses. Let's experiment with a Log4J class.

Url: http://hax0r-universe.org/servlet/org.apache.log4j.Logger

Hey! It tried to load it! Awesome!

I wonder if evilsite uses the version of <Insert Library Name Here> that had that really cool Buffer Overflow Vulnerability that let's me execute arbitrary code and get a shell to the server!

You see where this is going.

Using the invoker servlet opens your entire JVM to the world for discovery and probing. A dictionary powered crawl could provide a map of your entire source code tree. A vulnerable library could be exposed providing a mechanism for the bad guys to use to find that security hole in your otherwise inpenetrable fortress application. The possibilities here are endless.

So, why, after all of that, does the Apache Crew refuse to do away with the Invoker Servlet? I can't pretend to know the answer to that, but I can tell you that by default, there is no *explicit* mapping to the InvokerServlet (it is commented out in $TOMCAT_HOME/conf/web.xml) but there are a significant number of people that are uncommenting it to use it in their apps.

This is bad, mmkay. So let's stop the madness. If you are using the InvokerServlet, it is time to get over the lazyness of not adding explicit mappings to your servlets and get rid of it!

On a side note, I am investigating the possibility of including a SecureInvokerServlet (if such a thing could even be written) for inclusion in the ESAPI that provides the same kind of functionality but adds in the required Access Control, Path Whitelisting, and basic security controls that the standard InvokerServlet that ships with Tomcat lacks.

Update 1 - A good followup read is the Securing Tomcat page at OWASP

Is Role Based Access Control dead?

This question has been coming up a lot in different circles lately and it seems like there isn't a great deal of online buzz or conversation about it, so I would like to bring it to the online collective for discussion and debate.

I have contested lately that RBAC (Role Based Access Control) just flat out doesn't work in today's world. There was once upon a time, when applications were much simpler that this concept fit very well in the application security world, but we no longer live in that world.

The problem with RBAC is that it is a big hammer. It is what I like to refer to as an all-or-nothing solution to a problem that deserves a much finer grained answer. To elaborate on this, let me first explain the concept of RBAC.

1. Applications have users.
2. Users need to be be able to perform actions.
3. Actions are associated with Roles that are allowed to perform said actions.
4. Users belong to one or more Roles.

This is a very *simple* solution to the problem of access control in an application, and in simple applications, it works quite well. RBAC is widely supported by vendors and comes built in to most web application containers. It also happens to be the access control mechanism used by most OS vendors (Replace Role with Group and Voila!). There are tons of implementations for J2EE applications such as Spring ACEGI, JAAS, etc.

When you want to check if a user can perform some action you simply use a quick check

   if ( user.isInRole( Roles.ADMINISTRATOR ) ) {
      doAdminStuff();
   }

So what is the problem with this simple, widely supported, very popular means of access control? It's simple really, RBAC has no awareness of the context request for access.

To illustrate this point, consider the following situation.

You have just completed coding a wonderful project management application for Big Humungous Inc. that filled all the requirements, is unhackable, and even has a list of features far exceeding the clients requests. One day you recieve a call that your client is creating a special group of representatives that need to have administrative access to customer accounts that belong to Group A between 2pm and 3pm every Monday, Wednesday, and Friday.

Now you have a problem. A role is an all-or-nothing access mechanism. So you can't just add the users to the Administrator Role, so your only option is to go back into the code and add a new check in the code that says am I in this role, and do I meet all these other requisites to do the requested action. Then you need to implement that code in every place where you would normally ask is the user an administrator?

Now let me introduce to a different approach to Access Control. It goes by many names. Some call it Activity Based Access Control, I call it Context Based Access Control. The concept is simple.

Make your Access Control mechanism aware of context!

There are any number of ways to do this, but I will address that in a subsequent article as this is more about the interface it provides. Adding context can allow you to specify any number of dynamic situation that are taken into account when determining whether a user has access to perform an action. Consider the following:

public interface AccessContext {
   boolean isAllowed( User u );
}

public interface AccessRole {
   // Some methods
}

public interface User {
   // ... Other user'ish stuff
}

public interface AccessController {
   boolean canUserPerformAction( User u, Context c, Action a );
}

public interface Action {
   void performAction();
}

This is a simple outline of how a Context Based Access Control API might look. Now in your code you might have something that looks like this:

   User user = RequestHelper.getUser();
   Context requestContext = RequestHelper.getContext();
   if ( accessController.canUserPerformAction( user, requestContext, new Action( "Delete User" ) );

Of course this is a very simple and open ended example, but it gets the point across rather well and illustrates the ability to solve problems in a manner that allows the AC layer to be as fine-grained or big hammer as it needs to be in any given situation.

To summarize:

1. Role Based Security doesn't address the problems of today's applications.
2. Context or Activity Based Security has the power to address those problems, but there is no force driving it forward.

I have proposed to the ESAPI team that we are in the perfect position to address this problem at the API level. Designing a clean interface that addresses the simple as well as complex control situations is really the difficult part in this concept.

An interesting read if you have a second - it looks like Microsoft had the same idea 2 years ago, too bad they patented it and did absolutely nothing with it.

http://www.freepatentsonline.com/y2007/0143823.html


I would love to hear what the 'verse has to say about this so let's get some conversation going around this topic and see what we can come up with!

Synchronizing the HttpSession

This is something that I have heard a great deal of debate over the last 2 years about. The servlet spec was somewhat recently amended to clarify that there is no guarantee that multiple calls to HttpServletRequest.getSession() or HttpServletRequest.getSession(boolean) will return the same object. This holds especially true in containers that return a facade object that wraps around the actual HttpSession object that you are working with, like Tomcat.

Why would you want to synchronize a session anyway?
The answer is pretty simple actually. Consider the following theoretical block of code:

public class WithdrawFundsServlet extends HttpServlet {

 @Override
 protected void doPost(HttpServletRequest request, HttpServletResponse response)
   throws ServletException, IOException {
  User u = ESAPI.authenticator().getCurrentUser();
  String withdrawAmt = request.getParameter("withdrawAmt");
  float amt;
                Account acct = session.getAttribute("acct_"+u.getAccount());
  try
  {
   amt = Float.parseFloat(withdrawAmt);
  }
  catch ( Throwable t )
  {
   ESAPI.log().info( Logger.SECURITY_FAILURE, "Non-Numeric value passed as Withdraw Amount");
   try {
    ESAPI.httpUtilities().sendForward(request, response, "/error" );
   } catch (AccessControlException ignored) { }
  }
  
  // Calling Withdraw will queue a check to be printed and mailed to the customer.
  AccountFacade.withdraw( acct, amt );
  
  try
  {
   ESAPI.httpUtilities().sendForward(request, response, "/success" );
  }
  catch (AccessControlException ignored) { }
  
  return;
 }
}

Now there are a couple things that I will point out that I am sure you will notice if you are paying attention. The first is that yes, this example is using the ESAPI. Call it a shameless plug :). The second is that I am ignoring AccessControlExceptions. This is purely to keep this example scenario short and to the point, and in any production code, you would never want to do this. There would also be some validation code in there as well.

Aside from those things, it looks innocent enough right? Well let's consider this for a second with a scenario.

Joe needs to have a check cut to him from his account at SomeBodiesBank. So he gets online and hits the form for the above servlet. Joe is not that savvy of a computer user, and like most novice internet users will do, he has the tendency to double-click on everything. He fills out the form to withdraw $500 from his account and double-clicks the submit button. So somewhere on the backend, we'll say in the AccountFacade.withdraw method, the software validates that Joe has enough money to cover the check, it discovers he has $750 in his Checking account so everything looks good. But wait a minute, Joe double-clicked remember?

Do you know what happens when you double click the submit button on a form? Well, 2 requests get submitted one after the other. Hmmmmmm.. So now I have 2 requests entering this method at the exact same time, both requests check Joe's balance and discover that he has $750 in his account, so they both queue up a request to print a check for the requested amount. There's only one problem, these are cashiers checks, the bank has withdrawn $1000 dollars (or in some circumstances, maybe only withdrew the original $500 from his account) but Joe ended up with $1000 in cashiers checks!

The checks show up in the mail, and Joe being the responsible individual he is, reports this to the bank. The bank will likely write this off as an anomoly and the bug will remain until one day when Joe is down on his luck and remembers the bug. He finds a program called JMeter and submits 1000 requests to the servlet as fast as he can for $1000 withdrawals. When his 1,000,000 in cashiers checks arrive, he promptly leaves the country and disappears in the backwoods of New Zealand never to be heard from again.

So the moral of the story is that this problem could have been easily avoided simply by adding thread-safety measures to the code. Granted the example cited is extreme and the consequence of the example even more extreme, but I can promise you that something similar to the situation has already happened and even moreso I can guarantee that something similar will happen again.

So, with this knowledge, what is the correct means to add thread safety around manipulating the session. It's quite simple even.

final Object lock = request.getSession().getId().intern();
synchronized(lock) {
   AccountFacade.withdraw( acct, amt );
}

Would do the trick in this simple example.

It's important when using synchronization to always lock on immutable objects. It is also important to use the same lock when locking in multiple places where you are working with the same data. Thread-safety is an entire subject on it's own that is will beyond the scope of this blog posting, so I will cut to the chase here.

This is incorrect, and not guaranteed:

synchronized (request.getSession()) {
   // do stuff
}

While this method is proven and works:

synchronized (request.getSession().getId().intern()) {
   // do stuff
}

Some interesting stats to close out with:

Google Code Search Results found approximately 4000 uses of different ways to say 'synchronized(session)'

The scary part is this was only the first 5 ways I came up with to search for it.

State of the InterWebz - Authentication and Usability

I am going to divert away from my current JMX saga for a brief moment to discuss an interesting post on the internet that was shared with me regarding usability versus security with masked passwords.

The post, from Jakob Nielsen, states that it is time to do away with password masking to improve usability (post is referenced at the bottom of this post).

This got some interesting conversation going on the webappsec mailing list and got me to thinking about the problem. Jakob has a point in his original post, that as a result of password masking, the average user tends to choose simple passwords to remember (which are quick and easy dictionary cracks) especially if they plan on logging on to the website from their mobile device.

I am sure everyone is aware why password's are masked in just about every type of password type authentication medium across the globe (ie: website logins, OS login, ATM PIN, Alarm Code, etc.) but the main goal is to prevent "shoulder surfers" from easily learning peoples passwords. Arguably, this is a first line of defense only, and not even close to a solution as someone who is good at their craft will be able to get your password just as easily by watching you type it on the keyboard. There are also several other ways that a devious individual may gain access to your password with keyloggers, camera's, or good old fashioned social engineering and simple masking your password bears no protection against these types of recon.

Now don't get me wrong, I am of the mind that having your password masked is a good thing, if we continue to rely on password type authentication. Any security concept should be multi-layered to address as many concerns as possible.

On the iPhone, when you type in a password, it apparently shows the current character you are typing in the form field, then masks it when you move on to the next character. This is an interesting concept and one that has apparantly been adapted on some sites across the internet using a JavaScript hack on a normal form input field.

I am definitely not of the opinion that this is a good idea by any means. Password masking is something that happens at the browser level. A developer simply specifies that a field on a form is of type password, and the browser implements a masking strategy over that field. JavaScript has no place in the security realm, regardless of how harmless it may seem, most of the time when you introduce javascript as a security tool, you open more holes than you close due to the nature of the language and how it interacts with browsers.

This brings me to the point of this post.

We live in a world where every day we grow more and more reliant on the internet to go about our daily lives. We bank online, we shop online, we interact and communicate online, there isn't much that we cannot and in most cases *don't* do online.

The world was a much more seemingly innocent place when the internet was born and no one envisioned that it would be what it is today, and as such, the security model that the internet uses is far too lax to be reliable, no matter how many layers of hacks and crap we put in front of it. There will always be one significant security hole on every web application in the world, in every social network, and on every bank or shopping site.

Humans as a Vulnerability

No matter what we do, the human element will always be there and the average human being has no idea what dangers are lurking around every click he makes on the net. There are a ton of plugins and apps that help to mitigate the risks of using the internet like popup blockers, phishing filters, virus scanners, and so on. These are essential to have installed in any environment, but they do not solve the problem of a poor security model overall, they only patch little leaks in a sinking boat.

Browser manufacturers need to go back to the drawing board when it comes to security and especially when it comes to authentication.

I don't pretend to have all the answers, if I did know the answer, I would be a rich man. I do have thoughts and theories though.

Certificates

Certificates eliminate the need for any human interaction in the authentication space. This, generally, is a good thing provided the human involved can keep his certificates safe. The main problem with using certificates is that support for them in the web space at this point, is shaky at best and there is no good implementation model to use them for authentication to web applications that I have seen. I feel that using certificates is probably the best option that we have in today's world as a first line of defense in our applications when it comes to authenticating users and verifying their identity.

Certificates themselves can also have a password to use, or an empty password for passwordless use. So if you are using a certificate to authenticate and you don't have a password set on the certificate itself, someone only needs gain access to your certificate files to become you.

Password Vaults

Password vaults are a great idea for people who need to remember a lot of passwords. I personally have solved the complex password typing issue completely on my blackberry by using it's integrated password vault to manage all my different internet passwords on different sites. The idea behind a password vault is that you only need remember one password, the password to your vault. The vault stores all of your individual passwords (encrypted of course) and sends them to the application when it prompts you for your password. This is a pretty ingenious idea that has been around for quite some time, however it too has it's vulnerabilities.

Your passwords are stored in a file, usually in some type of proprietary encrypted format specific to the password vault application that you are using. And they are of course, protected by a password. If a nefarious individual determined what password vault you were using, and in turn acquired, through some questionable means, your data file and your password (see shoulder surfing, key logging, etc) they could potentially unlock every password to every application you use and thus, become you.

Fingerprinting

Fingerprinting is an interesting concept that covers a wide variety of authentication in the real world. From retinal scanners, to fingerprint scanners, to hardware addresses and device fingerprinting, this is an interesting yet still vulnerable means of authentication.

For example, a good friend of mine bought an HP laptop with a fingerprint scanner and a touch screen. Hmmm. Sounds too easy to me. I quickly was able to demonstrate how in less than a minute I could lift a fingerprint from his monitor, and use it to gain access to his laptop.

We've all seen in the movies when the guy wears contacts fashioned to look like someone else eye bypasses retinal scanning, and while that may be science fiction in most regards, with todays technology it is very possible to create if you have know the right people and they have the right equipment.

Hardware addresses and device fingerprinting are all-to-easy to bypass these days. Wireless access points have shown us how quickly and easy it is to become another device altogether through some quick air sniffing.

So whats the answer?

My theory is that all of the above should be combined, to create a multi-layered authentication engine that is capable of thwarting most would be attackers, or at least making their job a good deal more difficult and time consuming.

What if there was a browser that implemented a secure password vault (I am not talking about the 'Remember This Password' popup that browsers currently have, I am talking about a true password vault with strong encryption). Having a single password to unlock every password would encourage people to put more thought into creating a more complex password that would be much more difficult to crack. When you only need to remember a single password, it is much easier to remember a complex one. Since all interaction with the applications would be handled via the password vault, the actual application passwords could be extremely complex sequences generated randomly by the password vault itself. This would require application developers to change their line of thinking too, and implement a new type of signup functionality and authentication strategy. Perhaps password creation and authentication would happen as a seperate request over a https connection that would create a token on either side of the connection for challenge/response authentication per-request. But I digress..

Now let's take it to the next step. This is where certificates come in. Instead of unlocking the password vault with a password, what if the password vault was unlocked with a certificate. For the end user, if using a password secured certificate this really is a transparent feature to them, as they still enter a single password to unlock every password, however, it adds an additional layer of complexity to the nefarious hackers evil plot to become you. Now in addition to getting your password vault data files, they also have to acquire your private key to unlock the vault.

Already, we have not only improved the usability of authentication on the web, we have easily doubled or tripled the complexity that a hacker must overcome to steal your identity on the web, just by leveraging existing technologies in a way that makes sense for the security model. This is probably good enough, but I am going to take it even one step further, given the nature of what people do on the internet every day, I would like to see something even more secure.

This is where device fingerprinting comes into play. A USB key could be the answer to the problem of human interaction. A lot of people will immediately argue at this point that now authentication on a website requires a physical piece of hardware to be on your person at the point in time which you wish to use the service. This is where I say, yes, precisely.

Think about it this way, most of us live in a house or apartment; and we safeguard our belongings, information, and family by putting a door that locks and requires a key to unlock between ourselves and any would-be intruders. Granted, there are other ways into a house, just as their are other means to steal an identity on the internet, but if a thief had the choice of walking through an unlocked door or breaking a window, which do you think he would choose?

My concept is that browser manufacturers include a means for an end-user to generate a signed certificate, that is a certificate signed by the browser manufacturer itself, that's single purpose is to live on removable storage (ie: USB thumb drives) and unlock their password vault. The end user then slides the USB thumb drive onto their key ring right between their car keys and the key to their deadbolt on their house and voila! Unless you have a habit of leaving the house without your car keys you will most likely have your authentication with you at all times.

Now, I will be the first to admit, this all seems like it would be far too much for say signing on to facebook, however, think about signing on to your bank website, or purchasing items online, or trading stock, updating insurance information, or filing taxes. All these things are sensitive operations that I believe require a great deal more authentication and proof of identity on the web than typing bob303 into a password box on a web form.

Security constraints should always reflect the level of sensitivity of the action that you are trying to take and it should be no more different on the internet. The responsibility lies on the browser manufacturers, the server developers, and the application developers to recognize this and implement something new. I am sure that there are holes in my concept and there are definately ways around it if an application has vulnerabilities outside of it's authentication scheme (ie: session hijacking, cross-site request forgery, etc.) but your authentication is your first line of defense and as such it should be treated with a great deal more respect than it currently is.

I could probably continue on about this for another 50 pages, and perhaps I will have to write a paper detailing my ideas and theories about the general state of security on the web and the mindset of the people that create functionality therein, but for now I think this brings up some interesting topics for debate and conversation and I am anxious to hear other peoples thoughts.

References:

Jakob Nielsen's post on Password Masking versus Usability
http://www.useit.com/alertbox/passwords.html

WebAppSec Consortium (Home of the Web Security mailing list)
http://www.webappsec.org