How to prevent CAS from leaking user identity to arbitrary visited websites?

Question

Summary

evil.example.com could use a hidden frame to request a CAS ticket from corporation.example.net, then validate it to receive the username of the hapless user. This effectively deanonymizes the CAS user to any malicious site they visit.

• As a CAS server author/maintainer, how can I prevent deanonymization of my users?
• As a CAS user, how can I prevent deanonymization of myself?

Background:

CAS (Central Authentication Service) is a single sign-on system with a redirect-based flow:

1. Client page redirects to CAS server with a service parameter that is the URL of the client site.
2. CAS server authenticates user via an existing cookie, a login page, etc.
3. CAS server redirects to service URL with ticket parameter appended.
4. Client calls a server validation endpoint, exchanging the ticket for a username.

Attack

1. User has already authenticated with corporation.example.net's CAS server and their browser has the ticket-granting cookie for that domain.
2. User browses to http://evil.example.com/dancing-bunnies.html, which embeds http://corporation.example.net/cas/login?service=http://evil.example.com/attack.html as a frame. (Framing is less conspicuous than a redirect -- there's no security difference.)
3. The CAS server's /login endpoint in the frame sees that the user-agent already bears login cookies, so it blindly redirects to the service URL, plus a ticket: http://evil.example.com/attack.html?ticket=ST-abc123
4. evil.example.com reads the ticket from the querystring and GETs http://corporation.example.net/cas/validate?service=http://evil.example.com/attack.html&ticket=ST-abc123, which responds with yes\nalice\n.
5. evil.example.com now knows that the user is alice @ corporation.example.net.

Possible amelioration

1. Restrict the domain on service parameter URLs to a known safe set
2. Require user interaction before redirect back to client
3. Forbid framing (either with headers or scripting)

Any downsides to either of these? Are there other solutions?

Notes

• Restricting the service parameter to a string-match on a set of known safe URLs is probably impractical, since it's used by clients to carry state through the redirect process.

ETA: I will be very sad if your answer assumes the following...

• ...that the attack relies on cross-origin communication.
• ...that I'm claiming that this does anything other than deanonymize the user

Answer 1

It seems that CAS 3 has an extension point for Services Whitelisting as noted here: https://wiki.jasig.org/display/CAS/well-known+modifications

As you stated in your notes this should resolve your concern and should be available to you.

Answer 2

Disclaimer: I don't know CAS, but I think I understood what it does and how it works.

Your attack scenario is not possible this way - even if the corporate website would not have frame busting headers. These frame busting headers are more to avoid click-jacking, but that's another topic.

If the frame does a redirect, then only the frame content is redirected.

The evil site cannot access the anything of the frame it embeds (not even the URL), because it's in another site. If it could, then such scenarios would be possible, but all modern browsers (even since IE4 I think) disallow cross-site access, so the evil site cannot access the new URL and therefore has no access to the identified user of the IFRAME.

As a user you can protect yourself by always logging out and if any suspicious site asks for permissions, don't authenticate.

A good example of this scenario you mention is Facebook. Many sites embed Facebook commenting functionality and other stuff. But they don't get your user name in any way. If it would be possible to get the Facebook user name somehow (Facebook users rarely log off) then this would be a big security hole. You could apply for the bug bounty if you'd find a way to get it or to log on and post or vote in the name of the user.

Answer 3

That is a good question. However, my understanding of the CAS protocol is that when you call the /serviceValidate URI, CAS checks if the service ticket obtained from request parameter is available in the service registry AND then checks if the service is a registered service.

In your example, evil.example.com would not be registered so you should not be able to get the USER ID as the CAS server will throw you an unauthorized service exception ;).