Algo más seguro que los campos de formulario ocultos en ASP.NET MVC?

Question

En ASP.NET MVC (enrutamiento por defecto), me gustaría usar una URL como esta para volver una vista con una forma de editar un cliente:

/Customers/Edit/5 

Necesito hacer uso de CustomerId=5, pero no quiero para permitir a un cliente a cambiar Enderece ahora hago el id oculta usando:

<%= Html.Hidden("CustomerId") %> 

con esto se logran lo que quiero, pero estoy bajo la impresión de que las variables de formulario ocultos no son seguras y puede ser manipulado por el usuario final.

Entonces, ¿cuál es la mejor manera de permitir que un cliente edite su información pero no su ID?

Answer 1

Mi solución fue usar el código de corrección de manipulaciones de Steven Sanderson's ASP.NET MVC book. La idea es que se crea un hash de cualquier campo de formulario oculto que deseas prueba de manipulaciones:

<%= Html.Hidden("CustomerId") %> 
<%= Html.Hidden("CustomerIdHash") %> 

Cuando se envía el formulario, el código de Steven calcula entonces otra hash del CustomerId y se asegura de que es igual CustomerIdHash. Si lo hace, entonces no ha habido manipulación. Es un gran código, y vale la pena el precio del libro.

Answer 2

No realiza ninguna seguridad real en el lado del navegador. Puede colocar la ID del cliente en la cadena de consulta, pero el servidor debe validar si realmente se le permite editar ese cliente. Si no, devuelve un error.

Answer 3

Compruebe los permisos en la acción de su controlador (/ Clientes/Editar) antes de mostrar la vista correspondiente. Tenga en cuenta que el problema aquí no está en absoluto en su campo oculto: un usuario podría simplemente escribir "http://yoursite.com/Customers/Edit/10" en su navegador. Por lo tanto, debe verificar en su acción si el usuario tiene permiso para editar los detalles solicitados del cliente, sin importar cómo invocó la acción.

Answer 4

Hay dos aspectos. No estoy seguro de lo que usted preguntaba directamente sobre, pero son ambos importantes:

• Para cualquier usuario dado, no se les puede permitir editar todos los clientes. Por lo tanto, como sugiere Dmitry, la acción de su controlador para la publicación del formulario debe observar al cliente que están tratando de editar y verificar que el usuario conectado pueda editar ese cliente. Probablemente también quiera hacer una comprobación similar en la acción del controlador que genera el formulario de edición en primer lugar y ni siquiera les permita acceder al formulario si no pueden editar el cliente solicitado.
• Para un usuario determinado y un cliente determinado, probablemente no desee que el usuario pueda cambiar la ID del cliente. Si está utilizando el método UpdateModel en su acción de controlador POST, necesita usar el parámetro propiedad whitelist y excluir la propiedad ID para que el usuario no cambie la ID. Incluso si cambian el valor del campo oculto, UpdateModel ignorará el valor modificado a través de la lista blanca.

Answer 5

Estoy teniendo el mismo problema y creo que la solución implica el uso de claves sustitutivas. En cada tabla donde tengo una columna ID, también agrego una columna clave que es un Guid (uniqueidentifier en el servidor SQL). Ahora, cuando hago uniones o cualquier lógica interna, uso el ID pero el controlador usa la clave. Como es un Guid, es difícil adivinar cuál es el Guid de otro disco.

Como alternativa (o además de lo anterior) se podría cifrar el campo oculto de acuerdo con This article

Answer 6

Los campos ocultos a prueba de manipulaciones están muy bien, pero esa sigue siendo la seguridad a través de la oscuridad. Siempre es mejor asegurar un sitio web, más específicamente MVC, asegurando los controladores y las acciones. Entonces el usuario puede manipular todo lo que quiera y no llegarán a ningún lado.