Hi, I don't see any security issue as the disclosed value is an blank one, though I admit it would be better to have these flags for removal as well as creation (consistency).
I think it should be done at CAS level. It should not be too complicated. Would you mind submitting a pull request for that? Thanks. Best regards, Jérôme 2015-10-20 16:11 GMT+02:00 Andrew Scully <andrewscu...@gmail.com>: > Something picked up on by our penetration testing team is that, while the > "HttpOnly" and "Secure" flags are present when setting the CAS cookies > (e.g. CASTGC and CASPRIVACY), they are not present when the cookie is > removed. > > (Note: You cannot literally "remove" a cookie, you do so by setting it to > an empty string) > > This gets flagged up by some pen testing tools (such as OWASP ZAP) > although, since the response cookie value is actually blank, no sensitive > data can be disclosed to the client (in the case of HttpOnly) / > man-in-the-middle (int the case of Secure). > > org.jasig.cas.web.support.CookieRetrievingCookieGenerator doesn't override > #removeCookie() so the behavior from > org.springframework.web.util.CookieGenerator > is inherited, which doesn't respect the HttpOnly / Secure flags. > > > So obviously we can just override the cookie generator ourselves if we > want to change this, but I was wondering if anyone has an opinion to offer > on whether this should be done by CAS (or even Spring) instead? > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: lel...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
