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?


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.


  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?


  • 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
  • I don't see how this situation is possible. Because of the Same-Origin Policy, the evil page does not have access to the URL of the frame (cannot steal the ticket) if it's from another domain (evil.example.com and corporation.example.com are two different origins). Have you tried this yourself or is this mere speculations? AFAIK, it's not possible.
    – Adi
    Commented Jun 11, 2013 at 20:49
  • @Adnan Basically, the evil page goes through the exact same flow a normal client would. I've written up a step-by-step of the attack; if you have a CAS server handy that you can auth with I could do a POC. Commented Jun 13, 2013 at 5:30
  • I do have a non-production CAS server. Please, write the PoC, it'd very interesting to try.
    – Adi
    Commented Jun 13, 2013 at 7:10
  • Well, I tried to write up a POC, but it looks like the CAS server I'm using for testing has frame-busting set up! I guess that's a pretty effective approach. (Any other attack I can think of would alert the user that something suspicious is going on -- pop-ups, redirect of the top-level page.) Commented Jun 13, 2013 at 16:40
  • 1
    Apologies, I believe I was the one misunderstanding your question.
    – Adi
    Commented Jun 13, 2013 at 20:37

3 Answers 3


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.


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.

  • 1
    "The evil site cannot access the anything of the frame it embeds (not even the URL), because it's in another site." ...unless the embedded page is on the same domain, which is true for this attack. evil.com/dancing-bunnies.html embeds the CAS login, which redirects to evil.com/attack.html. There doesn't even need to be cross-frame communication, frankly, since the inner page still tells the server the user's identity. Commented Jul 9, 2013 at 18:50
  • 1
    Also, I'm not aware of Facebook having a CAS endpoint. Even if they did, this attack does not allow impersonation, just deanonymization. Commented Jul 9, 2013 at 18:52

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 ;).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .