Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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
share|improve this question
    
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. –  Adnan Jun 11 '13 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. –  phyzome Jun 13 '13 at 5:30
    
I do have a non-production CAS server. Please, write the PoC, it'd very interesting to try. –  Adnan Jun 13 '13 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.) –  phyzome Jun 13 '13 at 16:40
1  
Apologies, I believe I was the one misunderstanding your question. –  Adnan Jun 13 '13 at 20:37
show 1 more comment

2 Answers

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.

share|improve this answer
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. –  phyzome Jul 9 '13 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. –  phyzome Jul 9 '13 at 18:52
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.