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

Kevin W. Wall kevin.w.wall at gmail.com
Sat May 1 11:32:45 EDT 2010


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.

FWIW,
-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 MIME


More information about the Esapi-user mailing list