Child pages
  • Proposals to mitigate security risks
Skip to end of metadata
Go to start of metadata
IdentifierScopeProposalDevelopment complexityEffectivenessBackward compatibleTargetFeedbacks
SEC_1ServiceBy default, we could define a service which does not allow HTTP in its pattern matching, for the in-memory services registry (deployerConfigContext.xml file)EasyNot very useful in practice as almost all CAS deployers use their own services registry in production. But it’s a good way to make people aware of the “HTTP risk”Yes in most cases as almost nobody uses the in-memory services registry in production4.0 ?

Bill : +1 for 3.5.3 and 4.0

Handled by SEC_8

SEC_2aServiceAdd a allowHttpForService flag for the CAS server to define if the service can be in HTTP (/login, /validate, /serviceValidate urls) : false by defaultMediumUseful to make people aware of the fact they need to setup something to allow HTTP servicesNo, already existing HTTP services could not work any more without enabling this flag 

Bill : +1 for 3.6 or 4.0

Handled by SEC_8

SEC_2bServiceReuse the secure flag already used by the proxy handler to define if the service can be in HTTP (/login, /validate, /serviceValidate urls)MediumUseful to make people aware of the fact they need to setup something to allow HTTP servicesNo, already existing HTTP services could not work any more without enabling this flag 

Bill : +1 for 3.6 or 4.0

Handled by SEC_8

SEC_3ProxyChange the default value of the allowedToProxy flag to falseEasyUseful. It would avoid any security issue with proxy by disabling it by defaultYes in most cases. Services are already defined with their allowedToProxy flag. Only new deployement would be impacted or very specific mechanism using the default allowedToProxy flag value4.0 ?DONE for 4.0
SEC_4ProxyCheck proxy callback urls against the services registryMediumUseful. If a default truststore is used (all certificates trusted), it would avoid any unexpected proxy callbackNo, it can break proxies which are not declared in the services registry (though, services definition should match proxy callback urls generally) This check is more useful if we don't have an empty certificates store (not SEC_5)
SEC_5ProxySetup by default empty truststore and keystoreMediumUseful. It would avoid any call to an untrusted proxyNo. For CAS deployers who use proxies, it would stop to work unless they change the default CAS configuration4.1Implemented in 4.1
SEC_6ServiceWhen calling /validate and /serviceValidate urls, the CAS server should connect back to the application to check against the list of the trusted certificates using the checkAgainstCertificates flag defined for each service (false by default)MediumMight be useful. It would check the SSL certificate even if the url has already been checked, to avoid DNS attack.

Yes. This extra security feature must be enabled only in specific cases.

 

This check makes sense only if there is a empty certificates store (SEC_5)

Handled by SEC_8

SEC_7ProxyRemove critical information from the urls : use POST instead of GET requests for proxy callbacks and /proxy urlHard (clients must be upgraded as well)Useful. Avoid criticial information in logs or from being indexed...No. Very invasive change as clients should be also upgraded. Handled by SEC_8
SEC_8Proxy/ValidationInstead of performing a proxy callback to the client to deliver the PGTID and PGTIOU, or when returning attributes in general, we could have the PGTID (instead of the PGTIOU) embedded directly in the CAS response and the whole CAS response encrypted by the client public key. This kind of "PGT delivery" would be chosen by service (by default, we would keep the default PGT delivery : using a proxy callback).Hard (clients must be upgraded as well)Useful. Provide another way to ensure security with PGT.Yes. This new kind of PGT delivery would need to be enabled by service. Proposed by Bill. Possible for 4.1, 4.x and 5
SEC_9

Service+

Proxy

Encrypt/Hash the ticket registry as appropriate to avoid people either stealing or tampering with the registry, either in the wire, in memory or on disk.HardThis would be extremely useful to make the ticket registry secure out of the box even if the user does not take pains to encrypt his network traffic or disk storage.No. Not backward compatible with existing sessions. Not backward compatible to older CAS servers in the same cluster (there may be ways to work around this). Is backward compatible with old clients.4.1

Possible for 4.1, 4.x and 5.

Proposed by Jerome

SEC_10Service + ProxyRemove/encrypt/truncate sensitive information from the CAS log by default. For example TGT and ST is logged in the CAS log by default. Enable this for debug mode, but for production, this should not be logged by default. (Also consider proxyCallbackURL).MediumRemoves a simple to exploit way to break CAS security for someone with access to the log files.Yes4.1Default logger factory removes TGT. Done for 4.1
  • No labels