¿Cómo evito que mi HTML sea explotable al tiempo que evito los GUID?

Question

He heredado recientemente una base de código ASP.NET MVC 4. Un problema que noté fue el uso de algunos identificadores de bases de datos (ints) en las direcciones URL también en presentaciones de formularios html. El código en su estado actual es explotable mediante el retoque de URL y la creación de publicaciones HTML personalizadas con diferentes números.

Ahora bien, aunque puedo solucionar fácilmente los problemas de URL mediante el estado de sesión o comprobaciones de autenticación adicionales, estoy menos seguro de los identificadores de base de datos que se incrustan en el HTML que el sitio escupe (es decir, les doy un menú desplegable llenar). Cuando vuelven los identificadores en una publicación, ¿cómo puedo estar seguro de que los coloco allí como opciones válidas? ¿Qué se considera "mejor práctica" en términos de abordar este problema?

A pesar de que aprecio que podría simplemente "guiarlo", no estoy seguro de hacerlo porque me parece un fastidio trabajar con ellos al depurar bases de datos.

¿Tengo una opción aquí? ¿Debo GUID para evitar la adivinación fácil de los identificadores o existe algún tipo de mecanismo DRY que pueda usar para validar el uso de los identificadores a medida que vuelven al sitio?

ACTUALIZACIÓN: Un comentarista preguntó acerca de los exploits que estoy esperando. Digamos que escupí un formulario HTML con una lista desplegable de todas las ubicaciones desde las que se puede importar "tesoro". La identificación de las ubicaciones que posee el usuario son 1,2 y 3, estas se proporcionan en el HTML. Pero el usuario examina el html, juega con él y decide armar un POST con el ID de 4 seleccionado. 4 no es su ubicación, es la de otra persona.

Answer 1

Valide la ID aprobada con los ID que el usuario puede modificar.

Puede parecer tedioso, pero esta es realmente la única forma de asegurarse de que el usuario tenga acceso a lo que está tratando de modificar. Usar GUIDs sin validación es seguridad por oscuridad: seguro que adivinarlos es difícil, pero puede adivinarlos con suficientes recursos.

Puede hacer esto en la parte superior del controlador antes de hacer cualquier otra cosa con los datos publicados. Si hay una violación, solo lanza una excepción y haz que tu manejador de excepciones global se encargue de ella; no es necesario que lo maneje de una manera bonita, ya que puede asumir con seguridad que el usuario está manipulando datos de una manera no compatible.

Answer 2

El problema que usted describe se conoce como "referencias a objetos directos inseguros", y el grupo OWASP recomienda dos políticas para hacer frente a este problema:

1. utilizando referencias a objetos indirectos basados ​​en la sesión, y
2. validación todos los accesos a referencias de objetos.

Un ejemplo de sugerencia n. ° 1 sería que en lugar de tener las opciones desplegables 1, 2 y 3, asigne a cada opción un GUID asociado con la ID original en un mapa en la sesión del usuario. Cuando obtiene un POST de ese usuario, comprueba para ver a qué objeto se suponía que estaba vinculada la identificación dada. El ESAPI de OWASP tiene algunas bibliotecas para ayudar con esto en varios idiomas.

Pero en muchos casos, la sugerencia n. ° 1 es en realidad contraproducente. Por ejemplo, en muchos casos desea tener URL que puedan copiarse/pegarse de un usuario a otro. El proceso n. ° 2 generalmente se considera la manera más infalible de abordar este problema.

Answer 3

Usted está describiendo Broken Access Control con Ides inseguros. Una vez que haya identificado la amenaza y haya decidido qué IDds son propiedad de ciertos usuarios, asegúrese de que haya controles para este lado del servidor.