tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Preißer <>
Subject RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Date Wed, 18 Jun 2014 16:05:08 GMT

> -----Original Message-----
> From: Christopher Schultz []
> Sent: Wednesday, June 18, 2014 4:23 PM
> To: Tomcat Users List
> Subject: Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
> Hash: SHA256
> Konstantin,
> On 6/18/14, 5:34 AM, Konstantin Kolinko wrote:
> > 2014-06-18 11:57 GMT+04:00 Konstantin Kolinko
> > <>:
> >>>
> >>> HTTP/1.1 302 Found Set-Cookie:
> >>> JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu,
> >>> 01-Jan-1970 00:00:10 GMT Pragma: No-cache Cache-Control:
> >>> no-cache Expires: Thu, 01 Jan 1970 00:00:00 UTC Set-Cookie:
> >>> JSESSIONID=235F4293591E5C72859317ED3294C5A5; Path=/admin;
> >>> Secure; HttpOnly Location: https://X.Y.A.B/admin/login.jsp
> >>> Content-Length: 0 Date: Tue, 17 Jun 2014 16:21:17 GMT Server:
> >>> XYZ
> >>>
> >>
> >> With that value of "Expires" the cookie is actually being
> >> cleared, not set.
> >>
> >
> > The 'Secure' flag says that the browser should never send the
> > cookie to the server over a non-secure connection.
> >
> > When the cookie is being cleared, the "Secure" flag is irrelevant,
> > as the cookie will not be sent back by the browser.
> +1
> > The "HttpOnly" flag says that the cookie should not be accessible
> > from Javascript code running in the browser. If the cookie is being
> > deleted, is there a way to access it from Javascript? I think that
> > there is no such way.
> +1
> I think this is a spurious error being flagged by the security
> scanner. Adding "HttpOnly" and "Secure" flags to the "expire"
> Set-Cookie header is just a waste of bytes because they have no effect
> whatsoever on what the client does with the cookie (it always deleted
> it, unless the system clock is set horribly wrong).

I haven't followed all of this discussion, but as for deleting a Cookie, I think the problem
is that there isn't an explicit "Delete-Cookie" header; but instead the server has to send
the cookie name with a "Expires" flag that is in the past.

In this case, I think if the original cookie contained a "Secure" and "HttpOnly" flag, then
the Set-Cookie header which deletes the cookie by setting an "Expire" date in the past also
should set the "Secure" and "HttpOnly" flags. Although it is unlikely that the client will
send back a Cookie which expires in 1970, it would be possible if the client's system date
is set wrong, so IMHO this is not an exact "delete this cookie" instruction and therefore
the "Expire" Set-Cookie header should include the same HttpOnly and Secure flags that were
included in the original Set-Cookie header.

Also, when deleting a cookie, I think it might be better to send a Set-Cookie header with
an empty value, so that the value is overwritten by the browser if for some reason the cookie
is not yet expired.

E.g., instead of
    Set-Cookie: JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, 01-Jan-1970 00:00:10
the server could send:
    Set-Cookie: JSESSIONIDSSO=; Expires=Thu, 01-Jan-1970 00:00:10 GMT

(RFC6265 Section 3.1 shows an example where a cookie is deleted this way)

Konstantin Preißer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message