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:
- Client page redirects to CAS server with a
serviceparameter that is the URL of the client site.
- CAS server authenticates user via an existing cookie, a login page, etc.
- CAS server redirects to
- Client calls a server validation endpoint, exchanging the ticket for a username.
- 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 embeds
http://corporation.example.net/cas/login?service=http://evil.example.com/attack.htmlas a frame. (Framing is less conspicuous than a redirect -- there's no security difference.)
- The CAS server's
/loginendpoint in the frame sees that the user-agent already bears login cookies, so it blindly redirects to the service URL, plus a ticket:
evil.example.comreads 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
evil.example.comnow knows that the user is
- Restrict the domain on
serviceparameter 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?
- Restricting the
serviceparameter 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