auth0-samples / auth0-cas-server Goto Github PK

It should be trivial to at least add some integration tests around the endpoints and flows exposed by the src/server.js file since the hosting of Express has been decoupled and moved into the index.js (local hosting) and webtask.js (webtask hosting) files.

Now that we have tests, let's enable CI, so we can get automatic builds for PRs and commits to master.

The CAS /validate endpoint (as well as the inherited /serviceValidate (CAS 2.0) and /p3/serviceValidate (CAS 3.0) endpoints) has a few minor security vulnerabilities:

1. Unlike the OIDC/Auth2 equivalent /token endpoint, the CAS /validate endpoint does not require any form of client credentials (eg. client_id/client_secret). Consequently if a malicious user were to intercept a ticket during the redirect back to the CAS application, then they could possibly call the /validate endpoint first and obtain the user's profile information. Luckily they wouldn't be able to authenticate as the user and log into the CAS application because that call would have to have been made from within the CAS application so that a local session could be generated.

2. However, if the malicious user was able to perform the above interception, they could simply complete the login flow with the CAS application first and thereby hijack the user's session. OIDC/OAuth2 solves this using the state parameter, which CAS doesn't have an equivalent of. In OIDC/OAuth2, the malicious user would not have the required cookie on their browser correlating the state parameter, so if they attempted to hijack the session using just the redirect URL, their call to the application server would be rejected.

One solution to improve security with the CAS /validate endpoint implementation in this sample would be to add IP filtering on the /validate endpoint so that only certain IPs (eg. those of the CAS applications) would be allowed to call the endpoint. This would guard against the first scenario above which would at least prevent a malicious user from obtaining another user's profile attributes. For this to work well with our sample, we'd need to confirm that external IPs can be detected in the Webtask environment as well.

At a minimum, we should include a security warning in the README.