Monday, August 2, 2010

"Interesting project" - owasp-esapi-js

Just to keep in touch with some security topics, I have downloaded latest code of OWASP ESAPi for Java
and JavaScript today.
I'm bloging about the JavaScript part today.

This is the quote from original site (if you do not know OWASp and/or ESAPI:
http://code.google.com/p/owasp-esapi-js/
The purpose of the ESAPI is to provide a simple interface that provides all the security functions a developer is likely to need in a clear, consistent, and easy to use way. The ESAPI architecture is very simple, just a collection of classes that encapsulate the key security operations most applications need.

Just the first look is shocking:

the esapi.js
does not use closure to hide it's internal functions,
pulutes global space,
modifies Array and String prototypes,
$,
uses bad uncompressable techniques,
unefficient constructs,
and ...
is "unsecure" and "destructive".


Unsecure can be shown here:

if (!Array.prototype.each) {
Array.prototype.each = function(fIterator) {
if (typeof fIterator != 'function') {
throw 'Illegal Argument for Array.each';
}

for (var i = 0; i < this.length; i ++) {
fIterator(this[i]);
}
};
}


What is the purpose of the if here ? If already defined, use the defined function
override otherwise. Defined by who ?

Browser ? As far as I hnow, none JavaScript version supports Array.prototype.each
(there si forEach in JS 1.6)
Other library ? How trusted ?
Or injected poisoned version of XSSed script ?

This method and others constructed in the same style are then used in subsequent
"security APIs".

Destructive means:

var $type = function( oVar, oType ) {
if ( !oVar instanceof oType ) {
throw new SyntaxError();
}
};

In global scope of course.

Those two are ultimately candidates for criticism, specially in "security related library".

The rest of the code which is not big (3000 lines including spaces and comments),
shows quite inconsistent coding style,
and lack of professional Java Script knowledge.

So much for now, I will have deeper look later,
but I'm not impressed.

"Shame of OWASP label"

2 comments:

  1. First, thanks for taking a look at the project. The more eyes we have on it the better it will be when it is finished!

    I am the project owner of the ESAPI4JS project, and as such wanted to make sure that the air is clear and that the status of the project was not misunderstood.

    This project is *far* from release quality at this point - the code that is checked in now, is merely a working prototype of the library. I originally would have thought this as a given with the version of 0.1.3 but perhaps I was wrong in that assumption, so I apologize for any misconception that this code was ready to be used in a production application.

    Second, while wrapping functions in closures provides the illusion of security in Javascript by limiting the scope of the executing code, I would also like to point out that at this point, it really doesn't matter what scope the code lives in, it is inherently insecure as in javascript everything ultimately has to bubble up to the global scope at some point to be accessible to the rest of the code. Originally, the concept was to expose on the ESAPI locator in the global scope and privatize the rest of the code with references only available to private members of the locator itself. However, even at that point any implication of security is still nothing more than an illusion due to the fact that as soon as something is exposed in the global scope, anything else can modify it or it's references.

    That being said, I have toyed around with the idea of sandboxing, however I think that it is also important that the footprint of ESAPI be as small as possible to accomplish it's goals.

    I have been engaged with the ECMA 5 community and with the firefox team in the implementation of the Object.lock/unlock prototypes, as I feel that this is an imperative step in truly creating a useful javascript security API.

    All that being said - I would love the opportunity to chat with you about ideas you may have to make the library better or more useful - and if you have cycles to spare, it sounds like you definately have a lot to contribute to the project as a whole.

    Also - for the record I am a professional Software Engineer - I write primarily in Java and do quite a bit of JavaScript, HTML, and CSS. It is not a lack of knowledge that you see, moreso a desire to get a prototype out quickly to demonstrate the potential usefulness of such a library.

    Feel free to contact me personally at chrisisbeef (at) gmail (dot) com - or join the ESAPI-Developers and ESAPI-Users mailing lists. Without criticism, progress can't be made - and there are definately a lot of us looking to make ESAPI better for every language.

    ReplyDelete
  2. "closures provides the illusion of security": nice sentence, but properly using closures, aliasing functions and using other techniques minimizes the possible "attack or demage-by-mistake surface" as well as helps to write "unobtrusive" code not interfering with others (at least).

    Could you explain what you mean by "sandboxing" and "footprint" and how sandboxing can influence footprint ?

    I believe you are employed as SW Engineer but sorry no offence it still makes no guarantee of
    "professional Java Script knowledge". Those two are unrelated topics,
    I'm professional JavaScript and Java coder and
    I have far from professional JS knowledge.
    there are other geeks on web, I try to learn from.

    I will send you by email very brief suggestions, that could make the first step to improve things.

    I also hope we can attract more JS people, with this small chat, and in several years I will be able to download and use owasp labeled code and benefit from it.

    ReplyDelete