Las 10 mejores API de la serie OWASP de Coders Conquer Security: falta el control de acceso a nivel de función

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 crearon el Open Web Application Security Project (AVISPA) lista de las principales vulnerabilidades de la API. Dada la importancia de las API para las infraestructuras informáticas modernas, se trata de problemas críticos que debe mantener fuera de sus aplicaciones y programas a toda costa.

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

Pero primero, ¿por qué no te lanzas y juegas a nuestro desafío gamificado para ver cómo te encuentras a la hora de sortear esta complicada clase de bichos?

Echemos un vistazo más a fondo:

Las API son especialmente vulnerables a este defecto porque están muy estructuradas. Los atacantes que entienden el código pueden hacer conjeturas fundamentadas sobre cómo implementar comandos que deberían estar restringidos a ellos. Esa es una de las principales razones por las que la vulnerabilidad del control de acceso a nivel de función o recurso se ubicó entre las diez mejores del OWASP.

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

Los atacantes que sospechen que las funciones o los recursos no están protegidos adecuadamente deben obtener primero acceso al sistema que desean atacar. Para aprovechar esta vulnerabilidad, deben tener permiso para enviar llamadas de API legítimas al punto final. Quizás haya una función de acceso de invitados de bajo nivel o alguna forma de unirse de forma anónima como parte de la función de la aplicación. Una vez que se haya establecido ese acceso, pueden empezar a cambiar los comandos en sus llamadas a la API legítimas. Por ejemplo, pueden cambiar GET por PUT o cambiar la cadena USERS de la URL a ADMINS. Una vez más, dado que las API están estructuradas, es fácil adivinar qué comandos podrían estar permitidos y dónde colocarlos en la cadena.

OWASP ofrece un ejemplo de esta vulnerabilidad de un proceso de registro configurado para permitir a los nuevos usuarios unirse a un sitio web. Probablemente utilizaría una llamada GET a la API, como esta:

OBTENGA /api/invites/ {invite_guid}

El usuario malintencionado recuperaría un JSON con detalles sobre la invitación, incluidos el rol y el correo electrónico del usuario. A continuación, podrían cambiar GET por POST y también elevar la invitación de un usuario a la de administrador mediante la siguiente llamada a la API:

PUBLICAR /api/invites/new
{"correo electrónico»:» shadyguy@targetedsystem.com «, "rol» :"admin "}

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

Eliminar la vulnerabilidad de control de acceso a nivel de función

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

Por lo tanto, todas las funciones de nivel empresarial deben protegerse mediante un método de autorización basado en roles. La mayoría de los marcos ofrecen rutinas centralizadas para que eso suceda. Si el marco elegido no lo hace, o si la rutina que tiene es difícil de implementar, hay muchos módulos externos que están diseñados específicamente para facilitar su uso. Sea cual sea el método que elija en última instancia, asegúrese de implementar la autorización en el servidor. Nunca intente proteger las funciones desde el lado del cliente.

Cuando trabajes para crear permisos a nivel de funciones y recursos, ten en cuenta que los usuarios solo deben tener permisos para hacer lo que necesitan y nada más. Como siempre ocurre al codificar las API o cualquier otra cosa, practica la metodología de privilegios mínimos. Protegerá su entorno y evitará muchos problemas relacionados con la ciberseguridad en el futuro.

Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.