|
Dom, I think you may be misunderstanding the nature of the potential exploit created by relying on the Host header. The adversary here is not the end user. The adversary here is host A, whether it's a malicious application or a previously wholesome application compromised to become malicious. An intended property of the CAS infrastructure is that it contains security breaches. Compromising an application to which users authenticate via CAS should not allow the adversary to compromise other hosts. This exploit allows an adversary, having compromised an application to then authenticate to *other applications* as users who authenticate to the compromised application, thereby spreading the security compromise. Let me try another explanation: The exploit involves the user authenticating to Host A, which instead of validating the ticket forges a request to Host B with a Host: header indicating A, and thereby executes an illicit proxy to Host B, authenticating as the user to host B despite the end user not having acquired a service ticket for B and host A not having acquired a PGT, PT targetted to B, B having had a chance to validate that PT and decide whether A is an authorized proxy, in the usual way. If B relies on the Host header, then A can forge the request such that B believes that it (B) is A, and so A can use service (or proxy) tickets intended to authenticate to A to instead illicitly authenticate to B. B's defense against this attack is stalwart self-awareness. By knowing that it is B, it will name itself as B when validating tickets with CAS, and so the CAS server will fail to validate tickets issued for the purpose of authenticating to A when B attempts to validate them. For CAS clients to be vulnerable to this exploit requires only that they put excessive faith in the requestor-set Host header, not that the CAS server involved implement complexities as to which users may authenticate to which applications. This exploit, and its solution, predates those CAS server features. Does this further explanation help? I have also updated the wiki page previously referenced to include this additional explanation. Andrew Andrew Petro Cooperative Support Technical Lead - uPortal Unicon, Inc. Hi Andrew, Thanks for your reply.Just in case I didn't quite digest the two explanations correctly in the FAQ. A user that has access to only a subset of services that have been CASified can gain access to all services by forging the host entry. The user would have to first authenticate against a service they do have access to, creating a valid service ticket, then forge the host entry and switch to another service they didn't have access too. If this is correct and in my implementation all users have access to all services, I could have confidence in allowing the host entry to construct the service url. Because in order to exploit this security issue the user has to have access to at least one service. Dom _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas |
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
