Proteger la interfaz no autenticada de ataques de adivinación

0

Actualmente me encuentro con una interfaz disponible públicamente; accesible al menos a través de formularios web / webviews y algunos protocolos sin estado (presumiblemente REST). En el pasado, este formulario le permitía ver su historial de reservas sin una cuenta, al ingresar su apellido, una identificación de reserva y un secreto compartido derivado de la identificación con la que realizó la reserva.

Debido a cambios legales, este secreto compartido ya no se puede utilizar. Por lo tanto, la interfaz ahora solo pide el nombre y la identificación, que considero abiertos a ataques de adivinación. Debido a los dispositivos heredados, no es posible introducir nuevos metadatos necesarios.

Conozco las recomendaciones de OWASP para reducir los ataques de adivinación ( Ralentizar los ataques de adivinación en línea y también Bloqueo de ataques de fuerza bruta ). Sin embargo, todas estas recomendaciones requieren un sistema de cuentas presente.

El bloqueo basado en IP no ayuda contra las herramientas modernas de ataque de implementación de proxy. También podría bloquear a muchos usuarios que se esconden detrás de IPs a granel (cable, grandes empresas ...).

Pensé en adaptar las cookies de identificación del dispositivo. Normalmente tienes la protección de un sistema de cuentas. Tal vez ayude a ralentizar la creación de una cookie de identificación de dispositivo y luego bloquear a los usuarios basándose en esto. De esta manera, cada solicitud de un usuario bloqueado sería mucho más lenta que solo disparar las solicitudes de formulario y las solicitudes legítimas repetidas serían lentas.

¿Existen prácticas recomendadas para proteger los formularios / servicios web de uso anónimo? Estoy bastante familiarizado con los mecanismos donde está presente un sistema de cuentas, pero esto es nuevo para mí.

¡Gracias!

    
pregunta Draugr 27.06.2017 - 11:43
fuente

0 respuestas

Lea otras preguntas en las etiquetas