https://github.com/rubycas/rubycas-server/wiki#contribute

Thanks but I don't think it would be a good idea to send a PR without discussion the problem with the core members first. I guess they want to prepare a release too.

Hi @gregmolnar thanks a lot for you feedback.
I do not understand what you are afraid off by creating PR, could you explain that?
You have to remember that this is an open source project the rules here are simple, we all together working on that project. There is no secrets to hide. If there is a vulnerability, you just create an issue (with PR the best) and we will react on it as soon as possible. If the core team will not be able to provide solution fast enough, at least people will be able to use your fix or create own.
Do not wait, as if you found it, there is huge chance that someone else with "black hat" already did that.

If you still do not agree with publishing it as a regular issue with PR, please send the report to me on robert.mitwicki@opensoftware.pl I will take care of it as one of the core team.

best regards

I believe users of rubycas are not looking at github everyday but they probably have some kinda of a monitoring of the new releases so I guess in case of a security fix, a new release should be published quickly. But if someone just submits a PR and for any reason the core members doesn't really have the time to review it and release a new version, the vulnerability can be public for a period without a released fix.
Anyway I will send a PR soon.

The issue I am about to report been found in an older version of the gem. In that version it was possible to lock down the CAS server to a subdomain. Has that feature been removed? I made a simple app and had a play around but even if I set the allowed_service_ips I can be redirected to not allowed services too. Am I missing something?

I investigated this a little more and it looks like at my work someone patched rubycas-server to avoid an XSS token hijack vulnerability. I can't see any protection in rubycas master related to this.
The vulnerability is pretty simple and I created a POC app here: https://github.com/gregmolnar/cas-client-example. Basically you can just the service param in the URL, send the link to someone, he logs in, being redirected to your evil site, you get the ticket from the URL and redirect him to the correct URL. Than you can access to the service with the stolen token.
Am I missing something from the documentation or there is no protection for such a thing? I see there is an allowed_service_ips option but that doesn't seem to stop this happening.

allowed_service_ips is ignored if no allowed IPs are defined as you can see here.

I wrote it that way to be more backwards compatible since there was previously no way to limit what services could grab potentially sensitive information as you described. And I didn't want everybody upgrading to suddenly have a broken CAS server.

However, it might be a good idea to change to a more secure default of only allowing 127.0.0.1 or even treating an empty allowed_service_ips configuration as a "deny all". And then make configuring allowed IPs an explicit setup step in the README. At the very least the new rubycas-server-core should work that way I'd think.

As far as I see the ip_allowed? method is only called to verify the service when the service is calling rubycas. Which means it is steal possible to steal the token. Have you had a chance to look at the POC app?

Oh sorry, I should have read that more carefully. You're right ip_allowed? only protects against third-party servers getting user info, not stealing tokens.

Maybe I'm missing something again but if you were to get a ticket for http://stealyourtoken.com and then tried to use that token on say http://realsite.com, wouldn't authentication fail because the initial stealyourtoken stored service URL doesn't match the realsite service URL parameter that the realsite server would use to validate the token?

The code I'm referring to that does the service matching is here: https://github.com/rubycas/rubycas-server/blob/master/lib/casserver/cas.rb#L183.

I guess it is a proxy ticket by default so it is not locked to a service. At least in my POC I can access the app on localhost with the ticket issued to stealyourtoken.com.

When I try it out on some of our real sites I get the following error.

The ticket 'ST-1407797912rY78jOwbfxgQeF09-x7' belonging to user 'adam' is valid, but the requested service 'https://real.biola.edu' does not match the service 'https://bogus.biola.edu' associated with this ticket.

We're not using rubycas-client though and our client doesn't do proxy tickets. So it could have something to do with that.

Your setting is probably not the default. The app I linked is a default setup of casclient and casserver and that issues and validates a proxy ticket. A possible fix would be to add a whitelist of services to the server and don't redirect to anywhere else with a token in any setup.

Any of the core members had a chance to look into this? I am happy to send a fix but not sure what solution would be accepted by the core team.

@gregmolnar, just open the PR, and then will be able to discuss about proposed solution.