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]>:

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

Reply via email to