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>
Showing posts with label OWASP. Show all posts
Showing posts with label OWASP. Show all posts
5.11.2011
ESAPI 2.0GA IS RELEASED!
4.18.2011
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. :)
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. :)
11.20.2010
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:
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.
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:
- 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. - 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
- 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.
Subscribe to:
Posts (Atom)