> Are there any aspects of the cookie that are trusted, such as > expiration? If not I think we're entirely safe.
The FormsAuthenticationCookie is just a standard cookie (i.e., has the following properties: name, domain, expiration date, http only, path, secure, and value/values) containing a specially formatted value. The value is a serialized, encrypted, and encoded FormsAuthenticationTicket. The FormsAuthenticationTicket has the following properties: cookie path, expiration date, persistent (lasts across browser sessions)?, issue date, user name, user data, and version. When a user authenticates on an ASP.NET app, a FormsAuthenticationTicket is created, serialized, encrypted, and encoded & is stuffed into a FormsAuthenticationCookie's value field. The cookie path and expiration date are stored in both the cookie and the ticket and are validated on each subsequent request to ensure that the user can't tamper with them. If they don't match on subsequent requests when the cookie/ticket are validated, the cookie is destroyed and the request is treated as anonymous. The assumption was that the server-side encryption of the FormsAuthenticationTicket protected the web application from a malicious user modifying their FormsAuthenticationCookie or creating one from scratch. Without the machine's key, a user couldn't possibly encrypt anything that the server could decrypt. On the strength of this assumption, MS made the design decision not to maintain state about outstanding FormsAuthenticationCookie/Tickets on the server or in a database. If this assumption is false, a user can create a valid cookie that will grant them access as any user on the system without having to deal with a login screen. The reason this impacts CAS is because the logic related to CAS is never executed provided that an incoming request contains a FormsAuthenticationCookie & Ticket that validate successfully. If the ticket decrypts & the date and path match, the request is authenticated as the user name contained in the FormsAuthenticationTicket. The ServiceTicketManager workaround in the CAS client mitigates the crypto attack by strengthening the validation process. With the CAS client running with a service ticket manager, the FormsAuthenticationTicket isn't valid unless ASP.NET says it's valid _and_ the FormsAuthenticationTicket's UserData (which in the CAS client contains the CAS Service Ticket) resolves to a record in the server's memory and that the properties of that record match with the properties of the cookie and ticket. This way, even if a user created/encrypted/encoded a valid FormsAuthenticationTicket from scratch, the request would fail validation because the CAS service ticket is non-existent in the ticket or not present on the server side. The mechanism that is used in the example web site to 'kick' users off of the web application takes advantage of this by removing the service ticket record from the server. This causes the subsequent request with that ticket become invalid/anonymous and the cookie to be destroyed. The vast majority of ASP.NET web applications don't have this kind of protection. If it really is possible to create a valid FormsAuthenticationTicket from scratch, the entire security subsystem on every Forms Authentication-based ASP.NET web application is theoretically vulnerable... and Forms Authentication is by far the most popular authentication provider in ASP.NET. I'm very anxious to see what gets revealed at the conference and nervous about the aftermath... http://ekoparty.org/juliano-rizzo-2010.php -ScottH -- 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-user
