Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
>> >> HTTP/1.1 302 Found >> Set-Cookie: JSESSIONIDSSO= CF7B7727443A3AAD1AC3AA033E4D98BE; Expires=Thu, 01-Jan-1970 00:00:10 GMT >> (...) I filed this issue into bugzilla: https://issues.apache.org/bugzilla/show_bug.cgi?id=5 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Hi,
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Thursday, June 19, 2014 5:40 PM
> >
> > 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.
Yes, but what I meant is:
>From a human perspective, we know that the "Secure" and "HttpOnly" flags on a
>cookie which has an "Expires: 1970" date is irrelevant because it will
>immediately expired by the browser if the system clock is set correctly.
However, from a technical perspective, it is just a Set-Cookie header that sets
a Cookie name and value with some arbitrary "Expires" date; it is not an
explicit "Delete-this-cookie" instruction. While the expire date will lead a
browser to immediately expire the cookie, it is still a normal Set-Cookie
header that will set a cookie on a client with a valid value, but that
Set-Cookie header with the "Expires: 1970" parameter did not include the
"Secure" and "HttpOnly" flags that were set by the first "Set-Cookie" header,
so a client may assume that this cookie is no longer "secure" and "httponly",
therefore security scanners might report this.
Therefore, in my view, I think it would be better if that Set-Cookie header
with "Expires: 1970" would include the same Secure and HttpOnly flags that were
used in the first header.
> > 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.
I have not found any mentioning of "1970" in RFC6265. It just states in 5.2.1
("The Expires Attribute"):
" If the expiry-time is earlier than the earliest date the user agent
can represent, the user agent MAY replace the expiry-time with the
earliest representable date."
In 5.1.1, it states:
" Abort these steps and fail to parse the cookie-date if:
(...)
the year-value is less than 1601,"
so I'm not sure that there is a definition of an expire date of 0 ("Thu,
01-Jan-1970 00:00:00 GMT") to be an explicit expire operation.
> > 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? ;)
Thanks, I will look into providing patch (when I have some time :)
Regards,
Konstantin Preißer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Just to update, instead of using Valve I re-build the tomcat with following code while setting Expiry header "cookie.setSecure(request.isSecure())" in SingleSignOn class file. This works. In this way I can probably make it as secure or empty the value. -Original Message- From: Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) Sent: Thursday, June 19, 2014 7:47 PM To: Tomcat Users List Subject: RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat Ofcourse, I am not waiting :-) -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, June 19, 2014 7:44 PM To: Tomcat Users List Subject: Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Radha, On 6/19/14, 6:32 AM, Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Thanks Konstantin. This is what I am asking in my very first mail. > Why can't we empty the value in case Cookie is expired. > > Konstantin Kolinko, According to your suggestion planning to use Value > to change the Cookie. In the invoke() method of Valve, I need to get > the list of Cookies and If the Cookie name is "JSESSIONIDSSO" , we can > empty the value. Can you confirm whether above approach works? Wouldn't it be faster to try it (2 minutes) than to post to the mailing list and wait for someone to get back to you (4 hours, at this moment)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTovARAAoJEBzwKT+lPKRYhSYP/3e1QBB752UJGpbNsUaSdHvA 8A5kVD3ENUr1IOYVVqNW+tbPmeTlCeDsImralFG8ziDdzZ5fFS1Dj5XGlE6SnWTk F7ej6TmpG+N5Sc78iIVPWeOAWv8QZsWF7nvDUltkWaqem6tcL38MT8sCc7hI/K+U FLdWjVkyXk8zUBIQKdqyElZMI9CSkgCnSN/miUo4tHMC8P3BbfXQAbAe0w1PgG9V 4PZ+2iEaRbUqNvfH7T9ZoCBjWHgdseVOakz1r1HFrgyQE+rmUYhzy8bvvV9wcHsf JEP+Z4qRZcW/pmX0OLQBzuekzmoXtTafHSBRD7j5lOpTGtgBW04YZR0JWbyBXnUH Mcz+8fkUhRjtHVAa/Jjc4ZYkMAmKFuX9hzrhEBA5ryPrICKltsmW5nUNsUMMvCq9 OZN/ZudlqIe8Cyj+oduPPXSJivb35oMrTd5IWdFcEL9uVejG9Q7FxFupV63/LiQT Dn7uass4SWIxpJIp9J7Ea73UVMJQh/TfmCL4n9Oin5Ab1rEdFX2JtA345oZiuGRl fkmIVOZ0agSEMOISimV8Li5g/p0ezRpTkU3e2PktLKxIsqsrNp4Epkk2w/t41Eiq suSqUREMKA3KmxtLsJhuhynm10X7MQX9K5RIiPaJT1PdXhgkieeeT8czvUoblGm1 quN5VgZGv1wbGx8m/OKA =dWVv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Konstantin, On 6/18/14, 12:05 PM, Konstantin Preißer wrote: >> -Original Message- From: Christopher Schultz >> [mailto:ch...@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 >>> : >>>>> >>>>> 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/gqS5s3eFpoipq5Y74XQIOv
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Ofcourse, I am not waiting :-) -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, June 19, 2014 7:44 PM To: Tomcat Users List Subject: Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Radha, On 6/19/14, 6:32 AM, Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Thanks Konstantin. This is what I am asking in my very first mail. > Why can't we empty the value in case Cookie is expired. > > Konstantin Kolinko, According to your suggestion planning to use Value > to change the Cookie. In the invoke() method of Valve, I need to get > the list of Cookies and If the Cookie name is "JSESSIONIDSSO" , we can > empty the value. Can you confirm whether above approach works? Wouldn't it be faster to try it (2 minutes) than to post to the mailing list and wait for someone to get back to you (4 hours, at this moment)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTovARAAoJEBzwKT+lPKRYhSYP/3e1QBB752UJGpbNsUaSdHvA 8A5kVD3ENUr1IOYVVqNW+tbPmeTlCeDsImralFG8ziDdzZ5fFS1Dj5XGlE6SnWTk F7ej6TmpG+N5Sc78iIVPWeOAWv8QZsWF7nvDUltkWaqem6tcL38MT8sCc7hI/K+U FLdWjVkyXk8zUBIQKdqyElZMI9CSkgCnSN/miUo4tHMC8P3BbfXQAbAe0w1PgG9V 4PZ+2iEaRbUqNvfH7T9ZoCBjWHgdseVOakz1r1HFrgyQE+rmUYhzy8bvvV9wcHsf JEP+Z4qRZcW/pmX0OLQBzuekzmoXtTafHSBRD7j5lOpTGtgBW04YZR0JWbyBXnUH Mcz+8fkUhRjtHVAa/Jjc4ZYkMAmKFuX9hzrhEBA5ryPrICKltsmW5nUNsUMMvCq9 OZN/ZudlqIe8Cyj+oduPPXSJivb35oMrTd5IWdFcEL9uVejG9Q7FxFupV63/LiQT Dn7uass4SWIxpJIp9J7Ea73UVMJQh/TfmCL4n9Oin5Ab1rEdFX2JtA345oZiuGRl fkmIVOZ0agSEMOISimV8Li5g/p0ezRpTkU3e2PktLKxIsqsrNp4Epkk2w/t41Eiq suSqUREMKA3KmxtLsJhuhynm10X7MQX9K5RIiPaJT1PdXhgkieeeT8czvUoblGm1 quN5VgZGv1wbGx8m/OKA =dWVv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Radha, On 6/19/14, 6:32 AM, Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > Thanks Konstantin. This is what I am asking in my very first mail. > Why can't we empty the value in case Cookie is expired. > > Konstantin Kolinko, According to your suggestion planning to use > Value to change the Cookie. In the invoke() method of Valve, I need > to get the list of Cookies and If the Cookie name is > "JSESSIONIDSSO" , we can empty the value. Can you confirm whether > above approach works? Wouldn't it be faster to try it (2 minutes) than to post to the mailing list and wait for someone to get back to you (4 hours, at this moment)? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTovARAAoJEBzwKT+lPKRYhSYP/3e1QBB752UJGpbNsUaSdHvA 8A5kVD3ENUr1IOYVVqNW+tbPmeTlCeDsImralFG8ziDdzZ5fFS1Dj5XGlE6SnWTk F7ej6TmpG+N5Sc78iIVPWeOAWv8QZsWF7nvDUltkWaqem6tcL38MT8sCc7hI/K+U FLdWjVkyXk8zUBIQKdqyElZMI9CSkgCnSN/miUo4tHMC8P3BbfXQAbAe0w1PgG9V 4PZ+2iEaRbUqNvfH7T9ZoCBjWHgdseVOakz1r1HFrgyQE+rmUYhzy8bvvV9wcHsf JEP+Z4qRZcW/pmX0OLQBzuekzmoXtTafHSBRD7j5lOpTGtgBW04YZR0JWbyBXnUH Mcz+8fkUhRjtHVAa/Jjc4ZYkMAmKFuX9hzrhEBA5ryPrICKltsmW5nUNsUMMvCq9 OZN/ZudlqIe8Cyj+oduPPXSJivb35oMrTd5IWdFcEL9uVejG9Q7FxFupV63/LiQT Dn7uass4SWIxpJIp9J7Ea73UVMJQh/TfmCL4n9Oin5Ab1rEdFX2JtA345oZiuGRl fkmIVOZ0agSEMOISimV8Li5g/p0ezRpTkU3e2PktLKxIsqsrNp4Epkk2w/t41Eiq suSqUREMKA3KmxtLsJhuhynm10X7MQX9K5RIiPaJT1PdXhgkieeeT8czvUoblGm1 quN5VgZGv1wbGx8m/OKA =dWVv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Thanks Konstantin. This is what I am asking in my very first mail. Why can't we empty the value in case Cookie is expired. Konstantin Kolinko, According to your suggestion planning to use Value to change the Cookie. In the invoke() method of Valve, I need to get the list of Cookies and If the Cookie name is "JSESSIONIDSSO" , we can empty the value. Can you confirm whether above approach works? -Original Message- From: Konstantin Preißer [mailto:kpreis...@apache.org] Sent: Wednesday, June 18, 2014 9:35 PM To: 'Tomcat Users List' Subject: RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat Hi, > -Original Message- > From: Christopher Schultz [mailto:ch...@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 > > : > >>> > >>> 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 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) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Hi, > -Original Message- > From: Christopher Schultz [mailto:ch...@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 > > : > >>> > >>> 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 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) Regards, Konstantin Preißer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 > : >>> >>> 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). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJToaDcAAoJEBzwKT+lPKRYY98P/jGnvGM3nFZBN3pttDIqiV6K vKsxu1aUctQFECY0Sj4ZD4jG2C7Ydx2qx4MdEKUEzcVaP1kMdgWJIX75KvF0Dn+I /YbgMszpGzSRJ3pGZlVZi28I64hCxnw7K/Lt2+K6YXc4btOhdf4C4Et3xv6ykrXh C3MD97yRLeldeSVh78mCg4sYP5z6Ps1+Wwg6b11NN7f2qw5+KROfBLJY0575+cas po7+I7kn261XL+3JCjO1qdCOEO+32/9yjMZDf6qD1dJkmAgxtY/uVPapyrLp8pQJ M4ujXtiIjT+oTAEjtfMoWx37zNrXmM0WBj/5KIv9sZNE/hAxJ2HwpoH3qOC6M9NB WvzpS0lvS76vqgkleO7cW5sGuqpe0Q5tOqN8SlvJ9pEnKfPJFbnW7NT94zF5TUnh cZb2TZaB+rzqmHG178XMqv8fMQpuWlSc4bHtv+jNa79GTkSvS4ggLuw11/a8Ybic ggt4ztVwqafek8uxI9Al4wB8t78nHE4pFNwQBlWe7xTXF9KhfqKYUFyncd2UEiW6 t8bb1I7/ZHdEGHi6hCPpwA5/HM4s6egZgyXbP4dVIxWjXbIfMOcExUV/El48IZ3S Zj+ztxMQ6abJ/5YfjquDjDUoImSW+GnB0F52U9iJI5BUIKheHiBL/DTCB1Ihs/3M ahfaNFJlZ+ZALbSq+x5a =A2Gk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
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. 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. So is there any issue here with those flags? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
2014-06-18 12:13 GMT+04:00 Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) : > Thanks Konstantin for your quick reply. > Actually Security Scanners are thinking that "secure" and "httpOnly" flag is > not set and raising as issue. I would like to set these values by overriding > "setHeader" or "addHeader" in the ResponseWrapper, but not working. You cannot intercept setting it. You have to look into changing the header that has already been set. (A filter can do that in Tomcat 7 with Servlet 3.0 APIs. A Valve can do that on any version of Tomcat). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Thanks Konstantin for your quick reply. Actually Security Scanners are thinking that "secure" and "httpOnly" flag is not set and raising as issue. I would like to set these values by overriding "setHeader" or "addHeader" in the ResponseWrapper, but not working. Do you have any idea how we can add these flags to even for cleared cookies? I also understand there is no direct way of dealing the JSESSIONID and JSESSIONSSO cookies. IMO if tomcat is clearing the Cookie, tomcat can send with empty or NULL value instead of JSESSIONIDSSO cookie exact value. One can argue still this is vulnerable through MitM as the JSESSIONIDSSO cookie value is present. What do you think? -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Wednesday, June 18, 2014 1:27 PM To: Tomcat Users List Subject: Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat 2014-06-18 10:45 GMT+04:00 Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) : > Hi Tomcat Users, > > We are using Tomcat 6.0.37 version. I have few questions regarding > JSESSIONIDSSO cookie generated by tomcat. > As you know, in general each cookie needs to set "httpOnly" and "Secure" > flags. I understand both JSESSIONID and JSESSIONIDSSO cookies are maintained > by Tomcat for session management. The problem is sometimes "JSESSIONIDSSO" > cookie is not set to "Secure" and "HttpOnly" flags. For example from the > following two responses one time JSESSIONIDSSO is set and other one not. I > would like to know in some scenarios whether this is expected. Your input is > much appreciated. > I could not find any documentation related to this in tomcat.apache.org web > site. > Please help me. > > In different application, I could not find this cookie at all which is using > Tomcat 7.x. Is there any fixes between Tomcat 6.0.37 and Tomcat 7.x related > to JSESSIONIDSSO. > Is there any behavior change? > > HTTP/1.1 200 OK > Pragma: No-cache > Cache-Control: no-store > Expires: Wed, 31 Dec 1969 23:59:59 GMT > Set-Cookie: JSESSIONID=E6AA4F8CD91D557123B23F1FBCDAC137; Path=/admin; > Secure; HttpOnly > Set-Cookie: JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Path=/; > Secure; HttpOnly > Content-Type: text/html;charset=utf-8 > Date: Tue, 17 Jun 2014 16:18:27 GMT > Server: XYZ > Content-Length: 71916 > > > 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 code for clearing the cookie is in o.a.catalina.authenticator.SingleSignOn.invoke(...) [[[ cookie.setMaxAge(0); response.addCookie(cookie); ]]] The code for setting the cookie is in o.a.catalina.authenticator.AuthenticatorBase.register(...) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Regarding JSESSIONIDSSO Cookie maintained by tomcat
2014-06-18 10:45 GMT+04:00 Radha Krishna Meduri -X (radmedur - HCL TECHNOLOGIES LIMITED at Cisco) : > Hi Tomcat Users, > > We are using Tomcat 6.0.37 version. I have few questions regarding > JSESSIONIDSSO cookie generated by tomcat. > As you know, in general each cookie needs to set "httpOnly" and "Secure" > flags. I understand both JSESSIONID and JSESSIONIDSSO cookies are maintained > by Tomcat for session management. The problem is sometimes "JSESSIONIDSSO" > cookie is not set to "Secure" and "HttpOnly" flags. For example from the > following two responses one time JSESSIONIDSSO is set and other one not. I > would like to know in some scenarios whether this is expected. Your input is > much appreciated. > I could not find any documentation related to this in tomcat.apache.org web > site. > Please help me. > > In different application, I could not find this cookie at all which is using > Tomcat 7.x. Is there any fixes between Tomcat 6.0.37 and Tomcat 7.x related > to JSESSIONIDSSO. > Is there any behavior change? > > HTTP/1.1 200 OK > Pragma: No-cache > Cache-Control: no-store > Expires: Wed, 31 Dec 1969 23:59:59 GMT > Set-Cookie: JSESSIONID=E6AA4F8CD91D557123B23F1FBCDAC137; Path=/admin; Secure; > HttpOnly > Set-Cookie: JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Path=/; Secure; > HttpOnly > Content-Type: text/html;charset=utf-8 > Date: Tue, 17 Jun 2014 16:18:27 GMT > Server: XYZ > Content-Length: 71916 > > > 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 code for clearing the cookie is in o.a.catalina.authenticator.SingleSignOn.invoke(...) [[[ cookie.setMaxAge(0); response.addCookie(cookie); ]]] The code for setting the cookie is in o.a.catalina.authenticator.AuthenticatorBase.register(...) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Regarding JSESSIONIDSSO Cookie maintained by tomcat
Hi Tomcat Users, We are using Tomcat 6.0.37 version. I have few questions regarding JSESSIONIDSSO cookie generated by tomcat. As you know, in general each cookie needs to set "httpOnly" and "Secure" flags. I understand both JSESSIONID and JSESSIONIDSSO cookies are maintained by Tomcat for session management. The problem is sometimes "JSESSIONIDSSO" cookie is not set to "Secure" and "HttpOnly" flags. For example from the following two responses one time JSESSIONIDSSO is set and other one not. I would like to know in some scenarios whether this is expected. Your input is much appreciated. I could not find any documentation related to this in tomcat.apache.org web site. Please help me. In different application, I could not find this cookie at all which is using Tomcat 7.x. Is there any fixes between Tomcat 6.0.37 and Tomcat 7.x related to JSESSIONIDSSO. Is there any behavior change? HTTP/1.1 200 OK Pragma: No-cache Cache-Control: no-store Expires: Wed, 31 Dec 1969 23:59:59 GMT Set-Cookie: JSESSIONID=E6AA4F8CD91D557123B23F1FBCDAC137; Path=/admin; Secure; HttpOnly Set-Cookie: JSESSIONIDSSO=CF7B7727443A3AAD1AC3AA033E4D98BE; Path=/; Secure; HttpOnly Content-Type: text/html;charset=utf-8 Date: Tue, 17 Jun 2014 16:18:27 GMT Server: XYZ Content-Length: 71916 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 Thanks Radhakrishna
