Given the following scenario: CAS URL: https://cas.example.com Bogus unauthorized service URL: https://bogus.example.net Real authorized serviceURL : https://authorized.example.org
User is tricked (by phish, perhaps) to visit <https://cas.example.com/cas/login?service=https://bogus.example.net> The user does not have an SSO session, so is presented with the CAS Login Form. The user submits the form with the username, password, and login ticket POSTed in the body. CAS authenticates the user and creates/sets an SSO session CASTGT cookie in the user's browser which contains the session key for the SSO session (TGT). It appears that at this point, CAS verifies the "?service=" parameter against the registry of authorized service URLs. The user is presented with the "Application Not Authorized" error. However, by now the user has a valid TGT, and if they subsequently visit <https://authorized.example.org>, they will be able to utilize it to login via SSO. Is there any reason for concern here? I believe the scope of exposure is only limited to anyone who has access to the browser session (e.g. say, a publically accessible computer). But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? Or perhaps destroying the TGT if the service URL is unauthorized? Or am I missing something, or perhaps some best practices configuration of CAS to mitigate against this sort of situation? -baron -- Baron Fujimoto <[email protected]> :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
