[Esapi-user] To URL encode cookies or not

Chris Schmidt chrisisbeef at gmail.com
Tue Aug 24 00:17:49 EDT 2010


+1 encode

Sent from my iPwn

On Aug 23, 2010, at 8:31 PM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:

> 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
> 
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user


More information about the Esapi-user mailing list