Serie OWASP Top 10 API de Coders Conquer Security: Control de acceso a nivel de función faltante

Esta serie de blogs se centrará en algunas de las peores vulnerabilidades relacionadas con las interfaces de programación de aplicaciones (API). Son tan graves que forman parte de la lista de las principales vulnerabilidades de API del Open Web Application Security Project (OWASP). Dada la importancia de las API en las infraestructuras informáticas modernas, estos son problemas críticos que debes evitar a toda costa en tus aplicaciones y programas.

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

Pero primero, ¿por qué no te animas a probar nuestro desafío gamificado para ver qué tal te manejas con esta compleja clase de errores?

Analicémoslo más a fondo:

Las API son especialmente vulnerables a este fallo debido a su estructura altamente organizada. Los atacantes que entienden el código pueden hacer conjeturas fundamentadas sobre cómo implementar comandos que deberían estar restringidos para ellos. Esa es una de las razones principales por las que la vulnerabilidad de control de acceso a nivel de función/recurso entró en el top diez de OWASP.

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

Los atacantes que sospechan que las funciones o los recursos no están protegidos adecuadamente deben primero obtener acceso al sistema que desean atacar. Para explotar esta vulnerabilidad, deben tener permiso para enviar llamadas API legítimas al punto final. Quizás exista una función de acceso de invitado de bajo nivel o alguna forma de unirse de forma anónima como parte de la funcionalidad de la aplicación. Una vez establecido ese acceso, pueden empezar a cambiar los comandos en sus llamadas API legítimas. Por ejemplo, podrían sustituir GET por PUT, o cambiar la cadena USERS en la URL por ADMINS. De nuevo, debido a 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 en un proceso de registro configurado para permitir que nuevos usuarios se unan a un sitio web. Probablemente utilizaría una llamada API GET, como esta:

GET /api/invites/{invite_guid}

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

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"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 desee. En este caso, el usuario malintencionado sería invitado a unirse al sistema como un nuevo administrador. Después de eso, podría ver y hacer todo lo que un administrador legítimo podría hacer, lo cual no sería nada bueno.

Eliminación de 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 desprotegidas dentro de una API estructurada. Siempre que puedan obtener cierto nivel de acceso a una API, pueden comenzar a mapear la estructura del código y crear llamadas que eventualmente serán ejecutadas.

Por lo tanto, todas las funciones a nivel de negocio deben protegerse mediante un método de autorización basado en roles. La mayoría de los marcos de trabajo ofrecen rutinas centralizadas para lograrlo. Si el marco que has elegido no lo hace, o si la rutina que tiene es difícil de implementar, existen muchos módulos externos creados específicamente para facilitar su uso. Independientemente del método que elijas, asegúrate de implementar la autorización en el servidor. Nunca intentes proteger las funciones desde el lado del cliente.

Al trabajar en la creación de permisos a nivel de función y recurso, ten en cuenta que los usuarios solo deben recibir los permisos necesarios para hacer lo que deben hacer y nada más. Como siempre ocurre al programar API o cualquier otra cosa, practica la metodología de menor privilegio. Esto asegurará tu entorno y evitará muchos problemas de ciberseguridad en el futuro.

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