[Esapi-user] [Esapi-dev] Why ESAPI crypto uses a custom serialization scheme

Jim Manico jim.manico at owasp.org
Sat May 1 11:45:18 EDT 2010

This is not even a security issue in my mind. It's just getting chit  
to work.


1) web 3.0 style client ( pure js )
2) no plug in dependencies
3) webservice(s) require signed request body

I do not trust client side controls for obvious reasons. But the  
scenario above is becomming very common for enterprises and other  
organizations who use the latest web technologies.

Jim Manico

On May 1, 2010, at 8:32 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com>  

> Jim Manico wrote:
>> Encrypting on the client is a fundamental - hard core fundamental - 
>> need
>> as we approach the web 3.0 world of client side apps interacting
>> directly with webservices.
>> Sure, those of you still playing with HTML forms or web 2.0 AJAX  
>> might
>> scoff at most client side security controls.
> I do not scoff at client-side security controls. Rather I just realize
> that while they may be necessary, that alone, they are not sufficient.
> Fortunately, there are some FOSS JavaScript crypto libraries already
> in existence. (For example,
> http://www.clipperz.com/open_source/javascript_crypto_library)
> At one point, Chris Schmidt was considering adding support for crypto
> into his ESAPI4JavaScript project to be able to interact with ESAPI  
> for Java.
> But at the time, the use cases really were just not there. Most did  
> not
> deal with data at rest, but data in transit, for which TLS is a better
> alternative. Besides storing encrypted data on the client side via
> JavaScript would require signed JavaScript and I just don't see that
> being used very much today. I've only encountered one case of signed
> JavaScript in the past 10 years at Qwest. In most situations where it
> could have been used, developers chose to write signed Java applets
> instead.
> The important thing to remember when using *any* crypto for *any*  
> purpose
> is "who is my adversary"? That largely will determine where the  
> security
> controls are placed.  In most threat models, we consider the end  
> client,
> sitting behind his/her browser as a potential adversary, so putting  
> security
> controls at the client end where they may be easily by-passed does  
> nothing
> except perhaps to give you a false sense of security; it's really just
> security through obscurity. (Of course, if you are writing malware  
> for the
> client-side, that may be good enough, but I hope that none are these  
> lists
> are using ESAPI for such purposes.)
> However, in the rare cases where you client is *completely trusted*  
> (and
> I think those cases should be very rare), then crypto on the client  
> side
> MIGHT be OK if you cannot afford [wrt performance] to use TLS at all  
> times.
> In that case, you are saying that your only adversary is either  
> sitting on
> the network between client and server or somewhere at the server  
> end. And
> it should be that even in these cases, you still have to use a secure
> communication channel to download the crypto JavaScript client code  
> that
> you wish the client to execute. (The same of course is true if they  
> instead
> choose to use Java applets if the code needs to be downloaded.)  
> Failure to
> do so will allow a MITM attack that can force the client to download  
> whatever
> code your adversary chooses.
> So, in summary, I don't think that crypto running in the client  
> browser is
> _never_ called for. Instead, it should be very rare because it is  
> dealing with
> a very different trust model where you are willing to completely trust
> the client end. And in this day where so many PCs are infected with  
> rootkits,
> keyboard loggers, and other malware, I for one, am very reluctant to  
> do that.
> -kevin
> -- 
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts  
> agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of  

More information about the Esapi-user mailing list