iOS auth / auth con un servicio web REST

2

Actualmente estamos en la fase de diseño de un nuevo "Servidor Gateway" que queremos desarrollar. Nuestro servidor tiene un servicio de REST. Mi tarea es encontrar opciones viables para proteger el acceso al Servicio REST mencionado anteriormente (auth / auth)

Este servidor se utilizará en un entorno empresarial, lo que significa que tenemos un Directorio Activo / LDAP a nuestra disposición. La información que se me enviará a través de esta API es de gran valor y debe estar adecuadamente protegida en el dispositivo y en el servidor. La aplicación y el backend serán utilizados por los empleados, no hay usuarios públicos.

Vamos a utilizar un servidor de aplicaciones (Glassfish) como el componente base para nuestro backend. Quiero usar los mecanismos de seguridad incorporados, ya que quiero evitar inventar mis propias soluciones que probablemente sean inferiores.

¿Cuál es la mejor práctica para asegurar el backend del acceso no autorizado / no autenticado?

O más específicamente:

  • ¿Cómo podría asegurar el acceso al backend?
  • ¿Es una opción transmitir el nombre de usuario y la contraseña con cada solicitud realizada desde el dispositivo móvil al backend?
  • ¿Es una buena práctica validar el nombre de usuario / contraseña transmitidos con el LDAP?

Es bueno saberlo:

  • El servidor de puerta de enlace está detrás de un proxy inverso.
  • El usuario debe autenticarse con el nombre de usuario / contraseña cuando quiera replicar (conectarse al backend)
  • la comunicación entre el dispositivo y el backend se protegerá con TLS

Gracias

    
pregunta theXs 28.02.2013 - 15:38
fuente

1 respuesta

2

Hay defectos comunes en los sistemas de autenticación que deben evitarse:

  • En un entorno corporativo es importante terminar Autentificación inmediata. Si un empleado es despedido podrían buscar venganza, e incluso una ventana estrecha de nube de acceso será suficiente para causar pérdida monetaria grave.
  • fuerza bruta. Debe haber un sistema implementado para que las solicitudes de autenticación de límite de velocidad provengan de una dirección IP específica. El bloqueo de solicitudes hasta que una IP pueda resolver un Capthca es un buen enfoque que es usado por Google y otros.
  • Fuga de información a través de un canal inseguro. Esto es mitigado por TLS (o HTTPS). TLS tiene sus propios problemas y siempre está mal configurado de forma predeterminada. Asegúrese de que está utilizando suites de cifrado seguro (TLS V1 o posterior) y deshabilite las solicitudes de renegociación. Cualquier escáner de vulnerabilidades que valga la pena mostrara estas violaciones, y son un hallazgo común en la naturaleza.
  • Inyección y bypass de autenticación. Asegúrese de comprender Inyección LDAP .

Al forzar que cada solicitud contenga un nombre de usuario / contraseña resuelve el primer problema de la terminación inmediata. Si todas las solicitudes deben enviarse a Active Directory, solo hay un lugar para revocar el acceso. LDAP es una base de datos no relacional muy rápida y las solicitudes de filtro son muy rápidas (mucho más rápidas que SQL).

    
respondido por el rook 28.02.2013 - 19:17
fuente

Lea otras preguntas en las etiquetas