Uso de cookies de subdominio con mod_auth_openidc

1

Entonces tengo un host comodín en un servidor Apache usando mod_auth_openidc Los bits relevantes de mi configuración de Apache son:

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

¿Hay algo que pueda evitar que un usuario se autentique con foo.sub.mydomain.com y luego también se autentique con bar.sub.mydomain.com sin tener que volver a iniciar sesión?

2
  • Como pregunta de seguimiento, si tengo dos archivos de configuración separados que no usan dominios comodín, ¿qué evitaría que alguien se autentique con foo.mydomain.com, luego cambie el nombre de host en el encabezado a bar.mydomain.com y envíe el mismo valores de cookies para el nuevo host? Dado que son hosts virtuales en el mismo servidor y ambos están respaldados por el mismo almacén de sesiones, ¿funcionaría eso como un vector de ataque?
    Severun
    9/10/15 a las 1:04
  • De acuerdo, configuro una configuración de prueba y la respuesta a la pregunta original es sí, una vez que se autentica con la configuración anterior, está autenticado para cualquier host en .sub.midominio.com. La pregunta de mi segundo comentario aún no está resuelta. Si modifico el dominio de las cookies y el dominio en mi encabezado para la solicitud, ¿podré acceder a diferentes dominios en el mismo host?
    Severun
    9/10/15 a las 1:15
0

No, eso funciona ya que la cookie de sesión está activada sub.domain.comy, como tal, se recibe foo.sub.mydomain.comtambién bar.sub.mydomain.com.

Lo que describe en el comentario no es realmente un ataque, ya que es el mismo usuario en el mismo navegador. Una especie de equivalente de lo que se mencionó anteriormente, excepto que se maneja manualmente en el navegador ... Sería un problema si de alguna manera podría robar una cookie de otro usuario, pero eso sería un ataque no específico de mod_auth_openidc y es imposible suponer todo se ejecuta a través de https y no hay malware en el navegador.

Si realmente necesita separación, puede dividirse en hosts virtuales y ejecutar una configuración mod_auth_openidc diferente en cada host. Entonces, las cookies de Apache no serán reutilizables en los dos hosts. Por supuesto, ambos hosts aún redirigirían al OP para la autenticación y puede existir una sesión SSO + cookie que une las dos sesiones juntas implícitamente.

7
  • Bueno, para resumir, estaba tratando de obtener una única configuración de Apache para admitir múltiples hosts virtuales. Lo que quiero evitar es que alguien que inicie sesión con foo.sub.mydomain.com acceda a bar.sub.mydomain.com. Estaba tratando de hacerlo con una única configuración de apache de host virtual. Probé OIDCRedirectURI https: // $ {HTTP_HOST} / oauth2callback y también probé solo / oauth2callback, con la esperanza de que tachara el host en el frente, pero ninguno parecía funcionar. Parece que tengo que ser explícito con el parámetro OIDCRedirectURI.
    Severun
    9/10/15 a las 18:45
  • re: el vector de ataque, lo que estoy postulando es, el usuario inicia sesión en foo y obtiene una cookie mod_auth_openidc. No tiene acceso a la barra, pero obtiene acceso modificando la cookie que obtuvo de foo para que parezca que proviene de la barra, luego pasa la misma identificación de sesión y barra como el nombre de host de la solicitud. La pregunta es, ¿mod_auth_openidc asocia la cookie con el host en el lado del servidor / sesión, o simplemente busca el ID de sesión independientemente del host en el que se esté utilizando la cookie? ¿O hay alguna otra característica de una cookie https o CSRF que lo previene?
    Severun
    9/10/15 a las 18:49
  • en una sola configuración de apache, restringiría el acceso a la barra usando las Require claim <key>:<value>directivas apropiadas . Si solo los usuarios de un OP A en particular tienen acceso a la "barra" y otros no, usted usaríaRequire claim iss:A
    Hans Z.
    9 oct 2015 a las 19:00
  • Ver también: github.com/pingidentity/mod_auth_openidc/wiki/…
    Hans Z.
    9/10/15 a las 19:01
  • Lo siento si no me estoy explicando muy bien. Ejecuté la siguiente prueba. Instalé el complemento en editcookies.mozdev.org . Divido mis archivos de configuración en dos, uno para foo.sub.mydomain.com y otro para bar.sub.mydomain.com con fqdn en mi OIDCRedirectURI. Cada uno con dominios de cookies fqdn explícitos. Luego inicié sesión en foo. Después de iniciar sesión en foo, usé las cookies de edición y copié / agregué un nuevo mod_auth_openidc_session usando la barra de nombre de host en lugar de foo. Luego puse bar.sub.mydomain.com en mi navegador y mod_auth_openidc me permitió ingresar al dominio contra el que no me había autenticado.
    Severun
    9/10/15 a las 20:14