[Esapi-user] Bug in HttpUtilities for cookie MaxAge with Internet Explorer

[Olivier Jaquemet]

Here is a proposed patch of DefaultHttpUtilities (include fix for 
previous bug reported with default max age of -1).

DefaultHttpUtilities.createCookieHeader() :

     // Test maxAge to fix bug with default MaxAge value of javax Cookie 
implementation
     // see 
https://lists.owasp.org/pipermail/esapi-user/2011-November/000916.html
     if (maxAge >= 0) {
       header += "; Max-Age=" + maxAge;

       // Add Expires header for compatibility with Internet Explorer 
and other browser
       // see 
https://lists.owasp.org/pipermail/esapi-user/2011-November/000917.html
       SimpleDateFormat cookieExpiresHeaderDateFormatter = new 
SimpleDateFormat("EEE, dd-MMM-yyyy HH:mm:ss zzz", Locale.US);
       cookieExpiresHeaderDateFormatter.setTimeZone(new 
SimpleTimeZone(0, "GMT"));
       Date expDate = new Date(System.currentTimeMillis() + (maxAge * 
1000));
       header += "; Expires=" + 
cookieExpiresHeaderDateFormatter.format(expDate);
     }

Tested successfully with :

  * Internet Explorer 7.0.5730.13
  * Internet Explorer 9.0.8112.16421
  * Firefox 7.0.1
  * Safari 5.1 (7534.50) for windows
  * Chrome 15.0.874.106 m

Regards,
Olivier

On 08/11/2011 12:31, Olivier Jaquemet wrote:
> Hi again ! :)
>
> I think I found another bug with DefaultHttpUtilities implementation
> regarding cookie max-age :
>
> When max-age has been specified, Cookies created by HttpUtilities are
> not compatible with Internet Explorer as the "Max-Age" option is not
> supported by this $£!%! browser, which only understand the "Expires"
> option of the original netscape specification.
> Common J2EE AppServer implementations usually set both Max-Age and
> Expires option to workaround this limitation.
>
> Source regarding IE incompatibility with max-age :
> http://blogs.msdn.com/b/ieinternals/archive/2009/08/20/wininet-ie-cookie-internals-faq.aspx
> http://mrcoles.com/blog/cookies-max-age-vs-expires/
>
> Source regarding some AppServer implementation :
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46403
>
> The tomcat bug report mentions a original security reason behind this
> change (some date parsing related problem).
> Therefore this behavior may not be a bug and was implemented voluntarly
> in ESAPI. If so where is it documented ?
> Otherwise, should I fill a bug report ?
>
> Olivier
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>

-- 
Olivier Jaquemet<olivier.jaquemet at jalios.com>
Ingénieur R&D Jalios S.A. - http://www.jalios.com/
@OlivierJaquemet +33970461480


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20111108/d73158b9/attachment.html