Thanks everyone! What I didn't realize was that the service url was not only used for the redirect to the service but also used when validating the ticket. That makes so much sense since the service url is where the client is redirected back so the evil site, which have to provide its own url, will get a ticket that other services cannot use.
Again, thanks for taking your time to explain! Best Regards, Gabriel Falkenberg On Tue, Oct 14, 2008 at 3:25 PM, David Whitehurst <[EMAIL PROTECTED]> wrote: > Gabriel: > > I've had these questions asked of me as an implementor of CAS. I've > been scrutinized over a proposal to implement CAS for a state > organization by a large group of executive and security folks. There > are a few truly key points on why CAS is secure and why your scenario > can't happen: > > - A unique ticket is generated for the client machine by the CAS > server on request > > - An HTTPS request is generated, in isolation of the original request, > from the client machine and will pass back a unique ticket to that CAS > server along with a URL that describes the client service or > application. This ticket has to be the original ticket issued or the > process will fail. > > - The HTTPS request to the CAS server with the ticket is generated by > the client machine and protects the original request from being > hijacked. > > The second request, generated by the client, going back to the server > is very important. The unique ticket that was generated for that > client must go back to the CAS server and ... the CAS server should > check to see if that client application URL is registered to even use > CAS. > > I struggled with this because of great scrutiny over a solution that I > was sure in my mind was secure. I struggled to obtain a very clear > understanding. I needed to convey this understanding to others and it > was tough at first. I went through the source code and traced it's > execution. > > I hope this helps, > > David > On 10/14/08, Andrew Ralph Feller, afelle1 <[EMAIL PROTECTED]> wrote: >> Gabriel, >> >> As Dale mentioned, service tickets (ST) are generated by a specific CAS >> server for a specific application URL (the service parameter specified when >> users are redirected to CAS login servlet). Normally these tickets are >> expired after a single use, which is stated in the >> WEB-INF/spring-configuration/ticketExpirationPolicies.xml, >> however it is possible to reconfigure your CAS deployment to allow ST to be >> used for validation multiple times. I must speak a word of caution as I >> believe most people do not use this feature, so don't take this as a >> recommendation to do so. If ST were allowed to be reused, it would be >> possible for someone to get a hold of a ST and by knowing the URL of the >> application it was created for, they could have it validated by the CAS >> server and get back the user's username. >> >> In summary, you shouldn't worry about the scenario as it should not occur. >> >> HTH, >> A >> >> >> On 10/14/08 5:05 AM, "Dale Ogilvie" <[EMAIL PROTECTED]> wrote: >> >> >> The ticket you get back from CAS will only be valid for your own site. If >> you attach it to another service url, it will be invalid when validated by >> the other service. >> >> I think "service specific tickets" is the aspect of CAS that prevents stolen >> tickets from being useful, service tickets only compromise the service they >> are generated for. >> >> ________________________________ >> From: [EMAIL PROTECTED] on behalf of Gabriel Falkenberg >> Sent: Tue 14/10/2008 8:07 p.m. >> To: Yale CAS mailing list >> Subject: Stealing tickets by installing a CAS-client on attacker's site? >> >> Hi, I'm probably just missing something here but I have a question >> regarding the standard configuration of the 3.3 CAS server. Using the >> standard configuration what stops the following from happening: >> >> 1. I have a site which I know is visited by lots of students from a >> university that uses CAS >> >> 2. I install a CAS filter on my own site using the university's CAS >> server in gateway mode which takes everyone to the CAS server and back >> transparently. >> >> 3. The students that are logged in will bring back a ticket to my site >> so for every logged in student I get a ticket. >> >> 4. I take the ticket and paste into the URL of a real university site >> which uses CAS. >> >> 5. That site sends the ticket to the CAS server and I am logged in as >> the student I stole the ticket from. >> >> I am sure some aspect of CAS stops the above from happening but which >> aspect is it? Does the standard configuration needs to be changed in >> order to prevent the above scenario? >> >> Best Regards >> Gabriel Falkenberg >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> >> -- >> Andrew R. Feller, Analyst >> Information Technology Services >> 200 Fred Frey Building >> Louisiana State University >> Baton Rouge, LA 70803 >> (225) 578-3737 (Office) >> (225) 578-6400 (Fax) >> >> _______________________________________________ >> Yale CAS mailing list >> [email protected] >> http://tp.its.yale.edu/mailman/listinfo/cas >> >> > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
