asp.net - route - ¿Cómo evito los ataques de repetición?

select asp-for asp-items

Question

Esto está relacionado con otra pregunta que hice . En resumen, tengo un caso especial de 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 están conectados!

Creo que se me ocurrió una solución a mi problema, pero tiene que desarrollarse. Esto es lo que estoy pensando. Creo un campo de formulario oculto llamado "nombre de usuario" y coloco en él el nombre de usuario del usuario, encriptado. Luego, cuando los formularios POST, aunque no recibo ninguna cookie del navegador, sé que están conectados porque puedo descifrar el campo de formulario oculto y obtener el nombre de usuario.

El principal defecto de seguridad que puedo ver son los ataques de repetición. ¿Cómo evito que alguien se apodere de esa cadena encriptada y POSTing como ese usuario? Sé que puedo usar SSL para dificultar el robo de esa cadena, y tal vez pueda rotar la clave de cifrado de manera regular para limitar la cantidad de tiempo que la cadena es buena, pero realmente me gustaría encontrar una solución a prueba de balas. solución. ¿Alguien tiene ideas? ¿ASP.Net ViewState evita la reproducción? Si es así, ¿cómo lo hacen?

Editar : estoy esperando 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 una granja web o escenario de jardín. Estoy aceptando la respuesta de Chris, por ahora, porque no estoy seguro de que sea posible asegurar esto sin una base de datos. Pero si a alguien se le ocurre una respuesta que no involucra la base de datos, ¡lo aceptaré!

Answer 1

¿Se puede usar la memoria o una base de datos para mantener la información sobre el usuario o la solicitud?

De ser así, a petición del formulario, incluiría un campo de formulario oculto cuyos contenidos son un número generado aleatoriamente. Guarde este token en el contexto de la aplicación o en algún tipo de tienda (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 sigue siendo válido (independientemente de lo que defina válido, quizás puede 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ía este mismo token que ya no se considera válido en el servidor.

Answer 2

Podría usar algún tipo de cadena de desafío aleatorio 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 3

Si solo acepta cada tecla una vez (por ejemplo, convierte la clave en GUID y luego verifica cuándo vuelve), eso evitaría las repeticiones. Por supuesto, si el atacante responde primero , entonces tienes un nuevo problema ...

Answer 4

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

Answer 5

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

Answer 6

Si realmente no desea almacenar ningún estado, creo que lo mejor que puede hacer es limitar los ataques de repetición utilizando marcas de tiempo y un tiempo de caducidad 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 envía esto de vuelta al servidor, y el servidor lo valida volviendo a calcular el HMAC en los valores proporcionados. Si es válido, usted sabe cuándo se emitió y puede elegir ignorarlo si es anterior a, por ejemplo, 5 minutos.

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

Answer 7

(Los ataques de repetición pueden tratarse fácilmente de un spoofing de IP / MAC, además de ser desafiado en direcciones IP dinámicas)

No es solo la repetición lo que buscas aquí, de manera aislada no tiene sentido. Simplemente use SSL y evite hacer cualquier cosa a mano.

ASP.Net ViewState es un desastre, evítelo. Si bien la PKI es pesada e hinchada, al menos funciona sin inventar sus propios "esquemas" de seguridad. Entonces, si pudiera, lo usaría y siempre buscaría la mutua autentificación. La autentificación de solo servidor es bastante inútil.

Answer 8

En una de mis aplicaciones para detener los ataques de "repetición", he insertado 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 el Request.UserHostAddress con él y luego lo comparo para asegurarme de que las IP coincidan. Si no lo hacen, entonces, obviamente, alguien que no sea 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 9

ViewState incluye funcionalidad de seguridad. Consulte este artículo sobre algunas de las funciones de seguridad incorporadas en ASP.NET. Hace la validación contra el servidor machineKey en machine.config en el servidor, lo que garantiza que cada devolución 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 la clase LosFormatter para codificar el valor de la misma manera que ViewState lo utiliza 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

Hay varias buenas respuestas aquí y ponerlas juntas es donde la respuesta es:

1. El cifrado en bloque cifra (con AES-256 +) y hash (con SHA-2 +) toda la información relacionada con estado / sin conexión que se envía a un cliente. Los hackers simplemente manipulan los datos, lo ven para aprender los patrones y eludir todo lo demás. Recuerde ... solo toma una ventana abierta.

2. Genere un nonce aleatorio y único por solicitud que se envíe de vuelta con la solicitud POST. Esto hace dos cosas: asegura que la respuesta POST va con ESA solicitud. También permite rastrear el uso de una sola vez de un conjunto dado de pares get / POST (evitando la repetición).

3. Use marcas de tiempo para hacer manejable el nonce pool. Guarde la marca de tiempo en una cookie cifrada según el n. ° 1 anterior. Deseche todas las solicitudes anteriores al tiempo de respuesta máximo o la sesión de la aplicación (por ejemplo, una hora).

4. Almacene una huella digital digital "razonablemente única" de la máquina que realiza la solicitud con los datos cifrados de la marca de tiempo. Esto evitará otro truco en el que el atacante robe las cookies de los clientes para realizar el secuestro de la sesión. Esto asegurará que la solicitud vuelva no solo una vez sino desde la máquina (o lo suficientemente cerca como para que el atacante sea prácticamente imposible de copiar) a la que se envió el formulario.

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

Answer 11

¿Es esto WebForms o MVC? Si es MVC, podrías utilizar el token AntiForgery. Parece que es similar al enfoque que mencionas, excepto que utiliza básicamente un GUID y establece una cookie con el valor guid para esa publicación. Para más información vea 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 revisar la referencia en la devolución? Esto no es a prueba de balas pero puede ayudar.

Answer 12

Use https ... tiene protección de reproducción incorporada.