autenticación HTTP: identificar al cliente

Question

autenticación HTTP: identificar al cliente

#1 de Mark (1 votos)
#2 de Slicedpan (1 votos)
#3 de Lorenzo Dematté (0 votos)

1

Tenemos un sitio web, donde cada usuario tiene que iniciar sesión para acceder a un área privada. Dentro del área privada, hay información sobre el usuario, un perfil, que incluye información confidencial (domicilio, datos bancarios, etc.)

Naturalmente, seguimos las mejores prácticas aquí (hash fuerte, SSL con los algoritmos correctos, verificación de contraseñas débiles, etc.).

También ofrecemos una base API en OAuth para terceros. De esta manera, el usuario sabe a qué puede acceder una aplicación registrada, la aplicación no tiene que almacenar las credenciales del usuario, podemos limitar lo que la aplicación obtiene ... todos los beneficios habituales. Por ejemplo, la API puede leer la información del perfil, pero la información confidencial se borra u omite.

El problema es: tenemos una aplicación de terceros que decidió que el uso de la API no era bueno; en su lugar, solicita las credenciales, las almacena (en texto plano ...), y luego se autentica utilizando un POST. Y lee la información del usuario haciendo raspado de pantalla. En realidad, solo utiliza la información "pública", pero también puede acceder a la información confidencial que no nos gustaría revelar.

No estoy especialmente preocupado de que la aplicación filtre la información del usuario (creo que lo hizo de esta manera porque es descuidada / perezosa, no maliciosa), pero aún así es un comportamiento menos deseable. Y me hizo preguntarme: ¿hay alguna manera de manejar esta situación desde la raíz?

Quiero abordar el problema de la manera más efectiva, y estoy empezando a preguntarme: ¿hay una manera de permitir que el usuario inicie sesión SOLAMENTE a través de su página? ¿Para evitar que alguien más se autentique usando solo un POST? Según mi conocimiento, puede hacer que sea difícil hacerlo (usar identificaciones únicas en la página / encabezados, usar hashing del lado del cliente (Javascript), etc.) pero no hay manera de estar 100% seguro de la publicación. viene de "tu página". Pero no soy un experto en seguridad, por lo que me puede estar perdiendo algo. Y, en cualquier caso, ¿cuál es la mejor manera de mitigar el problema, haciéndolo poco práctico (pero con poca o ninguna carga para el usuario, sin captcha, lo que no solucionará el problema)?

EDITAR: para que quede claro: no estoy hablando de soluciones para "prevenir" el raspado de la pantalla. Ya tenemos mitigaciones para que sea difícil (y otros para que sea aún más difícil en la línea) que harán que esta aplicación en particular desista. Estoy hablando del proceso de inicio de sesión: ¿qué puede hacer para asegurarse de que el nombre de usuario y la contraseña provienen de su propio formulario? Uno de los "puntos de venta" de OAuth es que le da sus credenciales a alguien (google, twitter) en el que confía; de hecho, se le redirige a un formulario en el dominio "confiable". ¿Además de mirar la url, la procedencia de las credenciales se impone de alguna manera? Si es así, ¿cómo?

authentication http mutual

pregunta Lorenzo Dematté 17.06.2014 - 11:02

fuente

3 respuestas

Lea otras preguntas en las etiquetas authentication http mutual

Validación de la entrada de seguridad de la aplicación: validación de variables de entorno y archivos de configuración Protegiendo una PC con Windows

score 1 · Answer 1

Si están raspando la pantalla, interrumpa su raspador de pantalla cambiando su página web. Nombre el campo "contraseña" "nombre de usuario" y el campo "nombre de usuario" "contraseña". Introduzca un campo de formulario oculto con nombre aleatorio con contenido aleatorio que deba volver a publicarse durante el inicio de sesión. Introduzca cambios en la estructura de la página que no cambien la apariencia. Sé creativo.

El raspado de pantalla se basa en "puntos de referencia" en la página para encontrar el contenido importante. Si esos puntos de referencia cambian constantemente, la persona que escribe el raspador de pantalla tendrá que actualizarlo constantemente para que siga funcionando y, con suerte, recibirá el mensaje de que no debería estar haciendo las cosas de esta manera.

score 1 · Answer 2

Usando un CAPTCHA es generalmente una buena manera de desalentar la automatización. Sin embargo, esto puede desalentar los inicios de sesión legítimos, y el tercero siempre puede pasar el captcha al usuario.

Usted podría potencialmente poner en una lista negra las direcciones IP que el tercero está usando. Pueden evitar esto cambiando las direcciones IP, pero la molestia de hacerlo podría ser suficiente como un elemento disuasivo.

Se me ocurre que lo que hacen los terceros puede de hecho ser ilegal en algunas jurisdicciones. Si sus términos y condiciones deniegan el acceso a terceros que no utilizan la API de OAuth, entonces creo que esto es bastante claro. (Por favor, consiga el asesoramiento legal adecuado)

Incluso si no es ilegal, podría advertir a sus usuarios legítimos acerca de las aplicaciones de terceros que almacenan sus datos de manera incorrecta.

score 0 · Answer 3

Esto es lo que obtuve hasta ahora (es una mezcla de las otras (2) respuestas que obtuve hasta ahora, y la investigación personal: Para el desaliento "general" de la captura de pantalla:

Puede aleatorizar la identificación / clase del contenido que se está "raspando". (pero el raspador podría analizar el HTML más a fondo)
Para maldad adicional, incluso puedes agregar otro contenido, con id / class similar, que contiene contenido similar pero incorrecto y está oculto por css (pero el raspador podría analizar el CSS también)
Banear usuario-agente (pero el raspador puede fingir)
Puede prohibir la (s) IP (s) (pero es posible que desee permitir aplicaciones legítimas, y acceso web, desde el mismo cliente)

Ahora, puede evitar todos los problemas (al menos en mi caso, donde todo está detrás de un inicio de sesión) "asegurando" el inicio de sesión, o mejor, identifique al cliente como autorizado. El problema es que en el caso de una aplicación web, el "cliente" expone todo a simple vista: html, css, JS.

Por lo tanto, no tiene un lugar para los "secretos" en el cliente: todo lo que ve el navegador y el raspador también.

De todos modos, el enfoque de esta pregunta fue hacer que el inicio de sesión a través de la página web sea lo más difícil de replicar posible. Hasta ahora, eso es lo que he pensado:

Puede solicitar CAPTCHA al iniciar sesión (pero esto es malo para la facilidad de uso, y solo se puede pasar al usuario)
Puedes hacer autenticación de dos factores (mismo inconveniente)
Puedes usar algo como un token CSRF (pero como no está en una sesión, el cliente también puede "raspar" el token y enviarlo junto con el inicio de sesión POST)
Puede usar el hash del lado del cliente para marcar el token 'CSRF-like' y solicitarlo en la respuesta (pero esto puede ser "derrotado", ya sea leyendo el JavaScript e implementando el mismo hash, o ejecutando JS directamente)

Puede hacerlo cada vez más difícil, pero como el raspador puede imitar a un cliente web legítimo en todos los aspectos (y presentar al usuario lo que él / ella quiere también). Si implementa al menos 3 o 4, el "inicio de sesión automático" (solo publicando el nombre de usuario y la contraseña) ya no funciona, y podría ser un fuerte incentivo para usar OAuth en su lugar.

Así que no, por lo que sé, es imposible garantizar que el inicio de sesión provendrá de "su formulario", porque al final es solo un POST, y no hay manera de afirmar la identidad de "su formulario" . (Relacionado: falsificación de OpenID / phishing )