Security concern allowing 127.0.0.1 (localhost) as allowed serviceID

[jehan procaccia]

Hello

developers ask us to allow serviceID of type https://localhost/*  or https://127.0.0.1/* in order to allow them to develop on their local machine ans test locally . 

As system and network administrators we are afraid that this opening of localhost serviceID might allow the entire world ( all Internet connected device and hence hackers !) to access our CAS server, allowing them for example to brute force the web login interface or whatever other mischief possible .

Is this a real security breach to allow serviceID like https://localhost/* , or we are anyway already exposed by our production services which allows https://*.our-domain.fr/* serviceID which could be also used by hackers if the spoof our urls  ?

thanks for your security advice regarding this question . 

 

[Jeremiah Garmatter]

I'm not sure if this would be less secure than any other service at least from a brute force perspective. The user still has to log in to your CAS instance. If you want to prevent brute forcing, you should employ some sort of account lockout after so many failed attempts or the CAS authentication throttling module (https://apereo.github.io/cas/7.0.x/authentication/Configuring-Authentication-Throttling.html). It could be problematic if you release several user attributes to the localhost serviceID though. Then anyone could receive the user info to their local service after a successful authentication.

I am a little confused how this would work from a technical standpoint. I don't know the CAS protocol that well, but if the CAS server has to communicate with the localhost service could there be a chance that communication breaks down as CAS tries to communicate with it's own localhost?

[Baron Fujimoto]

We have a similar situation. To mitigate the potential risks, we allow the localhost service registrations to facilitate developers  work, but only in our non-production CAS environments, and they must be on one of our networks (or VPNs) and not some random public IP address.

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/f278051d-a428-4232-8ccc-ac0bf042ff81n%40apereo.org.

--

Baron Fujimoto <ba...@hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum

[Ray Bon]

jehan,

A safer option would be to use a dev cas instance that is only accessible to subnets and VPN pools used only by the developers. As long as it's mostly stable (99% uptime), devs would be rarely inconvenienced. This assumes that you have a full dev infrastructure (LDAP, databases, etc).

Another option: name the laptop such that locally running applications have a url that is similar to your institution url, and also set up a self signed certificate for that url (root, intermediate, and one terminal cert for every subdomain). If your institution issues the certs instead (doing something like https://letsencrypt.org/ for non publicly accessible machines), then this approach could be pushed to all devs.

I can see a publicly available localhost service being a target for ne'er-do-wells.

You can tighten up your service Id regex by escaping operator characters to eliminate look-alike urls:

https://.*\.our-domain\.fr/.*

Note I added a '.' before the '*' assuming that your regex was hastily created and not indicative of the one being used.

Ray

---

From: cas-...@apereo.org <cas-...@apereo.org> on behalf of jehan procaccia <jehan...@gmail.com>
Sent: 12 July 2024 01:49
To: CAS Community <cas-...@apereo.org>
Subject: [cas-user] Security concern allowing 127.0.0.1 (localhost) as allowed serviceID