コーダーズ・コンカー・セキュリティ OWASP トップ 10 API シリーズ-機能レベルのアクセス制御が欠けている

Esta serie de blogs se centrará en algunas de las peores vulnerabilidades relacionadas con las interfaces de programación de aplicaciones (API). Estas son tan malas que han llegado a la lista del Proyecto de Seguridad de Aplicaciones Web Abiertas(OWASP) de las principales vulnerabilidades de las API. Dada la importancia de las API en las infraestructuras informáticas modernas, se trata de problemas críticos que debes mantener fuera de tus aplicaciones y programas a toda costa.

La vulnerabilidad del control de acceso a nivel de función que falta permite a los usuarios realizar funciones que deberían estar restringidas, o les permite acceder a recursos que deberían estar protegidos. Normalmente, las funciones y los recursos se protegen directamente en el código o mediante ajustes de configuración, pero no siempre es fácil hacerlo correctamente. Implementar controles adecuados puede ser difícil porque las aplicaciones modernas suelen contener muchos tipos de funciones y grupos, además de una compleja jerarquía de usuarios.

Pero antes, ¿por qué no te lanzas a jugar a nuestro reto gamificado para ver en qué punto te encuentras en la navegación de esta complicada clase de bichos?

Vamos a profundizar en ello:

Las APIs son especialmente vulnerables a este fallo porque están muy estructuradas. Los atacantes que entienden el código pueden hacer conjeturas sobre cómo implementar comandos que deberían estar restringidos a ellos. Esta es una de las principales razones por las que la vulnerabilidad de control de acceso a nivel de función/recurso llegó al top ten de OWASP.

¿Cómo pueden los atacantes explotar la vulnerabilidad del control de acceso a nivel de función?

Los atacantes que sospechan que las funciones o los recursos no están debidamente protegidos deben primero obtener acceso al sistema que quieren atacar. Para explotar esta vulnerabilidad, deben tener permiso para enviar llamadas legítimas de la API al punto final. Tal vez haya una función de acceso de invitados de bajo nivel o alguna manera de unirse anónimamente como parte de la función de la aplicación. Una vez establecido ese acceso, pueden empezar a cambiar los comandos en sus llamadas legítimas a la API. Por ejemplo, podrían cambiar GET por PUT, o cambiar la cadena USERS en la URL por ADMINS. De nuevo, como las APIs están estructuradas, es fácil adivinar qué comandos pueden estar permitidos, y dónde ponerlos en la cadena.

OWASP da un ejemplo de esta vulnerabilidad de un proceso de registro establecido para permitir que los nuevos usuarios se unan a un sitio web. Probablemente utilizaría una llamada GET de la API, como esta:

GET /api/invites/{invite_guid}

El usuario malicioso obtendría de vuelta un JSON con detalles sobre la invitación, incluyendo el rol del usuario y su correo electrónico. A continuación, podría cambiar GET a POST y también elevar su invitación de usuario a administrador mediante la siguiente llamada a la API:

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

Sólo los administradores deberían poder enviar comandos POST, pero si no están bien protegidos, la API los aceptará como legítimos y ejecutará lo que el atacante quiera. En este caso, el usuario malicioso sería invitado a unirse al sistema como nuevo administrador. Después de eso, podrían ver y hacer cualquier cosa que un administrador legítimo pudiera, lo que no sería bueno.

Eliminación de la vulnerabilidad del control de acceso a nivel de función

Prevenir esta vulnerabilidad de la API es especialmente importante porque no es difícil para un atacante encontrar funciones que estén desprotegidas dentro de una API estructurada. Siempre que puedan conseguir algún nivel de acceso a una API, pueden empezar a mapear la estructura del código y crear llamadas que finalmente serán seguidas.

Por lo tanto, todas las funciones de nivel empresarial deben estar protegidas mediante un método de autorización basado en roles. La mayoría de los marcos de trabajo ofrecen rutinas centralizadas para hacerlo. Si el marco de trabajo elegido no lo hace, o si la rutina que tiene es difícil de implementar, hay muchos módulos externos que se construyen específicamente para facilitar su uso. Sea cual sea el método que elijas, asegúrate de implementar la autorización en el servidor. Nunca intentes asegurar las funciones desde el lado del cliente.

Cuando trabaje en la creación de permisos a nivel de funciones y recursos, tenga en cuenta que los usuarios sólo deben recibir permisos para hacer lo que necesitan y nada más. Como siempre que se codifican APIs o cualquier otra cosa, practica la metodología del mínimo privilegio. Asegurará tu entorno y evitará muchos problemas relacionados con la ciberseguridad en el futuro.

Consulta las páginas del blog Secure Code Warrior para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a tu organización y a tus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.