I logged into the jasig wiki and looked for a way to comment on the page, but was unsuccessful (I do not believe I have permission). So I will just respond to this email with a suggestion on how to mitigate this attack. I'm pretty sure it works, but comments to things I overlooked and/or misunderstood.
When a protected resource in a CAS Service is requested the CAS Service should generates a ST Request ID (ST-RID) which is written into a cookie named ST-RID. The service then requests a ST with a service URL that contains the ST-RID in it. An example service URL might be https://service.example.com/M/authenticate?ST-RID=12345. The CAS Server can treat this URL just as it does any service URL. The CAS Server authenticates the user and returns a ST to the service URL (i.e. https://service.example.com/M/authenticate?ST-RID=12345&ST=ST-12-1234). Upon receiving a ST the CAS Service checks that there is a ST-RID in the URL and ensures it matches the ST-RID stored in the cookie. If ST-RID exists in the URL, exists in the cookie, and the values match the normal CAS flow continues. Otherwise an exploit attempt has been made and the flow should be handled differently (i.e. alert the user that an exploit was attempted and request a new ST using the above flow). I'm not sure if it covers all the cases, but it seems like it would fix the example provided the the example provided on "Mitigating Risk due to the Inherent Characteristics of Bearer Tokens". It also seems to align fairly close with the basic CAS protocol. It does prevent obtaining a ST prior to requesting a protected resource from the CAS Service. This could impact users of the RESTful API, but the suggested flow might not need to be performed when doing the RESTful API? Again let me know any thoughts on this suggestion. Regards, Rob Winch On Thu, Jun 10, 2010 at 9:36 PM, Scott Battaglia <[email protected]>wrote: > Dear CAS Community, > > The CAS Steering Committee was recently presented with a paper that > detailed some of the risks of protocols that use bearer tokens. The paper > specifically mentioned CAS, though just about all protocols that use bearer > tokens are subject to these risks. > > The Steering Committee has drafted a formal response to this paper and > encourages you to read it (the response specifically, but feel free to read > the paper also!): > > https://wiki.jasig.org/display/CASST/Mitigating+Risk+due+to+the+Inherent+Characteristics+of+Bearer+Tokens > > We've also started a document where the CAS community can collaborate on > best practices for securing their applications (its a bit sparse right now, > but we expect it to grow): > https://wiki.jasig.org/display/CASC/Client+Security+Recommendations > > We encourage you to read and contribute to this document. > > We take security and usability of the CAS Server and Clients seriously. > Future releases of the CAS Server and CAS clients will continue to take a > lead in implementing security and usability best practices in order to > protect users. Look for some of those to appear in the CAS Server 3.5 > release. > > If you have any questions, please do not hesitate to contact the steering > committee. > > Thanks > Scott > -- > Scott Battaglia > Chair, Jasig Central Authentication Service Steering Committee > (sent on behalf of the entire CAS Steering Committee) > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
