Hi

Thanks very much for confirming.

All the best

Michael

Am 29.08.14 11:50, schrieb Jérôme LELEU:
> Hi,
>
> Indeed, I'm refering to this default service pattern: ^(https?|imaps?)://.*,
> wherever you store your services registry.
>
> We should definitely remove it to force CAS deployers to define their own
> services or remove the unsecure protocol supports.
>
> Best regards,
>
>
> Jérôme LELEU
> Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj
> Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org
>
>
> 2014-08-29 11:43 GMT+02:00 Michael Wechner <[email protected]>:
>
>> Hi
>>
>> Thanks very much for your response.
>> Yes I agree that the problem are the people who are not fully aware of
>> the consequences, just as myself ;-)
>>
>> I guess you mean for example
>>
>> <cas:json-services-registry
>> config-file="file:/path/to/servicesRegistry.conf"/>
>>
>> right?
>>
>> I am currently using 3.5.2 and IIUC it is using
>>
>>         <bean
>>                 id="serviceRegistryDao"
>>         class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
>>             <property name="registeredServices">
>>                 <list>
>>                     <bean
>> class="org.jasig.cas.services.RegexRegisteredService">
>>                         <property name="id" value="0" />
>>                         <property name="name" value="HTTP and IMAP" />
>>                         <property name="description" value="Allows
>> HTTP(S) and IMAP(S) protocols" />
>>                         <property name="serviceId"
>> value="^(https?|imaps?)://.*" />
>>                         <property name="evaluationOrder" value="10000001"
>> />
>>
>> inside deployerConfigContext.xml, right? Or otherwise where is
>> "http*://**" currently configured?
>>
>> Thanks
>>
>> Michael
>>
>>
>> Am 29.08.14 10:58, schrieb Jérôme LELEU:
>>> Hi,
>>>
>>> It's a rather old article and you can't use the CAS server without a
>>> services registry anymore. But the idea remains the same.
>>>
>>> Defining precisely the possible services is more than a good practice, it
>>> should be mandatory for any CAS administrator. Never define http*://** as
>>> the only service, except for tests of course.
>>>
>>> Security requires time and efforts. One would never install a Linux
>> server
>>> and open all ports and allow directories for write to anyone: the same
>>> applies for the CAS server.
>>>
>>> We are heading more and more towards security and your proposal is close
>> to
>>> the ones we made (at the CAS AppSec working group):
>>> https://wiki.jasig.org/display/CAS/Proposals+to+mitigate+security+risks
>> and
>>> are implementing since 4.0.
>>>
>>> Since CAS 4.0, the CAS server doesn't also ship with the default handler
>>> (login = pwd).
>>>
>>> There is not issue with the CAS server security itself, the problem is
>> that
>>> people are not fully aware of all (the consequences of) the (default)
>>> settings. And things are going to be more and more restrictive to help
>> CAS
>>> deployers gain the right perspective on this.
>>>
>>> Any contribution will always be appreciated.
>>>
>>> Thanks.
>>> Best regards,
>>>
>>>
>>> Jérôme LELEU
>>> Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj
>>> Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org
>>>
>>>
>>> 2014-08-29 10:34 GMT+02:00 Michael Wechner <[email protected]>:
>>>
>>>> Hi
>>>>
>>>> I recently got aware of a possible phishing attack using the service
>>>> redirect, whereas it is described in detail at
>>>>
>>>> http://palizine.plynt.com/issues/2011Sep/sso-flaws/
>>>>
>>>> The solution seems to be rather simple, that one has to register the
>>>> services inside CAS, in order to prevent
>>>> redirects to mailicious URLs.
>>>>
>>>> Thinking about it some more I thought it might be best to enforce the
>>>> registration, which means by default
>>>> only redirects are being executed for services which are registered. The
>>>> configuration could be in a such a way,
>>>> that one could still alllow any service URLs, but one would have to
>>>> configure this explicitely and hence would be aware of the risk
>>>> explicitely.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>>
>>>> Michael
>>>>
>>>> --
>>>> 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-user
>>>>
>>
>> --
>> 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-user
>>


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

Reply via email to