¿Cómo evito los ataques de repetición?

Question

Esto está relacionado con otra pregunta que hice.En resumen, tengo un caso especial de una URL donde, cuando se le envía un formulario, no puedo confiar en las cookies para la autenticación o para mantener la sesión del usuario, pero de alguna manera necesito saber quiénes son y necesito para saber que han iniciado sesión!

Creo que se me ocurrió una solución a mi problema, pero es necesario desarrollarla.Esto es lo que estoy pensando.Creo un campo de formulario oculto llamado "nombre de usuario" y coloco dentro de él el nombre de usuario del usuario, cifrado.Luego, cuando el formulario se PUBLICA, aunque no recibo ninguna cookie del navegador, sé que han iniciado sesión porque puedo descifrar el campo oculto del formulario y obtener el nombre de usuario.

La principal falla de seguridad que puedo ver son los ataques de repetición.¿Cómo evito que alguien obtenga esa cadena cifrada y publique como ese usuario?Sé que puedo usar SSL para que sea más difícil robar esa cadena, y tal vez pueda rotar la clave de cifrado de forma regular para limitar la cantidad de tiempo que la cadena es válida, pero realmente me gustaría encontrar una solución a prueba de balas. solución.¿Alguien tiene ideas?¿ASP.Net ViewState impide la reproducción?Si es así, ¿cómo lo hacen?

Editar:Espero una solución que no requiera nada almacenado en una base de datos.El estado de la aplicación estaría bien, excepto que no sobrevivirá a un reinicio de IIS ni funcionará en absoluto en un escenario de jardín o granja web.Acepto la respuesta de Chris, por ahora, porque no estoy convencido de que sea posible asegurar esto sin una base de datos.Pero si a alguien se le ocurre una respuesta que no involucre la base de datos, ¡la aceptaré!

Answer 1

Si ingresa una marca de tiempo junto con el nombre de usuario y la contraseña, puede cerrar la ventana para reproducir ataques en un par de segundos.No sé si esto satisface tus necesidades, pero es al menos una solución parcial.

Answer 2

Si realmente no desea almacenar ningún estado, creo que lo mejor que puede hacer es limitar los ataques de repetición mediante el uso de marcas de tiempo y un tiempo de vencimiento corto.Por ejemplo, el servidor envía:

{Ts, U, HMAC({Ts, U}, Ks)}

Donde Ts es la marca de tiempo, U es el nombre de usuario y Ks es la clave secreta del servidor.El usuario lo envía de vuelta al servidor y el servidor lo valida volviendo a calcular el HMAC con los valores proporcionados.Si es válido, sabrá cuándo se emitió y puede optar por ignorarlo si tiene más de, digamos, 5 minutos.

Un buen recurso para este tipo de desarrollo es Lo que se debe y no se debe hacer en la autenticación de clientes en la Web

Answer 3

Hay varias buenas respuestas aquí y, al juntarlas todas, es donde finalmente se encuentra la respuesta:

1. Cifrado en bloque (con AES-256+) y hash (con SHA-2+) toda la información relacionada con el estado/nonce que se envía a un cliente.De lo contrario, los piratas informáticos simplemente manipularían los datos, los verían para aprender los patrones y eludirían todo lo demás.Recordar ...sólo se necesita una ventana abierta.

2. Genere un nonce único, aleatorio y único por solicitud que se devuelve con la solicitud POST.Esto hace dos cosas:Garantiza que la respuesta POST vaya con ESA solicitud.También permite el seguimiento del uso único de un conjunto determinado de pares get/POST (evitando la repetición).

3. Utilice marcas de tiempo para que el grupo nonce sea manejable.Guarde la marca de tiempo en una cookie cifrada según el punto 1 anterior.Deseche cualquier solicitud que supere el tiempo máximo de respuesta o la sesión de la aplicación (por ejemplo, una hora).

4. Almacene una huella digital "razonablemente única" de la máquina que realiza la solicitud con los datos de marca de tiempo cifrados.Esto evitará otro truco en el que el atacante roba las cookies del cliente para realizar un secuestro de sesión.Esto garantizará que la solicitud regrese no solo una vez, sino desde la máquina (o lo suficientemente cerca como para que al atacante le resulte prácticamente imposible copiar) a la que se envió el formulario.

Existen aplicaciones basadas en filtros de seguridad ASPNET y Java/J2EE que hacen todo lo anterior sin codificación.Administrar el grupo de nonce para sistemas grandes (como una empresa comercializadora de acciones, un banco o un sitio seguro de gran volumen) no es una tarea trivial si el rendimiento es crítico.Recomendaría mirar esos productos en lugar de intentar programar esto para cada aplicación web.

Answer 4

Podrías usar algún tipo de cadena de desafío aleatoria que se use junto con el nombre de usuario para crear el hash.Si almacena la cadena de desafío en el servidor en una base de datos, puede asegurarse de que solo se use una vez y solo para un usuario en particular.

Answer 5

En una de mis aplicaciones para detener ataques de "repetición", inserté información de IP en mi objeto de sesión.Cada vez que accedo al objeto de sesión en el código, me aseguro de pasar Request.UserHostAddress con él y luego lo comparo para asegurarme de que las IP coincidan.Si no lo hacen, entonces obviamente alguien distinto de la persona hizo esta solicitud, por lo que devuelvo nulo.No es la mejor solución pero es al menos una barrera más para detener los ataques de repetición.

Answer 6

¿Puedes usar memoria o una base de datos para mantener? cualquier ¿Información sobre el usuario o solicitud alguna?

Si es así, al solicitar el formulario, incluiría un campo de formulario oculto cuyo contenido es un número generado aleatoriamente.Guarde este token en el contexto de la aplicación o en algún tipo de almacén (una base de datos, un archivo plano, etc.) cuando se presente la solicitud.Cuando se envíe el formulario, verifique el contexto de la aplicación o la base de datos para ver si ese número generado aleatoriamente todavía es válido (sin importar cómo lo defina, tal vez pueda caducar después de X minutos).Si es así, elimine este token de la lista de "tokens permitidos".

Por lo tanto, cualquier solicitud repetida incluirá este mismo token que ya no se considera válido en el servidor.

Answer 7

Soy nuevo en algunos aspectos de la programación web, pero estuve leyendo sobre esto el otro día.Creo que necesitas usar un Mientras tanto.

Answer 8

(Los ataques de repetición pueden consistir fácilmente en una suplantación de IP/MAC, además, se le desafía en IP dinámicas)

No es sólo una repetición lo que buscas aquí, de forma aislada no tiene sentido.Simplemente use SSL y evite hacer nada a mano.

ASP.Net ViewState es un desastre, evítelo.Si bien PKI es pesada y está inflada, al menos funciona sin inventar sus propios "esquemas" de seguridad.Entonces, si pudiera, lo usaría y siempre optaría por la autenticación mutua.La autenticación sólo del servidor es bastante inútil.

Answer 9

ViewState incluye funcionalidad de seguridad.Ver Este artículo sobre algunas de las características de seguridad integradas en ASP.NET.Realiza la validación con la clave de la máquina del servidor en machine.config en el servidor, lo que garantiza que cada devolución de datos sea válida.

Más abajo en el artículo, también verá que si desea almacenar valores en sus propios campos ocultos, puede usar el LosFormatter clase para codificar el valor de la misma manera que ViewState usa para el cifrado.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

Answer 10

Si solo acepta cada clave una vez (por ejemplo, convierta la clave en un GUID y luego verifique cuando regrese), eso evitará las repeticiones.Por supuesto, si el atacante responde primero, entonces tienes un nuevo problema...

Answer 11

¿Se trata de WebForms o MVC?Si es MVC, podrías utilizar el token AntiForgery.Esto parece similar al enfoque que mencionas, excepto que utiliza básicamente un GUID y establece una cookie con el valor del guid para esa publicación.Para obtener más información al respecto, consulte el blog de Steve Sanderson: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Otra cosa, ¿ha considerado verificar la referencia en la devolución de datos?Esto no es a prueba de balas, pero puede ayudar.

Answer 12

Utilice https...Tiene protección de repetición incorporada.