"Threat modeling is an approach for analyzing the security of an application" (see https://www.owasp.org/index.php/Application_Threat_Modeling). One step in the threat modeling is the creation of a dataflow diagram (DFD) of the system so that all attack surfaces can be identified.
Global DFD of CAS interactions
- Visio Source File: CAS DFD.vsd
- Visio File in VDX format: CAS DFD.vdx
DFD of CAS protocol
- DIA format : cassecurity_protocol.dia
- VDX format : cassecurity_protocol.vdx
- DIA format : cassecurity_protocol_proxy.dia
- VDX format : cassecurity_protocol_proxy.vdx
Threats on "serviceValidate/samlValidate/proxyValidate" 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. The PGTIOU can also be stolen here. | 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. Or make it an option in the services manager to require a client cert. Other methods could be used such as basic auth (using a shared secret) or else IP filtering. This is less secure but easier to set up. Warning in the service manager that http is dangerous. Perhaps warning in the log file. Tool to look for more misconfigurations.
|
| Spoofing | An ST sent over http may be intercepted by an attacker and then sent to a service to spoof the client. | Should look at the later. It is a different attack surface. |
| 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". It maybe that this cannot be mitigated because you have to support gateway access: https://secure.example.com/cas/login?gateway=true&service=https://myfishing |
| Information Disclosure | It is easy to write bad patterns in the services registry when using ant patterns (this info needs validation). Here is an possible example (untested): This example doesn't work as * stands for anything except /. I made the test... http://example.*/myService for http://example.com/myService and http://example.fr/myService http://example.hostattacker.com/myService http*://example.com/myservice http://imanatacker.com//?foo=://example.com/myservice | Default to using regexp or other pattern matching that is not prone to failure. Document the pitfalls of ant matching in the security guide. |
| Information Disclosure | An attacker could construct a odd, but legal URI to trick the services pattern matching. See http://static.springsource.org/spring-security/site/docs/3.2.x/reference/springsecurity-single.html#request-matching for what spring security does. Here is an example of an odd, but legal path in a uri: /secure;hack=1/somefile.html;hack=2 | Ensure in the matching code that paths are normalized before matching against the service registry as spring security does. |
| 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.
|
| Spoofing | An attacker could try to fool a cas client with a cleverly constructed service ticket like ticket=ST-12345%26service%3Dhttps%3A%2F%2Fbadguy.com which decodes to: ST-12345&service=https://badguy.com. If a naive client pasted this in during serviceValidate in the ticket parameter, he could be validating a ticket intended for somone else. This behavior is not observed in mod_auth_cas or the java cas client. | Ensure that all outside inputs are properly decoded and encoded when used calls to CAS or other services. Write a security/hardening guide for CAS clients which contains all the needed advice for writing a secure CAS client in one place. |
| DoS | An overly large ticket might cause a denial-of-service or otherwise compromise the system. (However URI's are limited in length by most implementations). | Ensure that input is validated and that overly large inputs are discarded. Write a security/hardening guide for CAS clients which contains all the needed advice for writing a secure CAS client in one place. |
Threats on "/proxy" attack surface
| Type | Threat | Mitigation |
|---|---|---|
Information Disclosure | If HTTPS is not used, the PGT can be stolen, which is extremely critical as it represents as SSO identity. | Always use HTTPS for /proxy url. |
| Spoofing | The attacker can generate proxy tickets for other services and discover user's attributes. | Limit as much as possible the services definition : not a very efficient solution, we should never reach that point ! |
Threats on "proxy callbacks" attack surface
| Type | Threat | Mitigation |
|---|---|---|
Information Disclosure | If HTTPS is not used, the pgtIou and pgtId (=PGT) can be stolen. | Always use HTTPS for proxy callbacks. This is the default in CAS server : should we go further and disable completely the flag to disable HTTPS check ? |
| Spoofing | With a stolen pgtId, the attacker can try to forge proxy tickets by trying various services on /proxy url and discover user's attributes. | Limit as much as possible the services definition : not a very efficient solution, we should never reach that point ! |
| Information Disclosure | As the pgtId and pgtIou are send as GET parameters in the request, they can be stored in the logs of web servers or other network equipments. | Disable/clear logs for proxy callback urls. |
| DoS | A map with all pgtIou and pgtId must be saved to be able to associate user's identity (and pgtIou from /serviceValidate url for example) and PGT. Sending a lot of proxy callbacks with fake pgtIou and pgtId can fill the memory and cause the web application to crash. | Don't use default memory implementation. Use more advanced cache systems if they have be implemented to store pgtIou and pgtId. |
DFD of CAS tickets storage
- DIA format : cassecurity_tickets_storage_1.1.dia
- VDX format : cassecurity_tickets_storage_1.1.vdx
