Child pages
  • Mitigating Risk due to the Inherent Characteristics of Bearer Tokens
Skip to end of metadata
Go to start of metadata

Jasig's CAS Steering Committee received a report of a putative CAS security vulnerability, as disclosed on 2010-03-02 in a Standford University research paper, "Towards a Formal Foundation of Web Security" (1). We will briefly summarize the issue here for context and to facilitate distributing this document as a security notice to the CAS community.

The following workflow provides a hypothetical attack scenario that exploits the vulnerability in question: An attacker Mallory authenticates to CAS and acquires a service ticket for a CAS-enabled service, Service M. Instead of following through with subsequent ticket validation, which renders the ticket invalid, Mallory crafts a URL that will cause the ticket to be validated. Mallory then tricks a victim, Alice, via social engineering or other means to click the malicious URL. Alice indeed clicks the URL causing the ticket obtained and shared by Mallory to be validated; Alice is now authenticated to Service M as Mallory. Alice proceeds to interact with Service M, possibly disclosing valuable personal information, and eventually ends her session. Mallory may then reauthenticate as himself to Service M and view Alice's private data.

The CAS Steering Committee acknowledges that this scenario does represent a potential vulnerability for security protocols based on bearer tokens. Moreover, it is well understood and accepted that CAS service tickets are bearer tokens that cannot be authenticated in themselves as belonging to a given user by CAS services; to change this would be to fundamentally change the CAS protocol.

How then to protect the user against this type of subterfuge? The research paper provides a number of technical solutions to enforce that ticket granting and validation are performed by the same individual. However, we believe that the suggested technical approaches are cumbersome and represent a poor compromise between security and usability. Simple application development guidelines for CAS services, on the other hand, could provide a simple and powerful mitigation strategy. For example, user interface guidelines that require prominent display of the identity of the current authenticated user would provide protection against this and other similarly targeted phishing attacks.

The CAS Steering Committee will develop and publish these guidelines and heartily encourage CAS adopters to follow them to the fullest extent possible. We encourage community and outside participation in this process.

Signed:
The CAS Steering Committee

References:

1. Akhawe, D., Barth, A., Lam, P. L., Mitchell, J., and Song, D., "Towards a Formal Foundation of Web Security," 2010.

  • No labels

1 Comment

  1. One simple thing that could be done without changing the CAS protocol is to reduce the service ticket timeout.  This is 300000 by default  (5 minutes), but I'd think that most sites could drop that down to 30 seconds or a minute without any problem.