Pregunta

¿Cómo se asegura adecuadamente de que un usuario no esté alterando los valores de la cadena de consulta o los valores de URL de acción? Por ejemplo, puede tener una acción Eliminar comentario en su CommentController que toma un CommentID. La URL de acción podría verse como / Comentarios / Eliminar / 3 para eliminar el comentario con la identificación 3.

Ahora, obviamente, no desea que nadie pueda eliminar el comentario 3. Normalmente, el propietario del comentario o un administrador tiene permiso para hacerlo. He visto que esta seguridad se aplica de diferentes maneras y me gustaría saber cómo lo hacen algunos de ustedes.

¿Realiza múltiples llamadas a la base de datos para recuperar el comentario y comprobar que el autor del comentario coincide con el usuario que invoca la acción de eliminación?

¿En su lugar, pasa el CommentID y el UserID al procedimiento almacenado quién realiza la eliminación y hace un Delete donde UserID y CommentID son iguales a los valores pasados?

¿Es mejor cifrar los valores de la cadena de consulta?

¿Fue útil?

Solución

No lo haces.

Es una regla fundamental de programación, especialmente hoy en día, que nunca confíes en ninguna entrada que provenga del usuario, el navegador, el cliente, etc.

También es una regla fundamental de programación que probablemente no intentes implementar el cifrado y la seguridad tú mismo, a menos que realmente sepas lo que estás haciendo. E incluso si sabes lo que estás haciendo, solo estarás un paso por delante de los crackers tardíos. Los inteligentes todavía se reirán de ti.

Realice la consulta adicional para asegurarse de que el usuario conectado tenga el conjunto correcto de permisos. Eso hará que la vida de todos sea mucho más simple.

Otros consejos

Cifrar y descifrar parámetros de consulta es un proceso trivial y hay algunos excelentes ejemplos de cómo hacerlo utilizando un HttpModule aquí en StackOverflow.

" No lo haces " ;, " No puedes " ;, o " No es fácil " simplemente no son respuestas aceptables hoy en día ...

Vyrotek: el método de entrada no es importante. GET, POST, GET cifrado / ofuscado: no hay diferencia real. No importa la forma en que su aplicación recibe los comandos, para realizar una acción administrativa debe asegurarse de que el usuario emisor pueda hacer lo que quiera. La verificación de permisos debe realizarse DESPUÉS de que se reciba el comando y ANTES de que se ejecute. De lo contrario, no hay seguridad en absoluto.

Considere usar la técnica descrita en el artículo de Stephen Walther Consejo # 46 - No use Eliminar enlaces porque crean agujeros de seguridad que usa [AcceptVerbs (HttpVerbs.Delete)]

También puede permitir solo publicar solicitudes para eliminar la acción del controlador utilizando el atributo Aceptar verbos como se ve a continuación.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Delete(int? id)
{
    //Delete
}

Entonces también podría usar el token antiforgery como se describe aquí:

http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

He hecho cosas extrañas tomar la cadena de consulta, comprimirla, Base64 o simplemente codificarla en hexadecimal, para que " commentid = 4 & amp; userid = 12345 " se convierte en " code = 1a2b23de12769 "

Es básicamente "Seguridad a través de la oscuridad" pero hace mucho trabajo para alguien que intenta piratear el sitio.

No puedes hacer esto fácilmente.

Tengo buenos recuerdos de un sitio que utilizaba URL de acción para hacer eliminaciones.

Todo estuvo bien hasta que comenzaron a buscar rastreando la intranet.

Vaya, adiós a los datos.

Recomendaría una solución mediante la cual no utilice cadenas de consulta para nada que no desee editar.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top