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:
- Client page redirects to CAS server with a
service
parameter that is the URL of the client site. - CAS server authenticates user via an existing cookie, a login page, etc.
- CAS server redirects to
service
URL withticket
parameter appended. - Client calls a server validation endpoint, exchanging the ticket for a username.
Attack
- User has already authenticated with
corporation.example.net
's CAS server and their browser has the ticket-granting cookie for that domain. - User browses to
http://evil.example.com/dancing-bunnies.html
, which embedshttp://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.) - 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
evil.example.com
reads the ticket from the querystring and GETshttp://corporation.example.net/cas/validate?service=http://evil.example.com/attack.html&ticket=ST-abc123
, which responds withyes\nalice\n
.evil.example.com
now knows that the user isalice
@corporation.example.net
.
Possible amelioration
- Restrict the domain on
service
parameter URLs to a known safe set - Require user interaction before redirect back to client
- 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
ticket
) if it's from another domain (evil.example.com
andcorporation.example.com
are two different origins). Have you tried this yourself or is this mere speculations? AFAIK, it's not possible.