¿Prevenir el acceso fraudulento a recursos restringidos en la web?

5

Estoy trabajando en una aplicación web junto con una API web y se me ha advertido contra lo que parece ser una vulnerabilidad básica: no comprobar que el usuario que realiza una acción tiene suficientes privilegios en el recurso al que se accede. No encuentro recursos ni mejores prácticas.

Aquí hay un escenario:
El URI para acceder a los detalles de una cuenta bancaria es domain.com/details/1234 , con 1234 como ID de usuario. Un usuario malintencionado puede ver el patrón de URI e intentar acceder a domain.com/details/1230 . Si no se hace nada, ya que ha iniciado sesión, verá los detalles de otro usuario.

Primero, ¿este tipo de vulnerabilidad y ataque relacionado tienen un nombre? Segundo, ¿cuáles son las mejores prácticas para prevenir esto? En la web que parece bastante simple, simplemente podemos verificar la cookie de sesión / ID para comparar con el propietario del recurso solicitado. Pero la API será utilizada por una aplicación móvil, donde las cookies no están disponibles. ¿Cuál sería una buena manera de proteger la API?

    
pregunta Antoine 04.06.2013 - 19:21
fuente

2 respuestas

1

Para evitar la vulnerabilidad, cada solicitud debe estar autenticada de alguna manera y la autenticación verificada . Esto equivale a proporcionar una cookie de sesión, ya sea que lo haga en la URL GET, por ejemplo,

domain.com/details/1234

donde 1234 es su usuario (y también su sesión), o dentro de una solicitud POST o JSON.

En lo anterior, tiene la autenticación, pero no está verificada. Cualquiera puede reclamar ser usuario 1234.

O agrega una cookie separada, que aún expone la identificación del usuario:

domain.com/details/1234:db81390fb2befd1dd839c37ab39d699cddb8d65b

o empacas todo dentro de la cookie:

domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details

Lo anterior tiene la ventaja de que puede internamente reescribir la solicitud después de verificarla

domain.com/details/1234

para que la aplicación "detrás" de la capa de seguridad pueda permanecer sin cambios.

La capa de seguridad extraerá la cookie, verificará que sea válida (puede contener su propia firma criptográfica y un nonce, para evitar los ataques de repetición), y desde la sesión asociada a la cookie recupere la identificación de usuario 1234 y la transmita.

Al autenticarse por primera vez, se genera una nueva sesión y se asocia a la cookie. Si utiliza una cookie "suficientemente grande", puede agregarle aleatoriedad:

1. The mobile app requests the user details:

domain.com/db81390fb2befd1dd839c37ab39d699cddb8d65b/details

2. The server destroys cookie db813... and replies with JSON:

{
    'cookie': '926c8a7699c367d3da9370f433189a20b06f8f3d',
    ...other details...
}

3. The next request will have to contain cookie 926c8... to be accepted.

En el escenario anterior, puede reforzar aún más la seguridad al agregar reconocimiento de estado a la aplicación. Por ejemplo, cuando recibe el JSON anterior, la aplicación móvil se encuentra en estado "Mostrar detalles" y, a partir de ese estado, solo se permite un número muy limitado de transiciones. Es posible que no pueda realizar la transición en un paso desde allí a la pantalla "Cambiar contraseña de usuario", por ejemplo.

Lo que significa que si un atacante puede interceptar la solicitud JSON e intenta usarla para acceder a la función Cambiar contraseña:

domain.com/926c8a7699c367d3da9370f433189a20b06f8f3d/newpassword

se puede identificar como una transición ilegal. El método newpassword "verá" que el estado anterior no fue "Perfil de usuario" o "Menú de seguridad", sino "Mostrar detalles", lo cual no es pertinente, y la conexión se puede cancelar.

El atacante tendría que primero hacer la transición de Detalles al Menú Principal y de allí al Perfil de Usuario, regenerando la cookie una o dos veces y, por lo tanto, eliminando al usuario legítimo . La aplicación de usuario legítima no sabe que su estado ahora no está sincronizado y podría intentar usar la cookie que tiene. Dicha reutilización de cookies puede ser detectada y tomada como evidencia de que una cookie ha sido interceptada intencionalmente. No podrá saber de manera confiable quién es el atacante y quién la víctima, pero puede abortar ambas conexiones.

    
respondido por el LSerni 04.06.2013 - 20:11
fuente
4

¿Está seguro de que no hay cookies disponibles por una aplicación móvil, a menudo este es el caso. También esto se conoce como escalada de privilegios horizontal . Si solo puede ver los detalles de otros usuarios, también agregaría la enumeración de usuarios.

Si desea comprobar cómo se realizan estas solicitudes, puede colocar un proxy entre su teléfono e Internet (como ZAP o Burp) para ver qué pasa realmente al servidor.

La mejor práctica es NUNCA NUNCA PONER ID de sesión en las solicitudes GET. Hay una razón por la que tenemos cookies y las aplicaciones móviles son compatibles con las cookies como cualquier otra aplicación. La mayoría de las aplicaciones de banca móvil que he visto utilizan una API REST con JSON que no necesariamente usa cookies (pero puede que no sea completamente sin estado). A menudo, las consultas se firman con un tipo de clave privada o token.

    
respondido por el Lucas Kauffman 04.06.2013 - 19:49
fuente

Lea otras preguntas en las etiquetas