Incluso si hago cumplir HTTPS y uso tokens anti-falsificación, parece que la autenticación de Windows podría ser intrínsecamente insegura porque no requiere que el usuario pase explícitamente las credenciales del cliente al servidor.
En entornos donde la gente usa navegadores más antiguos que pueden no aplicar CORS (y especialmente si estas personas han desactivado el encabezado de referencia de su navegador por cualquier motivo), no estoy seguro de qué impediría que un sitio web malintencionado establezca una sesión en un nombre del usuario - ¡los usuarios ni siquiera tienen que iniciar sesión!
La confusión, para mí, todo se reduce a un punto: la autenticación inicial:
- Si tengo un sitio web alojado en algún dominio local, para simplificar, solo debemos referirnos a él como abc.com (aunque para una aplicación de intranet es probablemente solo una dirección IP).
- Un usuario válido de Active Directory abre su navegador y, sin saberlo, va a xyz.com (sin saberlo porque no sabe que se trata de una configuración de sitio malintencionada por uno de sus antiguos, pero ahora compañeros de trabajo despedidos y descontentos)
- xyz.com hace una solicitud válida a abc.com
La autenticación de Windows es, en verdad, algo así como una caja negra para mí: mi suposición aquí es que la solicitud a abc.com se considerará válida y la respuesta proporcionará la cookie de sesión necesaria para futuras solicitudes. En este punto, aquí están mis preguntas:
- ¿El navegador tendrá una cookie de sesión válida para futuras solicitudes de abc.com o el navegador eliminará la cookie de sesión porque no hay pestañas / ventanas activas abiertas para abc.com?
- Incluso si la cookie está marcada con HttpOnly, ¿no puede el atacante acceder a la cookie a través de TRACE o el navegador tiene una manera de notificar al servidor que la cookie ya no debe ser válida?
Si se puede evitar que el sitio web malintencionado acceda / secuestre una cookie, puedo ver cómo podría ser posible razonablemente asegurar un sitio web de intranet que utilice la autenticación de Windows exigir que un usuario, que aún no tiene un token antirrobo , pueda ingresar al sitio web accediendo a una página específica (página de destino), que primero solicitará que no devolvería ningún dato protegido, sino que devolvería la cookie de sesión válida y un token anti-falsificación en un encabezado personalizado de la respuesta. Todas las llamadas futuras tendrían que incluir el token anti-falsificación provisto por la solicitud anterior y si no lo hace, el usuario deberá ingresar nuevamente a través de la página de destino. Dado que este token anti-falsificación se mantendría en la memoria (por algo como un interceptor de solicitud), no debería ser accesible para javascript ejecutándose en otros dominios (y suponiendo que se haya tomado la debida diligencia para evitar que los ataques XSS accedan al token). Se emitirá un nuevo token con cada respuesta del servidor, el interceptor lo tomará y luego lo incluirá en el encabezado correspondiente en la siguiente solicitud del cliente al servidor.
Tenga en cuenta que esto es, por supuesto, todo asumiendo que no hay algún programa malicioso ejecutándose fuera del navegador.