Autenticación de Windows para proteger la API

3

Uno de mis colegas tiene una llamada a la API web que está comprobando que el usuario haya iniciado sesión y que su token coincida con lo que está en la sesión (gracias a todos por su ayuda). Digamos que esta es la capa azul.

Una vez que se haya confirmado que el usuario es quien dice ser, luego realiza una llamada a otra API en otro servidor (llamémosla capa roja). No estoy seguro de por qué no solo llama directamente a una capa, sino que asume que había una buena razón para este "Reflejo".

Dijo que evita que alguien llame directamente a la capa roja, y que solo la capa azul puede llamarlo. Le pregunté cómo y dijo Windows autenticación básica.

Ni siquiera miré su IIS, etc., pero asumo que hay una configuración de autenticación básica.

¿Cuáles son algunos de los riesgos que vienen a la mente en un escenario como este?

¡Gracias!

    
pregunta NullHypothesis 12.03.2014 - 14:11
fuente

3 respuestas

1

La autenticación básica es no Autenticación integrada de Windows. El primero utiliza nombres de usuario y contraseñas de texto simple; el último utiliza tokens Kerberos (generalmente) o NTLM. La autenticación integrada es lo suficientemente segura (tm) siempre que configure las ACL correctamente. Es un error común establecer que las ACL sean demasiado permisivas (los usuarios autenticados, por ejemplo) y confían en la incapacidad de un atacante para obtener cualquier token de Kerberos válido porque no tienen una cuenta en su dominio. Lo que es peor, es posible que un programador no verifique la autorización en absoluto y suponga que debido a que la llamada no solo falló totalmente en el nivel de IIS, debe estar bien.

Estas cosas son tontas; asegúrese de configurar las ACL para permitir que solo los usuarios que IIS está ejecutando en la capa azul accedan a la capa roja. Mientras hagas eso, es seguro; o, al menos, si alguien puede romperlo, tienes problemas más grandes.

    
respondido por el Reid Rankin 14.09.2015 - 01:18
fuente
0

si está destinado a ser ÚNICAMENTE para los usuarios en el servidor de Windows, entonces ninguno, tendrían permisos, y descifrarlos requiere una contraseña de administrador, por lo que si es una API / aplicación interna que usa la autenticación de Windows, el único temor es alguien para obtener una contraseña de administrador.

Lo que se refleja es algo que algunas personas llaman una "segunda opinión" con verificación, y ya que es la decisión final, es inteligente dejar que Red llame a Azul, porque si elude a Blue, su única preocupación sería Red. y como su amigo quiere 2 pases de verificación, debe pasar primero por Azul y luego por Rojo para asegurarse de que es el usuario real.

    
respondido por el Lighty 21.05.2014 - 10:03
fuente
0

Aquí hay un par de riesgos potenciales, dependiendo de la configuración exacta y los requisitos.

  1. Si los usuarios finales pueden obtener acceso directo a la capa roja y pueden obtener credenciales válidas, entonces tienen acceso ilimitado a la capa roja usando solo esas credenciales, omitiendo la verificación de autenticación en la capa azul por completo.

  2. Si la capa azul solo existe como una verificación de autenticación, es un punto adicional de falla, y si sufre una interrupción, el sistema se vuelve inutilizable incluso si la capa roja está funcionando correctamente.

  3. Si las credenciales para acceder a la capa roja no son exclusivas del usuario, pero sí a la aplicación de la capa azul, será más difícil saber si el acceso a la capa roja está realmente autorizado, ya que la capa roja será mucho más difícil. diciendo la diferencia entre un acceso autorizado y el acceso de un usuario con un token robado para la capa azul.

Al final, estos riesgos son probablemente bastante menores. No sé si la configuración implementada es necesariamente ideal, pero es probable que esté bien, y los riesgos que mitiga son mucho más graves. Es similar en diseño a muchas arquitecturas de múltiples niveles.

    
respondido por el Xander 17.12.2014 - 17:41
fuente

Lea otras preguntas en las etiquetas