tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Date Thu, 19 Jun 2014 15:40:08 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Konstantin,

On 6/18/14, 12:05 PM, Konstantin Prei├čer wrote:
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Sent: Wednesday, June 18,
>> 2014 4:23 PM To: Tomcat Users List Subject: Re: Regarding
>> JSESSIONIDSSO Cookie maintained by tomcat
>> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> Konstantin,
>> 
>> On 6/18/14, 5:34 AM, Konstantin Kolinko wrote:
>>> 2014-06-18 11:57 GMT+04:00 Konstantin Kolinko 
>>> <knst.kolinko@gmail.com>:
>>>>> 
>>>>> 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.

Correct.

> 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.

The point is that the "Secure" and "HttpOnly" flags are irrelevant if
the cookie is being expired.

> 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.

I wonder if the spec says something about the minimum date of the
Expires attribute. I'm not going to look it up, but I'll bet that
Expires values prior to start-of-UNIX-epoch are invalid, so basically
timestamp=0l is, by definition, an expire operation regardless of the
client's current clock.

> 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 GMT 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)

Seems like a reasonable request, although it should not matter one
bit. Want to create a BZ request for this? Perhaps even a patch? ;)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJTowRYAAoJEBzwKT+lPKRYUmkP/1csmbspAUI0PE8DlZukTMN6
jOKFJMJIJxTv3zOZc7jcDnUvXAwqrLvgxfylDim1MItEhhGfioi0LhCIjXuU7k9f
SyWG3l+pCJmYx68qXeOcyky7QVuWsVMtFhx/gqS5s3eFpoipq5Y74XQIOvq6CQ75
18HA7R6vXB5mtTJwvd59ICwitVmoQrYPNCF8HLnFVHLCvPYeeRVBt9PgDL7nMLRo
7viE5QIFII2G/ss5sRXzFRTHkV9xrwZ9J0N4q5+ivVr47CakLwzJLh2NUbExXL+u
gYfLKaVH2A6pCEacOtQgeamv6DTiKe+xdyclgyERRD04tQtjnGe1rIrH7ndwbH7z
Gz28BiNPGKF5vGerWcIRngPZ0/uHRVgc5/F8TytbEHVTFVTSXZq70jl2wEzMCXRk
C5iEXkyBLX7EmnnwAvCKKHc23vFMQG63Un4afHNXr7rabD8zQIeg5c9kEyDf9epx
rnePt4tgSv9ajWpSpUMqcHlZhVPk4GtdmrGQ+1blr4iygvwmf0Ew2is5nZOB2SVC
0Jz3/D40VrwkMHEv7wXPsZueMhX33yCTnavGuV5zerg1VpF1ghjcz1dxsEE6KJlS
VK8NPSr8zDvdBwvIeNFMT26frK11IQcwWohbQyJCkpOh8vKV9kI00yIPqQG9ccSg
H7OXzMdSg9Rph+ANAsjd
=wLAE
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message