Thanks for the issue and keeping us posted... 2015-10-21 11:58 GMT+02:00 Andrew Scully <andrewscu...@gmail.com>:
> Raised a ticket: > https://github.com/Jasig/cas/issues/1230 > > Unfortunately my company requires CLAs before open source projects are > contributed to -- I've got the ball rolling. > > > On Tuesday, 20 October 2015 16:50:01 UTC+1, Jérôme LELEU wrote: >> >> Yes, first a Github issue to track the problem and then, if you can >> submit a PR, that's better. I don't think no CLA is blocking for a merge, >> for now, I tend to consider a pull request submission as an implicit of >> agreement of the CLA... >> >> 2015-10-20 17:38 GMT+02:00 Andrew Scully <andrew...@gmail.com>: >> >>> OK that sounds sensible. >>> >>> I'm not CLA'd for Apereo although this is something I'm currently >>> looking into. >>> >>> I can raise an issue in the interim? >>> >>> >>> On Tuesday, 20 October 2015 15:17:12 UTC+1, Jérôme LELEU wrote: >>>> >>>> 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 <andrew...@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...@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...@lists.jasig.org as: >>>> jasig-cas-dev+...@googlegroups.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...@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...@lists.jasig.org as: >> jasig-cas-dev+...@googlegroups.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: 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
