...
Threats on "serviceValidate/samlValidate" attach attack surface
| Type | Threat | Mitigation |
|---|---|---|
Information Disclosure | An ST sent over http may be intercepted by an attacker and then sent to CAS to retrieve the attributes for that user. | Hardening guide to include dangers of including http services in service manager uri patterns. Change Service Manager default configuration to not generate and ST for a http based service. The current default has http://* in the list of valid services. Validate server identity using a client Cert sent in the serviceValidate call. |
| Information Disclosure | An attacker may probe for a misconfigured CAS server by asking for service ticket for various services at /login or at /serviceValidate until it finds a URI that should not be able to get tickets, but can if it can take over that URI. | At /serviceValidate, ensure that if the ticket is not valid, then the response is always the same and does not reveal anything about the service registry. At the login URI, only disallow the call for an "invalid" service, once a user supplies a password, so that at least only authenticated users can do this probing. Or lock down an account that makes too many login calls with an invalid "service". |
| Information Disclosure | It is easy to write bad patterns in the services registry when using ant patterns (this info needs validation). | Default to using regexp or other pattern matching that is not prone to failure. Document the pitfalls of ant matching in the security guide. |
| Spoofing | There is a well-known threat to CAS clients where an unauthorized proxy may be possible if the CAS client trusts the HOST header in the request. A recently written CAS client is known to have this problem and there are probably others. | Write a security/hardening guide for CAS clients which contains all the needed advice for writing a secure CAS client in one place.
|
...