Re: [cas-user] Prevent phishing via service redirect by default
Hi On my localhost I have now replaced property name=serviceId value=^(https?|imaps?)://.* / by property name=serviceId value=^https://localhost.*|https://127.*|https://www\.wyona\.com.*; / which seems to work very well. Thanks Michael Am 29.08.14 11:59, schrieb Michael Wechner: 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 michael.wech...@wyona.com: 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=1001 / 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 michael.wech...@wyona.com: 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 cas-user@lists.jasig.org as: lel...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: lel...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@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-user
Re: [cas-user] Prevent phishing via service redirect by default
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=1001 / 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 michael.wech...@wyona.com: 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 cas-user@lists.jasig.org as: lel...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@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-user
Re: [cas-user] Prevent phishing via service redirect by default
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 michael.wech...@wyona.com: 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=1001 / 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 michael.wech...@wyona.com: 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 cas-user@lists.jasig.org as: lel...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: lel...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@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-user
