¿Cómo detener la navegación forzada? - Guardar la información de ser comprometida por el cambio de URL

Navega tus respuestas
3

Tengo una aplicación ASP.NET MVC 4.

En algunas páginas web o vistas, tengo información mostrada en la tabla. Los valores de columna se representan como enlaces.

Problemas: 1. Cuando muevo el cursor sobre el enlace, su URL está visible en la parte inferior del navegador. 2. Cuando hago clic en el enlace, muestro información del recurso solicitado en la URL. (www.someurl.com/Employee/67 me da información del empleado con id = 67). Ahora, esta URL se muestra en el navegador. Si cambia la URL a www.someurl.com/Employee/88, muestra la información del empleado con id = 88, aunque se supone que el usuario registrado no debe ver la información para el ID del empleado 88

Estas son violaciones graves de seguridad.

Estoy pensando en seguir como posibles soluciones:

  1. Enmascaramiento de URL en el nivel de aplicación

  2. Codificación Base64 de la URL para acortarla y ofuscarla, de modo que los usuarios no puedan simplemente introducir valores en la URL.

  3. @ Html.AntiForgeryToken () y ValidateAntiForgeryTokenValidation mecanismo

¿Existe un enfoque mejor y más seguro que el anterior para resolver este problema?

Saludos,

Suraj

    
pregunta Suraj 02.04.2014 - 13:06
fuente

2 respuestas

3

A partir de la descripción que mencionó, parece que se trata de una vulnerabilidad de seguridad que popularmente se conoce como Referencia de objetos directa insegura .

Para mitigar este tipo de problema, debe verificar si el usuario tiene acceso a un recurso en particular o no. La codificación Base64 de la URL no funcionará en esto.

Le recomendaría que visite esto entrada del blog: OWASP Top 10 para desarrolladores .NET parte 4: Referencia de objetos directa insegura , escrita por Troy Hunt.

Espero que esto te ayude a proteger tus aplicaciones.

    
respondido por el justtrying123 02.04.2014 - 14:09
fuente
0

La única forma de solucionar este problema es imponer la autorización a nivel de rol o de elemento para cada una de sus acciones.

Sus suposiciones deben ser:

  1. Se conoce cada url a su sitio, ya que todos siguen una plantilla predecible
  2. La ofuscación no importa: en algún punto, una publicación enviará la identificación, ofuscada o sustituida o no, por lo que es posible predecir cualquier identificación si conoce el sistema de ofuscación (que en sí mismo es predecible).

Por lo tanto, un usuario malintencionado podría simplemente iterar a través de cada ID (desde -2147483647 a 2147483648) usando su URL para sus acciones (por ejemplo, mysite.com/user/delete/id). Usar un Guid no hace ninguna diferencia, solo hace que el espacio de ataque sea un poco más grande.

Por lo tanto, dentro de tus acciones debes verificar que:

  1. el usuario está autenticado (normalmente utilizando AuthorizeAttribute )
  2. el usuario está autorizado para acceder al objeto exacto para el que está enviando una solicitud. Esto se aplica a las acciones de lectura / actualización / creación / eliminación.

Puede hacer esto a nivel granular usando roles (también con AuthorizeAttribute , de modo que solo los miembros del rol de Administrador pueden eliminar un usuario), o en un nivel de elemento implementando su propio sistema de permisos (por ejemplo, almacene una tabla con los usuarios que tienen permiso para crear / leer / actualizar el perfil de otro usuario).

    
respondido por el Andy Brown 14.04.2014 - 12:26
fuente

Lea otras preguntas en las etiquetas

autorización de seguridad para los programadores ¿Qué significa RHSA, RHEA y RHBA en RedHat Erratas?