La seguridad de las APIs es un área importante de la ciberseguridad que trata de impedir que los atacantes exploten la interfaz de programación de aplicaciones para obtener datos sensibles o interrumpir los servicios. Con la creciente dependencia de las APIs para la comunicación entre aplicaciones y servicios, es esencial contar con una sólida estrategia de seguridad y auditorías en APIs para evitar el acceso no autorizado y garantizar el blindaje de los datos.
Las APIs pueden ser vulnerables a diversas amenazas a la seguridad, como ataques de inyección, man-in-the-middle (MITM), denegación de servicio distribuida (DDoS), ataques de control de acceso a las aplicaciones Estas amenazas, si no se abordan, pueden dar lugar a violaciones de datos, pérdidas financieras y daños a la reputación.
El presente artículo tiene como objetivo analizar la seguridad en las APIs desde el punto de vista del desarrollador, analizando las principales vulnerabilidades que se pueden producir en estas aplicaciones.
Introducción al OWASP API Security Top 10
El proyecto OWASP API Security Top 10 se lanzó en 2019 y la actualización de 2023 proporciona una representación más precisa de las amenazas actuales que enfrentan las interfaces de programación de aplicaciones (API). Este proyecto tiene como objetivo ofrecer a los desarrolladores y a los equipos de seguridad información sobre las 10 principales vulnerabilidades encontradas en las APIs que se pueden resumir en los siguientes:
- Broken Object Level Authorization (Autorización a nivel de objeto rota). Las API suelen exponer identificadores de objetos para acceder a los recursos. Cuando el control de acceso no se implementa adecuadamente en estos endpoints, los atacantes pueden ver u operar recursos a los que no deberían tener acceso. Esta vulnerabilidad afecta a todo tipo de arquitecturas API, incluidas SOAP, REST y GraphQL.
- Broken Authentication (Autenticación rota). Los endpoints y los flujos de autenticación de usuarios se consideran rotos si la API no utiliza los mecanismos de seguridad adecuados, como claves de cifrado seguras, prevención de relleno de contraseñas o contraseñas fuertemente codificadas. Si el desarrollador no realiza la rotación de claves o no configura la autenticación mediante tokens, los atacantes pueden obtener acceso a las credenciales de otra persona y usarlas para acceder a las API.
- Broken Object Property Level Authorization (Autorización de nivel de propiedad de objeto rota). El Top 10 de seguridad API de OWASP establece que una API es vulnerable cuando un usuario puede acceder a un objeto empleando un endpoint de la API sin que se haya procedido a validar que dicho usuario tiene derecho a acceder a las propiedades específicas del objeto a las que va a acceder.
- Unrestricted Resource Consumption (Consumo de recursos sin restricciones). Las APIs que no tienen restricciones en cuanto el acceso a sus recursos pueden verse fácilmente sujetas a ataques de por fuerza bruta o de denegación de servicio, que pueden tumbar los servidores o provocar un aumento del gasto en el uso de la infraestructura en el caso de utilizar arquitecturas serverless.
- Broken Function Level Authorization (Autorización rota a nivel de función). Este tipo de vulnerabilidad tiene que ver con que los usuarios habituales puedan acceder a funciones sensibles, como la modificación, creación o eliminación, a las que de otro modo no deberían poder acceder.
- Unrestricted Access to Sensitive Business Flows (Acceso sin restricciones a flujos empresariales sensibles). OWASP señala que cuando se crea un endpoint en una API, se expone un flujo de negocio y es fundamental entender que hay flujos de negocio más sensibles que otros y el acceso a ellos sin control puede resultar perjudicial para la empresa.
- Server Side Request Forgery (Falsificación de peticiones del lado del servidor). El ataque de Server Side Request Forgery (SSRF) es una vulnerabilidad de seguridad en la que un atacante puede inducir a una aplicación web o API a realizar solicitudes HTTP o de red desde el servidor en lugar de hacerlo desde la máquina del cliente. Esto puede permitir que un atacante realice solicitudes no autorizadas a recursos internos y servicios en la red local que pueden ser accesibles desde el servidor.
- Security Misconfiguration (Configuración incorrecta o no segura). Esta categoría cubre vulnerabilidades que ocurrieron porque las configuraciones de seguridad no se han implementado correctamente.
- Improper Asset Management (Gestión inadecuada de activos). Una API suele tener muchas versiones, funcionalidades, endpoints y muchos parámetros diferentes que afectan el comportamiento de ese endpoint. El rápido aumento de las API y los microservicios puede provocar una expansión y dar lugar a que muchos servicios no documentados y múltiples versiones se ejecuten simultáneamente.
- Unsafe Consumption of APIs (Consumo no seguro de APIs). Esta vulnerabilidad se produce porque los desarrolladores tienden a confiar en las interacciones con las API externas, pero éstas podrían tener requisitos de seguridad más débiles y los datos podrían verse comprometidos.
El papel del desarrollador en las APIs
El papel del desarrollador en el contexto de las APIs (Interfaces de Programación de Aplicaciones) es fundamental en el desarrollo de software y la creación de soluciones tecnológicas. La lista de 2023 destaca varios tipos de vulnerabilidad relacionadas con la autorización e introduce riesgos potenciales en torno a los flujos de lógica de aplicaciones o la gestión inadecuada de inventario. A continuación se detallan algunas responsabilidades clave que los desarrolladores deberían asumir en relación con las APIs:
- Broken Object Level Authorization(Autorización a nivel de objeto rota). Para prevenir esta vulnerabilidad, el Top 10 de seguridad API de OWASP recomienda implantar un mecanismo de autorización adecuado que se base en las políticas y la jerarquía de usuarios. En este punto el desarrollador debería implementar mecanismos de autorización para comprobar si el usuario autenticado tiene acceso para realizar la acción solicitada en cada función que utilice una entrada de datos del cliente para acceder a un registro de la base de datos.
- Broken Authentication (Autenticación rota). Respecto a la fuga de tokens, los desarrolladores deberían transportar tokens de acceso de forma segura utilizando tecnologías como OAuth o JSON Web Tokens.
- Broken Object Property Level Authorization (Autorización de nivel de propiedad de objeto rota). La clave para evitar esta vulnerabilidad es implementar un control de acceso estricto y granular basado en la sesión del usuario y garantizar que este control de acceso se implemente de manera consistente a lo largo de toda la aplicación.
- Unrestricted Resource Consumption (Consumo de recursos sin restricciones). Esta vulnerabilidad podría ser explotada por atacantes mediante un ataque de denegación de servicio (DoS), ante la falta de suficientes recursos para atender a todas las peticiones que se realizan a la API. Para evitar el consumo de recursos sin restricciones, es importante establecer límites a las solicitudes masivas, descarga de archivos o las demandas de uso de memoria y CPU.
- Broken Function Level Authorization (Autorización rota a nivel de función). Por ejemplo, cuando un usuario puede modificar la cuenta de otro usuario o cuando un usuario normal puede acceder a la funcionalidad de administración de un sitio. Estos problemas son debido a la falta de controles de acceso o mal configurados.
- Unrestricted Access to Sensitive Business Flows (Acceso sin restricciones a flujos empresariales sensibles). En este punto el desarrollador debería comprobar los flujos de negocio para ver si están exponiendo información sensible.
- Server Side Request Forgery (Falsificación de peticiones del lado del servidor). Para prevenir los ataques de Server Side Request Forgery, se deben tomar medidas de seguridad adecuadas, que podrían incluir:
- Validación de entrada de usuario: Validar y filtrar las entradas de usuario, especialmente las URL, para garantizar que solo se permitan las solicitudes a recursos legítimos y seguros.
- Listas blancas de direcciones: Podríamos utilizar listas blancas (whitelists) de direcciones y recursos permitidos para limitar las peticiones a destinos específicos que pongamos en estas listas.
- Limitar permisos: Limitar los permisos y la capacidad de la aplicación para realizar peticiones a recursos locales o externos, y garantizar que la aplicación se ejecute con el mínimo conjunto de privilegios necesarios, es lo que se llama aplicar el principio de mínimo privilegio.
- Security Misconfiguration (Configuración incorrecta o no segura). Para prevenir problemas relacionados con una mala configuración de la seguridad de una API es fundamental protegerla a lo largo de su ciclo de vida:
- Poner en marcha un proceso de hardening en el ciclo de vida del despliegue, que sirva para aplicar un entorno debidamente blindado.
- Revisar y actualizar las configuraciones de la API, incluyendo archivos de orquestación, componentes y servicios en la nube.
- Automatizar la evaluación de la configuración y los ajustes en todos los entornos, para que dicho análisis pueda realizarse de forma continua, por ejemplo si estamos utilizando sistemas de CI/CD sería interesante comprobar que se esté aplicando la misma configuración a nivel de seguridad en todos los entornos.
- Improper Asset Management (Gestión inadecuada de activos). Es importante realizar un inventario adecuado de hosts y versiones de API implementadas para mitigar problemas como versiones de API en desuso y endpoints de depuración que puedan quedar expuestos.
- Unsafe Consumption of APIs (Consumo no seguro de APIs). Para mitigar esta vulnerabilidad es importante validar los datos obtenidos de otras API antes de procesarlos y trasladarlos a componentes de la API y limitar los recursos que se pueden emplear para procesar respuestas de servicios de terceros.
Únete a nuestra comunidad ¿Quieres derle un vuelco a tu furuto profesional? En nuestra plataforma de Talent puedes encontrar la forma de llevar tu carrera al siguiente nivel. Entra en nuestra web y encuentra tu trabajo ideal. Échale un vistazo. Ser parte de la comunidad de Codemotion te permitirá potenciar tu experiencia y enfrentar nuevos desafíos que impulsarán tu carrera. Aprenderás nuevas habilidades técnicas y crecerás junto a otros miembros mediante el intercambio de opiniones y la creación conjunta. Tenemos dos comunidades para ti según tu experiencia: Si eres wanna-be-dev, junior-dev o early-mid-dev nuestra comunidad de Discord es para ti. Allí encontrarás recursos, eventos, formación, muchos compañeros de viaje y beneficios exclusivos. Súmate aquí. Si eres late-mid-dev, senior-dev, Tech Lead o CTO nuestra comunidad de Telegram es para ti. Allí encontrarás el mejor networking, artículos high-tech, debates de tendencias tech y beneficios exclusivos. Súmate aquí. ¡Nos vemos en Codemotion!
