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 <[email protected] 
> <javascript:>>:
>
>> 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 <[email protected]>:
>>>
>>>> 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 [email protected] as: [email protected]
>>>> To unsubscribe, change settings or access archives, see 
>>>> http://www.ja-sig.org/wiki/display/JSG/cas-dev
>>>>
>>>>
>>> -- 
>>> You are currently subscribed to [email protected] as: 
>>> [email protected]
>>> To unsubscribe, change settings or access archives, see 
>>> http://www.ja-sig.org/wiki/display/JSG/cas-dev
>>>
>>> -- 
>> You are currently subscribed to [email protected] <javascript:> as: 
>> [email protected] <javascript:>
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/cas-dev
>>
>>
> -- 
> You are currently subscribed to [email protected] <javascript:> as: 
> [email protected] <javascript:>
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-dev
>
>
-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-dev

Reply via email to