10 principales riesgos de seguridad de las API según OWASP: la edición de 2023 ya está aquí
Las interfaces de programación de aplicaciones (API) actuales permiten una integración flexible y rápida entre prácticamente cualquier software, dispositivo o fuente de datos, así como ofrecen una amplia gama de funcionalidades y proporcionan una base para la innovación y la transformación digital.
Además, se han convertido en el estándar para crear y conectar aplicaciones modernas, especialmente con la migración, cada vez mayor, a arquitecturas basadas en microservicios. Es importante protegerlas correctamente, ya que sirven como pegamento digital entre los sistemas.
Cada una de estas llamadas de API puede abrir brechas de seguridad y producir riesgos de privacidad que van desde una validación deficiente de los datos, errores de configuración y defectos en la implementación hasta la falta de integración entre los componentes de seguridad. Es importante tener esto en cuenta al abordar las vulnerabilidades definidas en los 10 principales riesgos de seguridad según el Proyecto abierto de seguridad de aplicaciones web (OWASP, por sus siglas en inglés).
El 5 de junio de 2023, OWASP lanzó la primera actualización importante de su lista inicial, que se publicó en 2019. Revisemos los cambios y veamos qué factores clave están influyendo en las vulnerabilidades actuales de las API para que pueda estar más informado sobre cómo proteger sus API.
10 principales riesgos de seguridad de las API según OWASP
OWASP es una organización no gubernamental que crea documentos de concienciación sobre la seguridad basados en los comentarios de la comunidad y la evaluación de expertos, incluidas las contribuciones de Akamai. Estos documentos describen los tipos de vulnerabilidades más comunes que se encuentran en las organizaciones actuales y son un recurso excelente para cualquier persona que trabaje con las API, desde desarrolladores hasta directores de seguridad de la información (CISO).
OWASP publica por separado el documento 10 principales riesgos de seguridad de las API, además de las otras listas Top 10, para hacer hincapié en que la seguridad de las API requiere un enfoque único. El proyecto de seguridad de las API de OWASP "se centra en estrategias y soluciones para comprender y mitigar las vulnerabilidades únicas y los riesgos de seguridad de las API".
Las diferencias
Repasemos las diferencias entre las ediciones de 2019 y 2023 (Figura 1).
Fig. 1: Los cambios en los 10 principales riesgos de seguridad de las API según OWASP de 2023
Según las notas de la versión de 2023:
El documento sobre los 10 principales riesgos de seguridad de las API según OWASP de 2023 tiene como objetivo la concienciación con visión de futuro de un sector que avanza a gran velocidad. No sustituye a las otras listas Top 10. En esta edición:
- Hemos combinado la Exposición excesiva de datos y la Asignación masiva, centrándonos en la causa principal común: los errores de validación de autorización a nivel de propiedad de objeto.
- Hemos puesto más énfasis en el consumo de recursos, fijándonos en el ritmo al que se agotan.
- Hemos creado una nueva categoría llamada "Acceso sin restricciones a flujos empresariales confidenciales" para abordar nuevas amenazas, incluso la mayoría de las que se pueden mitigar mediante la limitación de velocidad.
- Hemos añadido la categoría "Consumo no seguro de las API" para hacer frente a algo que hemos empezado a ver: los atacantes han comenzado a buscar servicios integrados de un objetivo para tratar de vulnerarlos, en lugar de acceder directamente a las API de su objetivo. Este es el momento adecuado para empezar a concienciar sobre este riesgo cada vez mayor.
Novedades, entradas y salidas
NOVEDAD | API3:2023 | Autorización a nivel de propiedad de objeto comprometida
OWASP combinó las anteriores categorías de Exposición excesiva de datos y Asignación masiva en la nueva Autorización a nivel de propiedad de objeto comprometida (BOPLA), centrándose en la causa principal común: los errores de validación de autorización a nivel de propiedad de objeto.
La diferencia entre la Autorización a nivel de propiedad de objeto comprometida (BOLA) y BOPLA es que BOLA hace referencia a un objeto completo, mientras que BOPLA se refiere a una propiedad dentro de un objeto (Figura 2).
Fig. 2: BOPLA hace referencia a una propiedad dentro de un objeto
Tanto OWASP como Akamai siguen detectando riesgos importantes a nivel de objeto, lo que explica por qué BOLA sigue siendo el primer y más importante riesgo de seguridad de API que se debe tener en cuenta.
Sin embargo, si profundizamos un nivel y observamos el nivel de propiedad del objeto, existe un riesgo adicional de compartir información o de permitir que determinadas propiedades puedan modificarse o eliminarse, cuando no debería ser así.
Estar protegido por BOLA no significa estarlo por BOPLA, y combinar la Asignación masiva y la Exposición excesiva de datos en una sola categoría enfatiza la importancia de la atención que deben prestar los desarrolladores de API a las propiedades dentro de un objeto.
Esta distinción es importante para aquellos que están buscando un producto de seguridad de API, ya que necesitan asegurarse de que el producto les protege frente a ambos tipos de ataque.
ENTRADA | API6:2023 | Falsificación de solicitudes del lado del servidor
OWASP redujo el riesgo de seguridad de inyección y, al hacerlo, este dejó de encontrarse entre los 10 riesgos principales y le allanó el camino a la falsificación de solicitudes del lado del servidor (SSRF).
La SSRF es un tipo de ataque que aprovecha una vulnerabilidad en una aplicación web o API y permite a un atacante realizar solicitudes no autorizadas desde el servidor a otros sistemas internos o externos.
Estas son algunas de las posibles razones por las que OWASP decidió realizar este cambio:
- Las API son más vulnerables a los ataques SSRF porque dependen de tecnologías modernas, como Kubernetes y Docker, que utilizan protocolos de comunicación HTTPS basados en API.
- Con tecnologías como WebHooks, las integraciones de SSO y la recuperación/redireccionamiento de archivos URL a través de terminales de API, los atacantes pueden utilizar la SSRF.
Un análisis más profundo
Para obtener más información sobre los ataques SSRF, lea el artículo de Mike Elissen Your APIs Are Enabling Server-Side Request Forgery (SSRF) Attacks (Sus API están permitiendo ataques de falsificación de solicitudes del lado del servidor (SSRF)).
SALIDA | API8:2019 | Inyección
Eliminar los ataques de inyección de la lista fue un acto osado y polémico en la comunidad de seguridad de las API, pero este tipo de ataques a los terminales de API presentan una amenaza cada vez menor.
La inyección es ahora esencialmente parte de API8:2023 | Configuración de seguridad incorrecta. Una configuración de seguridad adecuada debe incluir mecanismos de protección de API y aplicaciones web, que deben analizar y evitar las inyecciones por defecto.
GraphQL está cogiendo importancia como tecnología de API. Es, en esencia, un lenguaje de consulta que podría volver a abrir la puerta a un aumento de los ataques de inyección, por lo que los desarrolladores de API que usan GraphQL deberían seguir atentos.
NOVEDAD | API4:2023 | Uso de recursos sin restricciones
La lista original se centraba específicamente en comprender el riesgo de consumo de recursos que provoca que los terminales de API se saturen, así como que puedan dejar de estar disponibles, y perjudiquen la experiencia del usuario.
Hoy en día, los terminales de API deben estar disponibles, pero eso no lo es todo. La implementación de la puerta de enlace de API, del balanceo de carga o de los controles de limitación de velocidad es un paso en la dirección correcta.
En los últimos años, estamos viendo un enorme cambio en la·"economía del uso de las API". Esta categoría actualizada tiene como objetivo concienciar acerca de este aspecto, que seguirá cobrando importancia con las integraciones de API de terceros.
NOVEDAD | API6:2023 | Acceso sin restricciones a flujos empresariales confidenciales
Otra nueva incorporación es API6:2023 Acceso sin restricciones a flujos empresariales confidenciales. Esta categoría finalmente ha logrado codificar lo que hace que la seguridad sea tan especial: pensar más como un atacante y ver dónde pueden hallarse los posibles beneficios.
La tecnología (la API) es solo una forma de ejecutar la lógica empresarial. De este modo, que exista la posibilidad de omitir o alterar dicha lógica a través de la tecnología no es recomendable y puede dar lugar a complicaciones.
OWASP compartió ejemplos específicos de cómo se pueden evitar, pero este riesgo de seguridad depende en gran medida de la lógica empresarial que utilicen sus terminales de API.
Desarrolladores de API: Ejemplo
Recientemente, Mike Elissen mantuvo una conversación con unos desarrolladores de API en un servicio de streaming. Para atraer a público nuevo, este servicio de streaming ofrecía una prueba gratuita de 30 días para los nuevos usuarios que compartieran la información de su tarjeta de crédito.
Sin embargo, la lógica empresarial solo tenía en cuenta las direcciones de correo electrónico exclusivas de los nuevos registros. Asimismo, con una dirección de correo electrónico nueva, se podría acceder fácilmente a otra prueba con la misma información de la tarjeta de crédito, lo que podría provocar que los usuarios creasen cuentas nuevas cada mes, utilizando el servicio de forma gratuita indefinidamente.
NOVEDAD | API10:2023 | Uso inseguro de API
Como el consumo de API por parte de terceros está creciendo rápidamente, las API a menudo tienen que integrarse y comunicarse con diferentes servicios internos y externos (de terceros) tanto para enviar datos como para recibirlos.
En esos casos, también es importante seguir las reglas "básicas" de seguridad, y para los productos de seguridad puede resultar complicado detectar vulnerabilidades y defenderse proactivamente en este espacio.
OWASP incluye una serie de sugerencias en su documento, tanto generales como específicas de API, como:
- Seguir las indicaciones cuidadosamente. Incorporar esta supervisión a la lógica empresarial, así como añadir soluciones de seguridad que controlen e inspeccionen continuamente los flujos de tráfico.
- No limitarse a confiar en las API de terceros, aunque tengan una buena reputación. Incorporar defensas y límites en sus aplicaciones y terminales de API.
Akamai puede contribuir a la seguridad de las API
Las organizaciones y sus proveedores de seguridad deben colaborar estrechamente y alinear personas, procesos y tecnologías para establecer una protección sólida contra los riesgos de seguridad descritos en los 10 principales riesgos de seguridad de las API según OWASP.
Akamai ofrece soluciones de seguridad líderes en el sector, expertos de elevada experiencia y Akamai Connected Cloud, que obtiene información de millones de ataques a aplicaciones web, miles de millones de solicitudes de bots y billones de solicitudes de API cada día. Las soluciones de seguridad para aplicaciones web y API de Akamai le ayudarán a proteger su organización frente a los ataques distribuidos de denegación de servicio y frente a los ataques contra aplicaciones web y API más avanzados.
Akamai + Neosec
La nueva versión de OWASP coincide con nuestra reciente adquisición de Neosec. La solución de seguridad de API de Neosec complementará la cartera de aplicaciones y seguridad de API de Akamai, la cual es líder en el mercado, al ampliar drásticamente la visibilidad de la empresa en el panorama de amenazas de API, que crece rápidamente.
Esta combinación está diseñada para que los clientes puedan proteger fácilmente sus API, ya que les ayuda a descubrir la totalidad de las mismas, evaluar su riesgo y responder a vulnerabilidades y ataques.
Más información
Obtenga más información sobre las soluciones de seguridad de API de Akamai y nuestra adquisición de Neosec.
¡Enhorabuena y gracias, OWASP!
Concienciar sobre la seguridad requiere un gran esfuerzo por parte de la comunidad, así que queremos agradecer a OWASP el haber dirigido este proyecto y, en especial, a Erez Yallon, Inon Shkedy y Paulo Silva su gran trabajo en la edición de 2023.
También queremos dar las gracias a todos los colaboradores, y sobre todo a Maxim Zavodchik y Mike Elissen de Akamai, por haber participado en este proyecto y haber educado a la comunidad de desarrolladores sobre la seguridad de API.
Información adicional sobre las API
Akamai realiza un seguimiento del uso de las API y la cantidad de tráfico de API como parte de sus informes sobre el estado de Internet (SOTI). Lea los informes SOTI anteriores para obtener más información y busque nuevos informes cada trimestre.
Recursos adicionales
Serie de vídeos: Fundamentals of API Security (Fundamentos de la seguridad de API)
