Los 10 principales riesgos de seguridad de las API según OWASP

Cuando intentas mejorar la seguridad de las API, puede ser difícil saber por dónde empezar. Tu equipo quizá se pregunte qué se considera una vulnerabilidad «crítica» y qué una «no crítica», y qué herramientas implementar para mitigar los riesgos más graves que afectan a las aplicaciones de backend (es decir, los servidores) y otros sistemas que funcionan con API.

En conjunto, la industria de la ciberseguridad responde a estas preguntas creando marcos que ofrecen información basada en investigaciones sobre qué riesgos priorizar y cómo responder a ellos. Uno de los avances recientes es el marco OWASP API Top 10, diseñado para proteger las API.

Qué es OWASP API Top 10

La fundación OWASP lleva más de una década ofreciendo recomendaciones de seguridad a las organizaciones. Su iniciativa más conocida es el proyecto OWASP Top 10, vigente desde 2003 y actualizado recientemente para 2021.

En 2019 se publicó la primera lista de seguridad de API de OWASP. OWASP decidió publicar esta lista porque reconoció la importancia de las API y el riesgo creciente que representan para la postura de seguridad de las aplicaciones móviles, SaaS y web actuales.

¿Por qué deberías usar OWASP API Security Top 10?

Hoy en día, las empresas de software no pueden innovar sin API. Estas son la base de innumerables aplicaciones, ya que les permiten integrarse fácilmente y compartir datos y funciones con otras entidades, como terceros y otros equipos de desarrollo internos. En esencia, una API permite intercambiar datos fácilmente y ofrece interoperabilidad. Pero, por desgracia, esto también significa que un atacante puede exponer con facilidad la lógica de la aplicación y los datos confidenciales que proporciona una API. Además, como estas API suelen estar disponibles públicamente, existe un riesgo considerable de que actores maliciosos las utilicen.

Seguridad de aplicaciones web frente a seguridad de API

¿Por qué OWASP tuvo que publicar una lista independiente de las 10 principales vulnerabilidades de las API? Porque las API y las aplicaciones web, aunque a menudo dependen unas de otras, son tecnologías distintas y pueden introducir diferentes tipos de riesgo.

Seguridad de aplicaciones web

Las aplicaciones web tradicionales suelen tener puntos de entrada en dos lugares: el cliente y el servidor. Las mayores amenazas para las aplicaciones web suelen estar relacionadas con debilidades en una de estas dos categorías.

Dos ejemplos de las 10 principales vulnerabilidades de OWASP en las aplicaciones son el control de acceso roto, que significa que personas no autorizadas pueden acceder al servidor, y las fallas criptográficas, que ocurren cuando los datos del servidor no están cifrados correctamente.

Como vemos, ambos tipos de riesgo se relacionan directamente con el servidor. Esto se debe a que las aplicaciones web tienen un número limitado de puntos de entrada: los datos se procesan en el servidor, la página web se muestra en el navegador del cliente, el usuario envía una solicitud y esta vuelve a llegar al servidor. Es un flujo sencillo de ida y vuelta. Aunque los actores maliciosos pueden manipular cualquier parte de este proceso, los puntos de entrada son limitados.

Seguridad de API

Por otro lado, las API tienen una superficie de ataque potencialmente enorme, porque exponen muchos endpoints que los actores maliciosos pueden usar para acceder a datos confidenciales. Los componentes de una misma aplicación funcionan con API individuales que envían y reciben datos de los servidores. Una aplicación puede tener numerosos puntos de entrada accesibles desde el cliente, y un atacante puede aprovecharlos todos.

Como mencionamos antes, la naturaleza misma de las API consiste en exponer datos. Cuando funcionan como corresponde, hacen que las aplicaciones sean mucho más eficientes porque pueden «comunicarse» con otras aplicaciones y bases de datos. Pero, por desgracia, esta característica también hace que los riesgos de seguridad de las API puedan perjudicar especialmente a las empresas que las utilizan.

Explicación de OWASP API Security Top 10

La lista de seguridad de API de OWASP clasifica las vulnerabilidades que tienen más probabilidades de comprometer la seguridad del servidor de tu aplicación. Ofrece una excelente orientación para que tus equipos evalúen soluciones y servicios que permitan reforzar la seguridad de tus API y mejorar la postura de seguridad integral de toda tu organización.

Esta es la lista completa. Puedes usarla para ir a cada sección:

1. Autorización rota a nivel de objeto

2. Autenticación de usuario rota

3. Exposición excesiva de datos

4. Falta de recursos y limitación de solicitudes

5. Autorización rota a nivel de función

6. Asignación masiva

7. Configuración incorrecta de seguridad

8. Inyección

9. Gestión incorrecta de activos

10. Registro y monitoreo insuficientes

#1: Autorización rota a nivel de objeto

Las API usan la autorización a nivel de objeto para garantizar que solo los usuarios adecuados puedan acceder a los datos que proporciona la API. Si este mecanismo de control de acceso falla, los atacantes pueden usar la API para divulgar, modificar o destruir datos que no les pertenecen o a los que no deberían tener acceso.

#2: Autenticación de usuario rota

Los endpoints y flujos de autenticación de usuarios se consideran vulnerables si la API no utiliza mecanismos de seguridad adecuados, como claves de cifrado sólidas, prevención del uso de credenciales obtenidas mediante ataques de fuerza bruta o contraseñas con hash robusto. Si un desarrollador no rota las claves o no configura la autenticación por tokens, los atacantes pueden obtener las credenciales de otra persona y usarlas para acceder a las API.

Por ejemplo, varias versiones del software de GitLab no aplican correctamente la autorización en las pipelines programadas. Esta vulnerabilidad podría permitir que un usuario malicioso ejecute una pipeline con el contexto de otro usuario.

#3: Exposición excesiva de datos

Esta vulnerabilidad ocurre cuando una API proporciona más información de la necesaria y los atacantes pueden aprovecharlo. Este tipo de exposición de datos es común porque los desarrolladores suelen implementar API de forma genérica, sin limitar los endpoints. En cambio, deben decidir con mucho cuidado qué endpoints de API exponer y, de forma predeterminada, filtrar los demás.

Un ejemplo es Moodle, una plataforma de aprendizaje. La función para descargar tablas de Moodle incluye los correos electrónicos de los usuarios, incluso cuando están ocultos. Esta vulnerabilidad se puede corregir con una simple actualización.

#4: Falta de recursos y limitación de solicitudes

Cuando los equipos de desarrollo no limitan el tamaño o la cantidad de recursos que un cliente puede solicitar, surgen vulnerabilidades. Los atacantes pueden usar la fuerza bruta o lanzar ataques de denegación de servicio cuando tienen «reintentos» ilimitados para realizar la solicitud correcta.

Por ejemplo, el middleware `express-brute` tiene un paquete vulnerable a la omisión de la limitación de solicitudes. Contar incorrectamente la cantidad de solicitudes enviadas permite que un atacante eluda este mecanismo.

#5: Autorización rota a nivel de función

Cuando un sistema de control de acceso está mal configurado, los atacantes pueden obtener acceso no autorizado a los endpoints de la API y usar sus nuevos privilegios para explotarlos.

`github.com/matrix-org/gomatrixserverlib`, una biblioteca de Go con funciones comunes para servidores Matrix, tiene una versión del paquete en la que puede fallar la función de análisis del nivel de permisos, lo que hace que los servidores Dendrite autoricen o rechacen eventos de forma incorrecta. Esta vulnerabilidad puede dejar a las organizaciones expuestas a un ataque de denegación de servicio (DoS).

#6: Asignación masiva

Esta vulnerabilidad ocurre cuando una API vincula los datos proporcionados por el cliente con los modelos de datos. Esto permite que un cliente malicioso modifique las propiedades de los objetos con solo manipular los campos accesibles desde el cliente.

Un ejemplo es laravel/framework, un framework para aplicaciones web. Las versiones afectadas de este paquete son vulnerables a la asignación masiva cuando no se usa la propiedad `fillable` en los modelos.

#7: Configuración incorrecta de seguridad

Esta categoría abarca las vulnerabilidades causadas por una implementación incorrecta de las configuraciones de seguridad. Algunos ejemplos de configuraciones incorrectas que podrían afectar a una API son:

• Falta de parches de seguridad

• Funciones innecesarias habilitadas

• El sistema no usa Transport Layer Security (TLS) ni una política de Cross-Origin Resource Sharing (CORS)

• Los mensajes de error exponen información confidencial

`typo3/cms`, un framework de gestión de contenido gratuito y de código abierto, tiene varias versiones vulnerables a una configuración incorrecta de seguridad que puede dejar una cuenta sin credenciales. Un usuario de backend con los privilegios de acceso adecuados podría aprovechar esta debilidad.

#8: Inyección

Los actores maliciosos realizan ataques de inyección al enviar datos maliciosos al sistema a través de la capa de API. Esto puede afectar a las API cuando no validan ni depuran los datos. Por ejemplo, `simple-git` es vulnerable a la inyección de comandos mediante la inyección de argumentos en las versiones 3.3.0 y anteriores. Al inyectar ciertas opciones de Git, era posible ejecutar comandos arbitrarios.

 #9: Gestión incorrecta de activos

Los equipos deben esforzarse por comprender el propósito y la estructura de cada API, y documentar esta información a fondo. De lo contrario, podrían no actualizar, reparar o retirar sus API cuando sea necesario. Una API desactualizada es mucho más vulnerable a los ataques que una que está al día.

#10: Registro y monitoreo insuficientes

Si un equipo de seguridad no cuenta con un registro y monitoreo adecuados, un atacante podría intentar ingresar a sus sistemas repetidamente sin que el equipo lo note.

Dos pasos para reforzar la seguridad de tus API

Al evaluar los 10 principales riesgos de las API según OWASP, tu equipo puede tomar dos medidas para abordar posibles brechas de seguridad: analizar en busca de vulnerabilidades y capacitar al equipo sobre los riesgos de las API.

Análisis de vulnerabilidades de API

Los equipos de seguridad deben analizar periódicamente las API en busca de vulnerabilidades. Para ello, pueden usar tecnología que evalúe el código de backend de las API, detecte riesgos y los corrija. Una forma eficaz de comprobar que estas actividades funcionan es practicar con un proyecto conocido por sus vulnerabilidades. Puedes encontrar estos proyectos en distintas fuentes, como OWASP. 

Cómo analizar las API en busca de vulnerabilidades

Snyk ofrece distintos recursos para que tu equipo analice la seguridad de las API. Snyk Code es una excelente opción para analizar el código de backend de tus API y detectar problemas de inyección, autenticación de usuario rota, exposición excesiva de datos y otros problemas de seguridad. Snyk IAC puede ayudarte a detectar configuraciones incorrectas de seguridad (riesgo n.º 7 de OWASP API) al configurar tu infraestructura para implementar contenedores o funciones sin servidor en la nube.

Capacita a tu equipo sobre las 10 principales vulnerabilidades de API según OWASP

Los equipos también necesitan conocimientos prácticos sobre OWASP Top 10. Si realmente comprenden las causas de cada tipo de vulnerabilidad, será menos probable que contribuyan a estos riesgos y estarán más dispuestos a ayudar a corregirlos.

Además de ofrecer oportunidades de aprendizaje sobre vulnerabilidades comunes, tu organización también debe establecer políticas de seguridad sólidas y capacitar a los desarrolladores para que las implementen mediante ejercicios prácticos. Snyk Learn ofrece recursos educativos útiles sobre diversos temas de seguridad, incluidas las vulnerabilidades de API. Cuando comprenden de verdad las prácticas recomendadas de seguridad, los desarrolladores pueden mejorar la postura de seguridad general con código seguro, mayor compromiso y una corrección más rápida.

Cómo ayuda Snyk con la seguridad de las API

Snyk no solo ofrece recursos para ayudar a las organizaciones a crear API más seguras: también brinda soluciones de seguridad de aplicaciones y de la nube. Además, ofrecemos recursos educativos sobre vulnerabilidades comunes en distintos lenguajes de programación y frameworks, como Java.

Nuestro objetivo es ofrecer recursos de seguridad desde las primeras etapas del desarrollo y fáciles de usar para desarrolladores, que protejan todo el ciclo de vida del desarrollo de software (SDLC) sin sacrificar la agilidad. Contáctanos para programar una demostración hoy mismo.