[Esapi-user] [OWASP-ESAPI] ESAPI Encryptor

Kevin W. Wall kevin.w.wall at gmail.com
Sat Jan 16 14:28:05 EST 2010

Fabio Cerullo wrote:
> so assuming the application server supports CSPRNG and they are using it
> properly... is it advisable to use ESAPI encryptor?

Probably not; it likely is a wast of time to use it to encrypt session IDs.
But based on what Ed Schaller & Jeff Williams wrote in a related thread to
this thread and also posted to this mailing list, it appears as though HTTP
Session Fixation is apt to be a problem still for most JavaEE application
servers / servlet engines..even the commercial ones.. Personally,
I'd be much more concerned about this. (In fact, I *am* very concerned
about it.)

As Jeff Williams mentioned, there is code in ESAPI in its reference
implementation using either its User.loginWithPassword() method or via
either of the HttpUtilities.changeSessionIdentifier() methods to mitigate
this. I recommend focusing on the session fixation issue rather than
the session prediction issue (which is what CSPRNG addresses). If for some
reason ESAPI is not satisfactory, there are other ways for remediation
of this issue. E.g., see the Reference links mentioned in the OWASP
Session Fixation link that I previously mentioned. The Wikipedia
article is particularly easy reading.

> in fact... what would be a typical use for ESAPI encryptor? for example
> transfering sensitive data between applications?

Well, yes, transferring sensitive data between applications is one use
(although most just address that at the transport layer via SSL/TLS).
The more common use is encrypting sensitive data for storage; e.g., storing
encrypted CC #s in a DBMS. I think many of us anticipate that ESAPI Encryptor
will be used to address encryption compliance issues such as those mandated in
PCI Data Security Standards doc.

> what other benefits ESAPI provides besides the ones Jeff & Kevin mentions
> about session fixation and prediction?

Boy, that would be a long discussion that would even wear me out. ;-)

I'd recommend starting here:

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