Kim, Yes, an adversarial intermediary might intercept the Service Ticket request parameter in the course of the browser's request to the non-https-CAS-using-application.
The adversary might then use that service ticket to illicitly authenticate to the non-https-cas-using-service in the name of the user. You're correct that, in a normal CAS configuration, service tickets are one-time-use so that once the adversary does this, 1) the end user will experience an error if their request to login eventually reaches the target application, and 2) the service ticket isn't then useful for anything else -- the adversary gets to do this illicit login only once. So, it's better than intercepting an enduringly and widely valuable cleartext password. :) But it's still a problem. As has been noted elsewhere in this thread, validating that stolen ST might expose interesting user attributes if your CAS server is configured to release them. There's a more subtle problem here, though. What does the non-https-using application intend to do when the legitimate user presents a legitimate service ticket to the application? It validates the ticket with CAS, and then... what? Does it set a session cookie? Issue a JSESSIONID as a request parameter on a redirect? Since it's speaking with the user over http and not https, whatever interesting thing the application does in response to a successful login to track that successful login across subsequent requests is done in the clear such that an adversarial intermediary can go ahead and firesheep the session and hijack it subsequent to the service ticket validation. There's no substitute for SSL. I suggest frowning firmly at a proffers of a non-SSL-using CAS-reliant application and reminding that self-respect should impel use of SSL. :) Andrew On 09/29/2011 11:06 AM, [email protected] wrote: > I want to check the risk scenario for authorizing CAS services that > are not behind SSL, e.g. http://example.com/casapp > > Is the scenario that someone might intercept the ticket from the > redirect to the users browser? That is, they would get the ticket sent > in the clear to the user via the redirect then quickly before the user > could use it (or by blocking the user's communication with the target > host) use the ticket on the target host and gain access as the user? > > As I understand it, once the ticket is validated, it can't be > validated again. > > Is there another scenario? > > Best, > Kim > > > Kim Cary > Chief Information Security Officer > Pepperdine University > > > > <html><head></head><body style="word-wrap: break-word; > -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I > want to check the risk scenario for authorizing CAS services that are > not behind SSL, e.g. <a > href="http://example.com/casapp";>http://example.com/casapp</a><div><br></div><div>Is > > <http://example.com/casapp%22%3Ehttp://example.com/casapp%3C/a%3E%3Cdiv%3E%3Cbr%3E%3C/div%3E%3Cdiv%3EIs> > > the scenario that someone might intercept the ticket from the redirect > to the users browser? That is, they would get the ticket sent in the > clear to the user via the redirect then quickly before the user could > use it (or by blocking the user's communication with the target host) > use the ticket on the target host and gain access as the > user?</div><div><br></div><div>As I understand it, once the ticket is > validated, it can't be validated again.</div><div><br></div><div>Is > there another scenario?<br><div><br><div> > <span class="Apple-style-span" style="border-collapse: separate; > color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; > font-variant: normal; font-weight: normal; letter-spacing: normal; > line-height: normal; orphans: 2; text-align: -webkit-auto; > text-indent: 0px; text-transform: none; white-space: normal; widows: > 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; > -webkit-border-vertical-spacing: 0px; > -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: > auto; -webkit-text-stroke-width: 0px; font-size: medium; > "><div>Best,</div><div>Kim</div><div><br></div><div><br></div><div>Kim > Cary</div><div>Chief Information Security Officer</div><div>Pepperdine > University</div><div><br></div></span><br > class="Apple-interchange-newline"> > </div> > <br></div></div></body></html> > -- > 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
