The "Host" header
I recall seeing something in the CAS list archives about a possible security issue with this. I personally don't think that there is a security issue here, becuase even if someone falsifies the Host URL, they will be directed to another server (possibly their own) only to retrieve their own CAS ticket and username. If someone could elaborate on the security implications, I would love to hear.
Honoring HOST header is not secure
NOTICE: I believe this patch opens you to the "forged host header" security exploit whereby an Adversary can use a service ticket intended for an arbitrary other service to authenticate to the application using this patch.
This security issue is discussed at the CASFilter page.
-[~awp9]
Do it!
This is a pretty simple fix, only 3 files are affected. These are modified from the Java CAS Client 2.1.1 distribution.
- edu.yale.its.tp.cas.client.Util
- Add support to get the "Host" header if it doesn't have a serverName or serviceURL.
- edu.yale.its.tp.cas.client.filter.CASFilter
- Remove exceptions thrown when serverName and serviceURL are both null.
- edu.yale.its.tp.cas.client.filter.CASValidateFilter
- Remove exceptions thrown when serverName and serviceURL are both null.
Load-balanced SSL-to-unecrypted app servers
This patch also includes support for an SSL issue we needed to fix. We have a load balanacer which provides SSL support for non-SSL enabled application servers behind it. This causes the CAS Filter on the servers to think they are non-SSL servers and create a redirect URL with service=http://... This is bad as it causes security pop-ups in IE 6 and the users may end up using a non-SSL connection if the load balancer is set up wrong. The fix is for the load balancer to inject the "SSL-Https: on" header which we check for in the CAS Filter.