ESAPI4JS - Very good write-up by Marcus Niemietz

So late last week, I recieved the final copy of a paper written by Marcus Niemietz that takes a deep dive into the ESAPI4JS Proof of Concept I wrote over a year ago. I was quite surprised, to say the least - and a bit humbled by 20+ pages of text on the project.

It's funny, I was just thinking about digging in my heals this spring and running through this code again - clean it up, trim a bunch of fat - and possibly do some additional integration into further jQuery plugins. Seems that I am not the only one who has been thinking about this project lately and that is great news!

First and foremost - I have reposted the entire report (with the author's permission and OWASP's) over on the OWASP Site.

Marcus spends some time discussing the project and concept of the project as well as the ESAPI project as a whole first off. Ths lays the groundwork for his paper and is probably stuff that most of you (my readers) already know. He also corrects some mistakes in the installation guide (that will be reflected on the wiki as soon as time allows). In addition he also spends some time discussing the assessment criteria and specifically how they relate to this project.

Once we get passed all of that, we get into the real meat of the paper.

Section 3 focuses on improvements that could be made to the project and this is where I would like to spend most of my time in this post.

3.1.x - Retrofitting Security

Marcus calls out a point here that a mature SDL will have isolated the "risks" of the application prior to any development being done. This is generally very true for shops that have an established and mature SDL - but that statement definitely does not apply to the majority of software development shops that are writing applications for the web today. The idea of retrofitting security into an existing application is paramount to the idea behind ESAPI. It is imperative that developers have the ability to integrate ESAPI controls into existing applications because there are a lot more insecure existing applications on the internet right now then there are new applications being built. Several large shops have legacy applications that are no longer actively maintained unless there is a problem, some have such massive application portfolios that it isn't realistic to expect rewrites and large redesigns, and the majority of the applications that are live (and vulnerable) on the web today are smaller "Mom and Pop" applications. This is the target market for ESAPI!

3.2.x - Modification of Objects


I heartily agree this is a huge issue - and one that I have passionately spoken out about whenever the opportunity arises. The fact of the matter is that until Javascript accepts the fact that some objects just *need* to be immutable, security will always be just another stepping stone for the attacker to (easily) overcome in the browser. In specific Marcus refers to the ability to overwrite objects in the DOM by referencing HTML Elements with the same id in Internet Explorer. While this is indeed a problem, the issue is much larger and depends 100% on the forced implementation of Immutable Objects in ALL browsers as described in the ECMAScript 5 Specification

3.3.x - Redundancy


This is a tricky issue in some regards, while most of this is due to the fact that I was simply creating a proof of concept that this could be done in Javascript - I also am a firm believer that all implementations of the ESAPI (regardless of language) should follow a well defined API specification. Because of this, it is to be expected that there will be some redundancy in some languages - some methods that perhaps just don't make sense in the language (such as the illustrated escape/unescape methods) will be implemented anyhow just to enforce the contract (implied in JS of course) of the API.

Adding more Validation!


I  agree with this to a certain extent - I think that all the suggested validators should be "available", but there is no need for my user registration form on my small used book store to require validation of International Bank Account Numbers - it does however make sense to provide ISBN validation. This problem (I believe anyhow) is addressed very well in the jQuery Plugin architecture and I would ultimately like to see this same type of architecture implemented into future ESAPI4JS implementations.

Summary


All in all, I think Marcus did a great job researching and presenting his case in this paper, and I highly recommend that everyone give it a read and comment. I look forward to reading your comments and rebuttals  - this is how we change the world people. One small debate at a time. :)

New Encoding - Property Aware Contextual Encoding

After some conversations over Twitter with the the XSS Ninja known as Gareth Heyes regarding different escaping needs that went even further than just having the context itself. Basically, the gist of the conversation asserted that different escaping rules applied to different CSS properties, for instance the background-color property accepts Hexadecimal color codes (#CCCCCC) or rgb color (rgb(100,100,100)) formulas as well as plain-text well-known color keywords (blue) - this is drastically different than what would go into something like say the width property - which would simply be a fixed size or percentage. It was at this point that we came to the conclusion that jquery-encoder should use the property name that is being encoded for to determine the correct escaping syntax.

The new API for the property aware encodeForXXX methods follows

• encodeForCss(property,data,omitPropertyName)
Returns the encoded property: value pair, escaped in the context of the passed in property. Banned properties are the behavior family (behavior,-moz-behavior,-ms-behavior) as they are not safe to be set using untrusted data and allow for script injection by definition. Values that contain the expression keyword will also be rejected as unsafe, as this is the equivelent of calling the javascript eval within a style context. If the optional omitPropertyName is true the function will return only the value encoded for the passed in property.

• encodeForHTMLAttribute(attribute,data,omitAttributeName)
Returns the encoded attribute="value" pair, escaped in the context of the passed in attribute. Banned attributes are href and src as those should be encoded using the encodeForUrl function. The javascript event hooks on* are also banned as they should be set using the encodeForJavascript function. The style attribute should be set using the encodeForCSS function. If the optional omitAttributeName parameter is true, the function will return only the value encoded for the passed in attribute.


In all cases, the property/attribute names are canonicalized prior to encoding to validate and get the escaping context for that property (or the default if there is no specific context specified)

This was a somewhat difficult decision to make, simply because it is mixing in a bit of validation with the output encoding control - which is not necessarily ideal from a pure design standpoint. I felt however, that this was a necessary evil in order to ensure correct encoding/escaping context and get the most value from the plugin.

Please continue to send me your thoughts and ideas for the plugin - I plan on releasing it to the general public through the jQuery plugin repository within the next couple weeks so any feedback from the community leading up to the release of the plugin will only make it stronger!

As always, the latest version of the plugin is available from my github
https://github.com/chrisisbeef/jquery-encoder

The sandbox (which will be updated with the latest version today) is available on my site:
http://software.digital-ritual.net/jqencoder/

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

jQuery-Encoder updated

I have made several updates to the jqencoder plugin over the weekend and thought I would share a little about them quickly.

Plugin Readme: http://bit.ly/ie4J04

First, and most importantly - I have added a series of static methods (that look similar to the methods on the Encoder interface for ESAPI) to perform particular contextual encoding tasks - specifically when building html dynamically rather than building elements up using the DOM.

• encodeForHTML
• encodeForHTMLAttribute
• encodeForCSS
• encodeForURL
• encodeForJavascript

Each of these methods can be accessed under the static $.encoder context.

$.post('http://untrusted.com/external_profile', function(profile) {
      $('#widget').html('<div id="untrusted_widget" width="' + 
                        $.encoder.encodeForHTMLAttribute(profile.width) + 
                        '" onmouseover="' + profile.callback + "(\'' +
                        $.encoder.encodeForJavascript(profile.parm) + 
                        '\')">' + $.encoder.encodeForHTML(profile.data) + 
                        '</div>');
   }

In addition, the $.canonicalize method has also been moved into the $.encoder context.

$('#phonenumber').blur(function() {
      validatePhoneNumber($.encoder.canonicalize(this.val());
   });

The third, and final big change over the weekend - was solidifying the ES5 immutable objects protection. If it is supported by the browser, the $.encoder object will be frozen, sealed, or non-extensible (in that order of priority) to protect the encoding and canonicalize functions themselves from being tampered with at runtime. At this point in time, Chrome has implemented Object.freeze in the latest release version, Mozilla has implemented it in Firefox 4 and Microsoft have implemented it in IE9. Safari shows no indication of implementing it, and neither does Opera.

Now, I pose a question to the developers that may use this plugin. Is there a need to keep the instance method $.fn.encode? It seems to me that due to the nature of setting DOM element properties via Javascript, that this is not really needed at all. So, should I nuke it?

I end this post with a final thought (continuing from my above conversation of Object.freeze)

I strongly recommend that developers start taking the initiative to make their custom JS objects immutable, and also recommend making framework objects immutable as well. If you were to (using jQuery) issue the following in your onready handler

$(document).ready(function(){
   if ( Object.freeze ) $ = Object.freeze($);
   // .. initialize page below here
});

It seems to me, this could eliminate a lot of potential vulnerability exploitation of bugs in framework code. What are your thoughts?

Also, why not consider the following:

var lock_objs = [ String.prototype, 
                     Array.prototype, 
                     Function.prototype, 
                     Object.prototype ];
   for (var i=0;i<lock_objs.length;i++) lock_objs[i] = Object.freeze(lock_objs[i]);