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.
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.


Call To Arms: ESAPI Documentation Team!

We are in desperate need of some people to aid in updating and completing the documentation for ESAPI 2.0GA Release (upcoming).

If you are a technical writer, or interested in writing at all, we could use your help! After all, how many of you would actually want your developers to also write your technical documentation?

That being said - here are the primary areas we are looking for help with documentation:

  1. Installation and Configuration
    This area of the documentation has been done and done again, but still needs to be clarified and updated to reflect changes in 2.0 and consolidate some of the developer documentation (crypto) into the core documentation.
  2. Integration
    This area of the documentation needs a lot of love and attention. This area is also the least defined as far as what goes here. I envision a basic outline of:

    • Integrating Core Componenets (Encoder, Logger, Validator, etc.)
    • Extending Core Components (Adding custom validators - etc.)
    • Creating Adaptors (Authenticators, Access Control, etc.)
    • Integrating with Popular Frameworks
      • Spring
      • Struts
      • Grails
      • GWT
      • etc
  3. Real-World Solutions
    Collection of Examples of how to solve real issues encountered in applications

These are only a few that I could think of off-hand, so if you are interested in helping - get in touch with us on the ESAPI-Developers or ESAPI-Users Mailing Lists and let us know. You can always get a feel for what we have already by visiting the wiki at The ESAPI Homepage.

Dave Wichers has offered to head up this effort and work on a documentation roadmap - and he has been with the project since the beginning offering thoughts, patches, and guidance.

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.


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!



If you follow my Tweets you probably are already aware that my talk on ESAPI was accepted and is scheduled to happen at AppSecUS 2010 in California this September. I am super excited about it!

I will be streamlining my Presentation from FROC 2010 and trying to cram a lot of information into a 45 minute presentation, and so I wanted to reach out to the community, especially to those who are thinking about coming to AppSecUS to see exactly what you guys would like me to spend my time on.

It seemed like a good deal of the questions after the presentation at FROC and the presentation(s) I had the pleasure of helping give at UberConf with Ken Sipe had to do with the following areas:

* Configuration
* Using specific components
* Cross Language Compatibility
* Encoding and Validation

So my initial plan is to reformat the presentation to address these concerns primarily and leave room for elaboration and code demos real-time.

I would love to hear what you all think and if you would like to see other areas covered as well.

I am also still in the planning phases of an ESAPI Bootcamp Training session that will either be a Webcast and/or hard-core weekend training event located in Denver, so I will keep you all posted on that.

I know I promised in my last posting that I would be throwing up some recipes and sample ideas from the book (which I have started and am working on) - however with work, life, and conference season in full swing, I have decided to put this off until this fall, when I will have more time to focus on it and more input from the community (and hopefully - a NSA reviewed GA release of ESAPI 2.0)

Hope to see everyone in California in a little over a month, and looking forward to reading your input and ideas!


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.

   <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');
<body onload="function(){document.getElementById('nameplace').innerHTML = firstName; }">
  <h1>Hello <div id="nameplace"></div>, Welcome to my Vulnerable Page!</h1>

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:

   <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">
      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';
<body onload="function(){document.getElementById('nameplace').innerHTML = $ESAPI.encoder().encodeForHTML(firstName); }">
  <h1>Hello <div id="nameplace"></div>, Welcome to my Vulnerable Page!</h1>

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!" );


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)

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

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();

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) {
      return out;

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

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 );

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

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.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.

Cracking Passwords with Teh Google

Have you ever googled yourself? You may have to sift through several pages of results about people with the same name that aren't you, but you would be surprised how easy it is to find a wealth of information about yourself by combinging information retrieved by your social networking profiles being indexed.

Have you ever tried your hand at cracking a password? Chances are if you have, you have downloaded a word list and may have eventually cracked a password (unless you happen to have a cluster of PS3's laying around to do all the processing for you)

Password cracking is a lost art that often requires a lot of patience. There are two primary methods of cracking passwords: online and offline. When you attempt to crack a password online, it is often via a 'brute-force' style attack and has to be throttled carefully to avoid immediate detection (although, any competent system admin will be able to spot an online BF from a mile away after 10 shots of tequila) Offline, is often much more difficult to accomplish, simply because in order to crack a password offline, you either need to obtain a password list, or at bare minimum the hash of the password that you are trying to crack.

All that aside, one of the most difficult and time consuming parts of cracking passwords is starting with the right wordlist. There are tons of really horrible wordlists spread all across the internet, and even a handful of good ones. I am fairly partial to the Common Passwords Dictionary and the extremely large dic-0294 when I am flying blind.

However, with the wealth of knowledge available on the internet about everyone you know from sites like facebook, myspace, linkedin, hi5, twitter, and the list goes on and on, there really is no need to fly blind anymore when cracking passwords.

Now before I go much further, let me warn you that this is a tedious process right now as I am not aware of any tools in the tubes that do this for you (although, such a tool probably would not be to difficult to build) Also I would like to note that as a security professional, the information that I am providing is as much a warning to people about how easy it is to get their password, as it is a informative post about something that has been sorely neglected in security presentations (that I have been privy too).

To keep this relatively brief while still getting the point across, the example I am providing below is purely fictional, and any similarity to actual people is completely unintentional.

Step 1: Recon
If you personally know your target, this step is pretty much already done - however, if you don't know the target, the first step is to find out some very basic information about them. This is all public domain information that is easy to gain through the use of search or social engineering. For the purpose of this example we will say that I am trying to crack the password of a coworker named Don Johnson.

Now I know very little about Don other than the company he works for (obviously) and the department that he is in. We will say that he is the director of Human Resources. Our fictitious company name will be Acme Inc.

So seeing as how I know about him only in his job, LinkedIn seems the obvious starting point for me. Now, LinkedIn is one of those funny psychological experiments that proves that people really don't care about their privacy, no matter what they say. Their profile may say that they are only interested in reconnecting with previous coworkers, but if a recruiter requests to be in their network, they will almost always click - if nothing else, for curiosity sake.

Google Search #1: site:linkedin.com "Don Johnson" +Acme +Denver

9 times out of 10, the Don Johnson we were looking for will be in the top 5 results returned from google. Once I have found his profile, it is quick and easy to get a free gmail account, create a fake recruiter profile on linkedin, and start adding a bunch of people, with Don among those being added. The reason for adding several people is that Don may be a little paranoid and if a recruiter with no network requests to be in his network, he may think twice about allowing him - however, if Don sees that this recruiter is acting like most every other recruiter on linkedin, and obsessively adding 10-20 people a day, well he will probably think nothing of it and allow the request. Once he is in your network you can view his full profile which will often include such information as all of his prior employers, education, blogs, etc. Generally, I will take a scrape of the entire profile (a scrape can be as simple as using File -> Save Page As in your browser) and use the information and picture from that profile to identify him on other networks.

Let us say that in the recon of my target I discovered a linkedin, facebook, myspace, and pandora account all linked to Don. I have scrapes of his profile pages from each network, along with an archive of comments and wall postings on friends profiles from the last 60 days.

Step 2: Assimilation of Information

This is where things really start to get interesting. You have a wealth of information now about your target. You know who he is dating, the names of all his pets (real and virtual), a list of his favorite musicians, movies, and books (invaluable), a collection of nicknames, his birtday, and much much more.

I specifically call out the fact that music, movies, and books are invaluable information to know about a target. Often, people will use a term or character name from their favorite stories as all or part of their password. So that being said, you can take Don's favorite songs look up the lyrics and start your wordlist. Next, look up a character list from his favorite books and movies, then lookup memorable quotes from those characters (imdb.com) and (wikipedia) are your friends here. Keep doing this with all the information you have until you have a comprehensive word list built specifically around the social profile of your target.

This is it, this is all you need to do. I have a relatively high (60-70%) success rate when building a custom word list using this method and if I were to take the time to build some tool that used the full power of the internet to build related information, I could almost guarantee a 90%+ success rate at using this method.

So the next time you are updating your profile on myspace or facebook, think about the password that you are using to login to that site and see if you can connect the dots between your password and any of the information on your profile. I would say that for most people, they will be able to make the connection fairly quickly and most of the time.

I purposefully described this process in a fairly abstract manner, as it is a very effective means of social engineering without having any direct contact with the target, and really, there are enough bad guys in the world already.

We rely on technology to keep our personal information secure and safe, yet the true dangers still lie in the information that we publicly disclose without a second thought. This is no different from the days of dumpster diving, only google is a much cleaner and organized dumpster.


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:

   # 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!