[Esapi-user] To URL encode cookies or not

Kevin W. Wall kevin.w.wall at gmail.com
Mon Aug 23 22:31:29 EDT 2010


In redoing some of the ESAPI code to get rid of the internal calls to
the deprecated crypto encrypt() / decrypt() methods and replace them
with the stronger preferred versions, I ran across this in one of the
DefaultHTTPUtilities.setRememberToken():

    ...
    String clearToken = user.getAccountName() + "|" + password;
    long expiry = ESAPI.encryptor().getRelativeTimeStamp(maxAge * 1000);
    String cryptToken = ESAPI.encryptor().seal(clearToken, expiry);
    Cookie cookie = new Cookie( REMEMBER_TOKEN_COOKIE_NAME, cryptToken );
    ...
    response.addCookie( cookie );

Now Encryptor.seal() returns a base64-encoded string. The character set for
base64 encoded strings may include the special characters '+', '/', and '='
that would be subject to URL encoding.

Now apparently classic ASP automatically does URL encoding / decoding of
cookies. (Apparently,this is *not* the case in ASP.NET however.) This means
that sending a base64-encoded domain cookie that is not URL encoded in
a JavaEE application and then is sent to a classic ASP application is
likely to have problems. The reverse scenario is also true. (For example,
see <http://cephas.net/blog/2005/04/01/asp-java-cookies-and-urlencode/>.)

RFC 2965 (HTTP State Management) does not *require* cookies to be URL
encoded. Specifically, it says:

      The [cookie] VALUE is opaque to the user agent and may be anything the
      origin server chooses to send, possibly in a server-selected
      printable ASCII encoding.  "Opaque" implies that the content is of
      interest and relevance only to the origin server.  The content
      may, in fact, be readable by anyone that examines the Set-Cookie2
      header.

Of course with "domain" cookies, the origin server is a bit more nebulous,
but obviously, they all need to agree on the *same* interpretation.

However, I am not familiar with classic ASP to know if this automatic
URL encoding of cookie values is something that can be disabled or not. If it
cannot, it would seem as though that perhaps we should choose to always URL
encode cookie value or at least support an ESAPI configuration property that
would automatically enable this. Otherwise the ESAPI for classic ASP might
have interoperability issues in this regard.

Anyhow, I would appreciate the ESAPI Dev and User communities give feedback on
this ASAP. If we think that ESAPI4Java needs to always URL encode cookie
values, then I will make sure that I get that into the DefaultHTTPUtilities
class. But the 2.0_RC7 release candidate is waiting for me to complete
this and this is the last thing on my TODO list in this regard.

So, if you could provide me your $.02 ASAP, I'll see what sort of consensus
(if any) we reach. If there seems to be a consensus, I'll implement it that
way. If there is no consensus, I'll probably add an option (like ESAPI
needs more configurable options--yuck!). (If no one weighs in at all, I
may just encode them all using ROT13 so that all our ESAPI cookies look
like jokes. ;-)

So please weigh in *NOW*.
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 MIME



More information about the Esapi-user mailing list