asp.net-mvc - parameter - mvc required field validation

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

Question

En ASP.NET MVC (enrutamiento predeterminado), me gustaría usar una URL como esta para devolver una Vista con un formulario para editar un cliente:

/Customers/Edit/5

Necesito usar CustomerId=5 , pero no quiero permitir que un cliente lo cambie. Ahora mismo, hago la identificación oculta utilizando:

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

Esto logra lo que quiero, pero tengo la impresión de que las variables de formulario ocultas no son seguras y pueden ser manipuladas 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

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

De forma alternativa (o además de lo anterior) puede cifrar el campo oculto de acuerdo con este artículo

Answer 2

Hay dos aspectos. No estoy seguro de lo que estabas preguntando directamente, pero ambos son importantes:

• Para cualquier usuario dado, es posible que no se les permita editar a todos los clientes. Entonces, como sugiere Dmitry, la acción de su controlador para la publicación del formulario debe mirar al cliente al que está tratando de editar y verificar que el usuario que está conectado realmente puede editarlo. Es probable que también desee realizar 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 tienen permiso para editar el cliente solicitado.
• Para un usuario determinado y un cliente determinado, es probable que no desee que el usuario pueda cambiar la ID de cliente. Si está utilizando el método UpdateModel en su acción de controlador POST, debe usar el parámetro de la lista blanca de propiedades y excluir la propiedad de ID para que el usuario no pueda cambiar la ID. Incluso si cambian el valor del campo oculto, UpdateModel ignorará el valor modificado a través de la lista blanca.

Answer 3

La prueba de manipulación indebida de los campos ocultos está muy bien, pero eso sigue siendo 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 va a llegar a ninguna parte.

Answer 4

Mi solución fue utilizar el código de prueba de manipulación indebida del libro ASP.NET MVC de Steven Sanderson . La idea es que crees un hash de cualquier campo de formulario oculto que quieras falsificar:

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

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

Answer 5

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

Answer 6

Tenía la misma preocupación y mi solución al respecto era utilizar el cifrado. puede cifrar el valor de CustomerId en el lado del servidor y enviarlo como una cadena de consulta o un campo oculto para que el usuario no pueda cambiarlo y lo pueda descifrar cuando lo desee

Answer 7

Verifique 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 al usuario realmente se le permite editar los detalles del cliente solicitado, sin importar cómo invocó la acción.