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