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

Jim Manico jim.manico at owasp.org
Sat May 1 12:07:34 EDT 2010

One other requirement on my end - TLS connections only. Better? This  
entire mechanism seems to work great on modern browsers.  Heck - even  
ie6 plays well with JS crypto libs albiet slower that chrome+FF.

Jim Manico

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

> Jim Manico wrote:
>> This is not even a security issue in my mind. It's just getting  
>> chit to
>> work.
>> Requirements:
>> 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.
> BTW, forgot to mention, that while I see a lot of pure JS / XML being
> passed around (a good example is SAML's Browser POST Profile) through
> the client's browser, realize that that is a bit of a different animal
> wrt crypto. There the SAML assertions (which use XML Digital Signature
> and XML Encrypt) are created on the server and validated on the server
> and the BPP redirect just uses the JavaScript to POST to get the SAML
> assertion from one DNS domain to another. If that JavaScript is
> intercepted and the SAML assertion gets redirected, it's generally
> not a major security issue. (The exception would be if one were  
> sending
> sensitive PII in the SAML assertion as attributes and the IdP side
> decided that it did not need to do a separate encryption of the
> SAML assertion; i.e., a configuration error on the IdP.)
> What I have *NOT* see (except once with a signed applet) was where
> the client itself performs some encryption / decryption and it is
> interacting with the server over an non-secured comm channel.  If you
> are starting to see that sort of thing, are you are liberty to give
> us a hint as to what sort of application it is for? I need to know
> whether it is something that I should be watching out for.
> Thanks,
> -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