No confíe en la URL ... ya que los datos PUBLICADOS pueden ocultar lo que realmente sucede.
La URL debe tratarse como un valor del lado del cliente y no se debe confiar de ninguna manera. Cualquiera puede alterar fácilmente la URL y puede crear fácilmente un POST para cualquier UserID .
Cualquier persona que pueda adivinar los nombres de las variables de ruta en ASP.NET MVC, puede poner datos inesperados en un controlador
Esto puede suceder de todos modos por manipulación de parámetros. Hay algunos consejos útiles en esta guía: enlace
Específicamente
¿Qué es? La manipulación de parámetros es un ataque en el que se modifican los parámetros para cambiar la funcionalidad esperada de la aplicación. Los parámetros pueden estar en un formulario, cadena de consulta, cookies, base de datos, etc. Discutiré los ataques que involucran parámetros basados en la Web.
¿Cómo se explota? Un atacante altera los parámetros para engañar a la aplicación para que realice una acción que no pretendía. Supongamos que guarda el registro de un usuario leyendo su ID de usuario de la cadena de consulta. ¿Es esto seguro? No. Un atacante puede manipular una URL en su aplicación
En MVC esto puede suceder a través del enlace de modelo:
El enlace del modelo es una gran característica de Model-View-Controller (MVC) que ayuda con las comprobaciones de parámetros, ya que las propiedades en el objeto Orden se completarán automáticamente y se convertirán a sus tipos definidos en función de la información del formulario. ... Solo tenga cuidado de limitar las propiedades que permite que se completen y, de nuevo, no confíe en los datos de la página para los elementos importantes. ...
Tenga en cuenta que uso el atributo [Bind (Exclude)] aquí para limitar lo que MVC está enlazando en mi modelo para controlar lo que hago o no confío. Esto garantiza que el ID de usuario no provenga de los datos del formulario y, por lo tanto, no pueda ser manipulado.
Por lo tanto, también debe tener cuidado de que los parámetros de formulario que no existen en su vista no puedan ser manipulados y agregados por un usuario malintencionado. Lo haría agregando el atributo Exclude :
public ActionResult Edit([Bind(Exclude="UserId")] Order order)
¿Este comportamiento es consistente en otros marcos MVC (Rails, etc.)?
No estoy seguro, pero no lo veo como una falla, ya que las verificaciones de permisos deben realizarse en los POST y en los GET. Su aplicación no debe suponer que una URL que se haya enviado POSTED tenga permiso para hacer esto solo debido a la falsa afirmación de que la URL con el formulario debe haberse cargado primero.
¿Cuáles son algunas formas de protegerse contra este tipo de resultados inesperados? ¿Deberían verificarse todos los POST con parámetros de URL?
El código simplemente debería decidir tomar la variable de ruta o la variable POST (si se le proporciona desde MVC como una variable de método llamada UserID , entonces ¿por qué no usar eso? No importa si fue de POST datos o la URL siempre que sea coherente), y luego tome todas las decisiones lógicas basadas en eso. Esto incluye la autorización inicial y también la lógica de procesamiento y de negocios; todos deben usar el mismo origen del valor para asegurarse de que las acciones solo se realicen cuando estén autorizadas.