IMO the risk is that instead of validating the ticket that the user would actually use the ticket before the intended user could.
The problem with using this argument against allowing non-SSL services, though, is that if I am an MITM attacker capable of intercepting http://xyz.com?ticket=ST-XXXXXXX , then it stands to reason I’ll be equally capable of intercepting all subsequent requests to that site, inclusive of the cookie headers, and am still able to hijack the session. FWIW, we’ve disabled non-SSL connections here, but it was more a way of forcing the admins of the other services to implement SSL and gain visibility into those who are not using it than it was a matter of securing CAS. CAS is secure by virtue of disallowing proxy tickets; it’s the other server which has the problem. -- Sean R. Baker Office #: (301) 319-0712 On Oct 22, 2014, at 10:14 AM, Adam Causey <[email protected]> wrote: > I understand the risk that proxying could pose by allowing non-https and > retrieving a service ticket. > > However, thinking about this additionally, is there actually a risk if > someone intercepted a ST for a non-proxy service? Doesn't CAS only send the > attributes back to the URL that was given the ticket? > > Let's say someone logs in and CAS sends an ST to http://xyz.com/ticket=ST-123 > and it is intercepted. The attacker would send a request > tohttps://thecasserver.com/cas/serviceValidate?ticket=ST-123&service=http://xyz.com > , but CAS would send the attributes back to http://xyz.com, correct? If the > attacker sent a different URL as the service then the validation would fail. > > > On Wed, Oct 22, 2014 at 9:38 AM, Jérôme LELEU <[email protected]> wrote: > Hi, > > Yes, using http can allow an attacker to steal a ST and try to use it before > the real user (the ST can only be used once). It's a problem, but it's "just" > one access / application. > > Big troubles come into play if the service allows proxy because this time, > the attacker could get a real SSO session. That's why by default, services > are not allowed to proxy in CAS 4.0. > > The proxy option should be enabled only when it's really necessary. > > Best regards, > Jérôme > > > > 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-10-22 15:25 GMT+02:00 Adam Causey <[email protected]>: > I would like some feedback on how others handle services that are non-https > (i.e. http://). Do most of you allow or disallow this? Currently we allow > non-SSL sites for some services, but are considering requiring https for > everything except locahost for developers. > > How much of a security concern is this? The only thought I have is that the > Service Ticket could potentially be sniffed and used, even though there is > only a 10 second window to use the ticket. > > Thanks! > > Adam Causey > Virginia Commonwealth University > -- > 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 -- 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
