1

So I have a wildcard host on an Apache Server using mod_auth_openidc The relevant bits of my Apache config are:

<VirtualHost *:443>
ServerAlias *.sub.mydomain.com
OIDCRedirectURI https://sub.mydomain.com/oauth2callback
OIDCCookieDomain sub.mydomain.com

Is there anything that would prevent a user from authenticating with foo.sub.mydomain.com, then also being authenticated with bar.sub.mydomain.com without having to log in again?

Severun
  • 2,893
  • 1
  • 16
  • 22
  • As a follow up question, if I have two separate config files that do not use wildcard domains, what would prevent someone from authenticating with foo.mydomain.com, then changing the hostname in the header to bar.mydomain.com and sending the same cookie values to the new host? Since they are virtual hosts on the same server and both are backed by the same session store, would that work as an attack vector? – Severun Oct 09 '15 at 01:04
  • OK I setup a test configuration and the answer to the original question, is yes, once you authenticate with the above configuration, you are authenticated for any host at .sub.mydomain.com. The question in my second comment is still unresolved. If I modify the cookie domain and the domain in my header for the request, will I be able to access different domains on the same host? – Severun Oct 09 '15 at 01:15

1 Answers1

0

No, that works since the session cookie is set on sub.domain.com and as such received on foo.sub.mydomain.com as well as bar.sub.mydomain.com.

What you describe in the comment is not really an attack since it is the same user in the same browser. Sort of the equivalent of what is mentioned above, except handled manually in the browser... It would be a problem is you could somehow steal a cookie from another user but then again that would be an attack not specific to mod_auth_openidc and is impossible assuming everything runs over https and there's no malware in the browser.

If you really need separation you can split out in to virtual hosts and run a different mod_auth_openidc configuration in each host. Then the Apache cookies won't be reusable across the two hosts. Of course both hosts would still redirect to the OP for authentication and an SSO session+cookie may exist there that binds the two sessions together implicitly.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • Well long story short, is I was trying to get a single apache config to support multiple virtual hosts. What I want to prevent is someone who logs in with foo.sub.mydomain.com from accessing bar.sub.mydomain.com. I was trying to do it with a single virtual host apache config. I tried OIDCRedirectURI https://${HTTP_HOST}/oauth2callback and I also tried just /oauth2callback, hoping it would tack the host on the front, but neither seemed to work. It appears I have to be explicit w/ the OIDCRedirectURI parameter. – Severun Oct 09 '15 at 18:45
  • re: the attack vector, what I am postulating is, user logs in to foo, and gets a mod_auth_openidc cookie. He does not have access to bar, but gains access, by modifying the cookie he got from foo to look like it came from bar, then passes the same session id and bar as the hostname of the request. Question is, does mod_auth_openidc associate the cookie w/ the host on the server/sessione side, or does it just look up the session ID regardless of the host the cookie is being used on? Or is there some other feature of an https cookie or CSRF that prevents this? – Severun Oct 09 '15 at 18:49
  • in a single apache config, you would restrict access to bar by using the appropriate `Require claim :` directives. If only users from a particular OP A have access to "bar" and other do not, you would use `Require claim iss:A` – Hans Z. Oct 09 '15 at 19:00
  • See also: https://github.com/pingidentity/mod_auth_openidc/wiki/Authorization#3-access-to-different-url-paths-on-a-per-provider-basis – Hans Z. Oct 09 '15 at 19:01
  • Sorry if I'm not explaining myself very well. I ran the following test. I installed the plugin at http://editcookies.mozdev.org/. I split my config files into two, one for foo.sub.mydomain.com and one for bar.sub.mydomain.com with fqdn in my OIDCRedirectURI. Each with explicit fqdn cookie domains. I then logged in to foo. After logging in to foo, I used the edit cookies and copied/added a new mod_auth_openidc_session using the bar hostname instead of foo. I then put https://bar.sub.mydomain.com into my browser and mod_auth_openidc let me in to the domain I had not authenticatd against. – Severun Oct 09 '15 at 20:14
  • claims seem to come from the OP. I would need to add a claim for hosts that the user has access to and do something like "Require claim host:foo.sub.mydomain.com. My issue is that if I protect two virtual hosts on the same server with mod_auth_openidc, then a user can pick up a session from one virtual host and use it on the other virtual host (by modifying the domain in the cookie) and it will not force them to authenticate. Perhaps a config parameter like "session prefix" can be added that will prefix a session with some value that is different between virtual hosts. – Severun Oct 09 '15 at 20:45
  • So that session ID 123 gets stored as foo-123 (on the back-end) if the session prefix configuration is present. Then if I try to re-use the session ID on bar, the session lookup will fail as it will look for bar-123. Or at least store the hostname of where the session was assigned, so that sessions are specific to virtual hosts. My issue is I use the same OP for all of my virtual hosts and I want the user to have to authenticate with each virtual host separately. Should I open up a new topic for this, I seem to have digressed a bit from my original question ;) – Severun Oct 09 '15 at 20:50