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

Kevin W. Wall kevin.w.wall at gmail.com
Sat May 1 13:22:33 EDT 2010

Jim Manico wrote:
> But Kevin - once your client is compromised - it's game over anyway.
> CSRF protections are moot, keylogger steals your pass, etc. What's makes
> JS crypto so special as a "bad" practice?

[Jim: You were just trying to goad me into writing another mammoth email,
      right?  OK, I'll bite.:-]

Compromise of a client should not lead to wider compromise of other
users or of server side data.

Here's an admittedly very contrived case that I've come up with to try
to illustrate what I mean.

    Your backend DB server stores millions of encrypted credit card #s.
    In fact, let's assume that it and the applications- that access
    has even passed a PCI DSS audit.

    There are certain accountant-type actors who are able to access
    these credit cards using their browser, but all the encryption /
    decryption is handled on the server.

    However, the accountant wants to generate en-mass reports (which
    will only display the last 4 digits of the CC#) of things like
    overdue accounts, possible fraudulent CC access, etc. To do so, the
    accountants tell you that they need to be able to interact directly
    with the decrypted CC data in a spreadsheet, etc.

    So someone in IT decides to build the accountants a new web application
    that has some RIA that acts just like a spreadsheet and will display
    the full CC number on the screen, but the "save as..." type of
    functionality ensures that only the last 4 digits of the CC# are saved.

    That same IT person figures it would be much less overhead on the server
    if the decryption were done on the client's browser, so they decide to
    actually send the decryption key down to the client browser and use some
    client JavaScript code (maybe something like the aforementioned
    Clipperz JavaScript crypto library) to decrypt the encrypted CC#s.
    That way the server doesn't take a performance hit when it needs
    to decrypt a few 100,000 CC#s that the accounts look at each month.

    Let's assume that of those 100K or so encrypted CC#s that are encrypted
    and downloaded to the accountant's client browser each month are out of
    a total of 10M CC#s held encrypted in the back-end DB. Also let's assume
    that there are appropriate access controls that exist on the web
    application such that each accountant can only access the CC# they
    are authorized to see, but no accountant is authorized to see all of
    them. (Maybe it's divided up by last name or region, etc. It doesn't
    really matter. Just that all accountants cannot access all CC#s.)

OK, so that's the scenario. What could go wrong? Well, you mentioned that
its "game over" if the client is compromised with malware. True...in part.

I want to show you how decrypting on the client _potentially_ makes it

Lets say ONLY ONE accountant's PC is compromised with a keystroke logger.
(How that happened is irrelevant to this discussion. Insert your own
favorite scenario.)

The black hat hacker eventually gets access to the accountant's pasword
and in turn gets access to the site. Let's say s/he can directly access
100K decrypted CC#s this way. S/he then looks deeper and realized that
the CC#s are being decrypted on the client-side rather than on the
server-side. Woohoo! Eventually they isolate the actual encryption key.

This means that all the attacker needs to get access to is the DB
of all the encrypted CC#s and s/he can then decrypt ALL of them
with the captured encryption key.

>From there, you can imagine many ways to get accsss to the DB. Use
your favorite way here. Maybe they contact one of the DBAs and are
able to extort or bribe them. Maybe they find an undiscoverd SQL
Injection vulnerability that allows them to dump all the encrypted
CC#s. I don't care what it is, but in some way you have not potentially
allowing the attacker to access all your encrypted data rather than
just the decrypted data that was avaialble to the user on that one
compromised accountant's PC.

...then, there's also the issue of 'trusted user gone rogue'. If an
accountant hears layoff rumors, maybe they attempt to find the
encryption key themselves. Etc.

Of course, all this points to a poorly designed system. (I told you it
was contrived.) But nevertheless, things like this happen all the
time. We have all seen them.

One moral of the story: Do a *detailed* threat model before you start
doing any crypto on the client side. I'm sure they are others you can
think of yourself, but that's the one I want to emphasize.

I'll step down from my soap box now. Thank you.

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