Cómo detectar la manipulación campo oculto?

Question

En una forma de mi aplicación web, tengo un campo oculto que necesito para proteger frente a manipulaciones por razones de seguridad. Estoy tratando de llegar a una solución en la que puedo detectar si el valor del campo oculto se ha cambiado, y reaccionar de manera adecuada (es decir, con un genérico "Algo salió mal, por favor, inténtelo de nuevo" mensaje de error). La solución debe ser lo suficientemente seguro de que los ataques de fuerza bruta no son factibles. Tengo una solución básica que creo que va a funcionar, pero no soy experto en seguridad y me puede faltar totalmente algo aquí.

Mi idea es hacer dos entradas ocultas: uno llamado "important_value", que contiene el valor que necesito para proteger, y uno llamado "important_value_hash" que contiene el hash SHA del valor importante concatenado con una constante de larga cadena aleatoria (es decir, el misma cadena se utiliza cada vez). Cuando se envía el formulario, el servidor volverá a calcular el hash SHA, y comparar con el valor enviado de important_value_hash. Si ellos no son los mismos, la important_value ha sido manipulado.

Podría valores adicionales también concatenar con cadena de entrada del SHA (tal vez la dirección IP del usuario?), Pero no sé si es que realmente me gana nada.

Será este seguro? Alguien tiene alguna idea de cómo podría ser roto, y lo que podría / debería hacer para mejorarlo?

Gracias!

Answer 1

Sería mejor para almacenar el hash en el lado del servidor. Es concebible que el atacante puede cambiar el valor y generar su / su propio hash SHA-1 y añadir la cadena aleatoria (que pueden averiguar fácilmente esta fuera del acceso a la página repetidamente). Si el hash es en el lado del servidor (tal vez en algún tipo de caché), se puede calcular el hash y comprobar para asegurarse de que el valor no se ha alterado de ninguna manera.

Editar

He leído mal la pregunta con respecto a la cadena aleatoria (sal constante). Pero supongo que el punto original sigue en pie. El atacante puede crear una lista de valores de hash que se corresponden con el valor oculto.

Answer 2

Firma Digital

Su algo excesivo, pero esto no es diferente de sonidos cuando se firma digitalmente un correo electrónico saliente, para que el destinatario pueda verificar su origen y su contenido es auténtico. La firma del campo de manipulaciones sensibles puede ser liberado en el medio natural con su campo de manipulaciones sensibles con poco temor de indetectable manipulación, el tiempo que se protege la clave privada y verificar los datos y la firma con el público clave en la declaración.

Este esquema tiene incluso la propiedad ingenioso que puede limitar "firma" de conjunto muy protegida de los servidores / procesos con acceso a la clave privada, pero el uso de un conjunto mayor de servidores / procesos proporcionados con la clave pública a los envíos de formularios proceso .

Si usted tiene un muy sensible "do-not-sabotaje" campo y no puede mantener la firma de hash de la misma en el servidor, entonces este es el método que yo consideraría.

Aunque sospecho que la mayoría estamos familiarizados con la firma digital, aquí hay algo de Wikipedia para cualquiera de los no iniciados:

criptografía de clave pública - Seguridad

  

... Otro tipo de aplicación en   criptografía de clave pública es el de   esquemas de firmas digitales. Digital   esquemas de firma se pueden utilizar para   autentificación del remitente y   no repudio. En tal un esquema de una   usuario que quiere enviar un mensaje   calcula una firma digital de este   mensaje y luego envía esta digitales   junto con la firma del mensaje a   el receptor previsto. Digital   esquemas de firma tienen la propiedad   que las firmas sólo pueden ser calculadas   con el conocimiento de una clave privada.   Para verificar que un mensaje ha sido   firmado por un usuario y que no ha sido   modificó el receptor sólo necesita   conocer la clave pública correspondiente. En   algunos casos (por ejemplo, RSA) no existe   esquemas de firmas digitales con muchas   similitudes con los esquemas de cifrado. En   otros casos (por ejemplo DSA) el algoritmo   no se parece a ningún tipo de cifrado   esquema. ...

Answer 3

Si usted no puede manejar la sesión en el servidor, considere la encriptación de los datos con su clave privada y la generación de un HMAC para ello, envía los resultados que el campo oculto (s). A continuación, puede comprobar que lo que se devuelve partidos lo que se ha enviado porque, ya que nadie más conoce su clave privada, nadie más puede generar la información válida. Pero sería mucho mejor para manejar los datos 'no debe ser cambiado' en el lado del servidor.

Hay que reconocer que cualquiera lo suficientemente determinada puede enviar una solicitud HTTP a usted (su forma) que contiene la información que desean, que pueden o no tener ninguna relación con lo que la última vez que los envió.

Answer 4

Si no puede / no almacenará el lado del servidor de hash, tiene que ser capaz de volver a generar es del lado del servidor con el fin de verificar la misma.

Por lo que vale, también debe sal sus hashes. Esto podría ser lo que quería decir cuando dijo:

  

concatena con una constante de tiempo   cadena aleatoria (es decir, la misma cadena   se utilizará cada vez)

saber que si ese valor no es diferente por usuario / login / sesison, no es en realidad un valor sal.

Answer 5

Mientras que custodian la "constante de larga cadena aleatoria" con su vida, entonces su método es relativamente fuerte.

Para ir más lejos, se puede generar una vez / único "constante de cadena larga al azar" 's.

Answer 6

Lo que usted describe es similar a la parte de la aplicación requerida para lo que se denominan canarios y se utilizan para mitigar los ataques de Cross Site Request falsificación.

En términos generales, una entrada oculta dentro de un formulario HTML contiene un valor cifrado que se devuelve con una petición HTTP. Una cookie del navegador o una cadena que tuvo lugar en sesión contiene el mismo valor cifrado de tal manera que cuando el valor de entrada oculta se descifra y se descifra el valor de la cookie / sesión, los valores no cifrados se comparan entre sí - si no son idénticas, la petición HTTP no se puede confiar.

El valor cifrado podría ser un objeto que contiene propiedades. Por ejemplo, en ASP.NET MVC, la aplicación canario utiliza una clase que contiene propiedades para el nombre de usuario autenticado, un valor criptográficamente de pseudo aleatorio generado utilizando la clase RNGCryptoServiceProvider, el DateTime (formato UTC) en el que se creó el objeto y una sal opcional cuerda. El objeto se cifra entonces utilizando el algoritmo de cifrado AES con una clave de 256 bits y se descifra con la misma clave cuando la petición llega.