[Esapi-user] To URL encode cookies or not
chrisisbeef at gmail.com
Tue Aug 24 00:17:49 EDT 2010
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
> 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
> 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*.
> 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
More information about the Esapi-user