Principales riesgos de API y cómo mitigarlos

Riesgos de la publicación de API

Examinemos algunas vulnerabilidades y riesgos de las API, empezando por los que se basan en su publicación, y las medidas de seguridad que pueden ayudar a mitigarlos.

Autenticación deficiente

Para que su uso sea seguro, incluso internamente, las API deben utilizar mecanismos de autenticación que garanticen que la entidad que les pide hacer algo es quien dice ser y está conectada con las personas o instituciones con las que dice estar.

Lamentablemente, durante el desarrollo de las API, los programadores no suelen aplicar una autenticación actual y sólida. En consecuencia, al igual que otras aplicaciones web, los back-ends de las API suelen estar plagados de autenticaciones débiles que los hackers malintencionados pueden comprometer fácilmente, o de autenticaciones rotas que pueden eludir.

Cuando la API no puede establecer correctamente la identidad de la entidad al otro lado de la llamada a la API, la empresa corre el riesgo de realizar acciones, compartir información confidencial o aceptar entradas de personas o sistemas que no desea.

Mitigación

Siga metodologías de desarrollo seguras. Los programadores deben estandarizar los módulos de autenticación fuerte y utilizar pruebas automatizadas durante los ciclos de desarrollo que rechacen cualquier código con autenticación no estándar.

El equipo de ciberseguridad también debería realizar pruebas de penetración contra las API, buscando autenticaciones inadecuadas.

Mala autorización

Saber de dónde proceden las solicitudes de API es sólo la mitad de la batalla. La otra mitad es controlar correctamente el acceso a los sistemas back-end y a los datos basados en esa identidad. En este caso, los problemas se centran en los derechos de acceso, ya sean inadecuados o demasiado generosos.

Un acceso inadecuado a la API puede impedir el acceso no autorizado, pero deja a los socios o clientes legítimos sin autorización para recuperar los datos y servicios que necesitan para funcionar adecuadamente.

En el otro extremo del espectro, un control de acceso demasiado amplio permite a los usuarios ver o hacer cosas más allá de lo necesario y podría permitir a agentes malintencionados acceder a información y sistemas privados.

Mitigación

Las pruebas completas de aceptación del usuario –automatizadas, si es posible– deben reproducir escenarios de acceso del mundo real.

El objetivo es evaluar la capacidad de la API para conceder, a una solicitud debidamente autenticada, acceso a todos los datos necesarios, desde cualquier objeto o almacén de datos que los controle. Estas pruebas de seguridad también deben incluir solicitudes para recuperar datos o realizar acciones para las que las cuentas de prueba no están autorizadas. Esto es para asegurar que fallan en las formas esperadas.

Las empresas que publican API deben añadir las revisiones de API a sus auditorías generales de políticas de autenticación. Y deben comprobar el cumplimiento de esas políticas como parte de sus pruebas de penetración periódicas.

Ataques de denegación de servicio

Como servicios orientados a la red, las API pueden ser objeto de ataques DoS y DDoS diseñados para inundarlas con tráfico falso. Si las API proporcionan servicios necesarios para el negocio, su bajo rendimiento o falta de disponibilidad podría tener graves consecuencias para la empresa.

Los ataques DoS o DDoS podrían significar que las API son incapaces de dar servicio a las solicitudes legítimas de manera oportuna. O las peticiones malformadas podrían hacer que consumieran recursos sin liberarlos, agotándolos. Por último, pueden simplemente verse forzadas hasta el punto de que el proceso de la API se bloquee.

Mitigación

Ponga en cola y estrangule las peticiones antes de que lleguen a los sistemas back-end. Además, considere la posibilidad de implementar defensas DDoS y una codificación más estricta para evitar problemas de «peticiones colgadas».

Falsificación de solicitudes del lado del servidor

Uno de los principales riesgos de las API es la falsificación de peticiones del lado del servidor (SSRF, por sus siglas en inglés). Las SSRF convierten el servicio de API en cómplice involuntario de un actor malintencionado, creando así el riesgo de un compromiso lateral o de convertirse en cómplice de ataques a terceros.

Al enviar una solicitud cuidadosamente elaborada a través de la API, el malhechor intenta que el servicio de la API llegue a algún otro sistema dentro de la infraestructura o a algún recurso o sitio de terceros. Por ejemplo, una llamada a la API que espera recibir una URL de la página de LinkedIn de una persona puede recibir una solicitud para abrir un puerto TCP en el propio host del servicio API.

Mitigación

Limite el tipo y el alcance de las URL válidas en las entradas para que sólo puedan hacer lo que se pretende. Utilice un analizador sintáctico actual en las URL para asegurarse de que están bien formadas y son del tipo esperado. Utilice una lista de direcciones permitidas para controlar a dónde pueden apuntar las URL.

TI también debe implementar la confianza cero en el entorno API para evitar que los servicios lleguen lateralmente a sistemas con los que no deberían comunicarse. Tenga en cuenta que este es un ejemplo de un riesgo más amplio: el escrutinio insuficiente de las entradas de las solicitudes de API.

Entradas maliciosas

Los gestores de API pueden, y con demasiada frecuencia lo hacen, aceptar ingenuamente entradas del usuario y almacenarlas en estructuras de datos en el código o en bases de datos externas sin examinarlas previamente. Al igual que ocurre con las aplicaciones web, este es el vector clásico de los ataques de inyección SQL, desbordamiento de búfer, SSRF y otros.

Las API se enfrentan al mismo riesgo de que datos falsos o sin sentido sean tratados como válidos. Si esto ocurre, el gestor de API podría convertirse en la plataforma para algún tipo de ataque lateral contra objetivos internos o ataque reflejado contra objetivos externos.

Mitigación

Nunca acepte datos sin procesar del solicitante. Analice y valide siempre las entradas.

Exceso de datos

Las API a veces exponen más datos de los que la política de seguridad de datos de la empresa dice que deben exponer. Esto crea el riesgo de que la información personal identificable u otra información protegida pueda ser revelada de forma inapropiada.

La exposición excesiva de datos puede ser el resultado de crear y probar API contra un extracto de un conjunto de datos, pero liberar el código en un conjunto de datos más amplio en producción. También puede deberse a problemas de autenticación (véase más arriba).

Mitigación

Realice pruebas con conjuntos de datos que limiten el número de registros, pero no los tipos o los campos contenidos, para validar el acceso con mayor precisión. Utilice sistemas de prevención de pérdida de datos para vigilar y alertar, bloquear o redactar activamente los datos que no deban revelarse de ese modo.

Dependencia de la API

Cuando los procesos internos dependen de los mismos servicios API que las integraciones externas, los procesos de negocio de la empresa están expuestos a las interferencias de los usuarios de API. Los ataques DoS centrados en API pueden paralizar los procesos internos –no sólo los externos– y obstaculizar seriamente la capacidad de la organización para hacer negocios.

Mitigación

Separe los servicios API orientados al interior de los orientados al exterior para evitar que los ataques a API externas afecten directamente a las internas.

Otras fuentes de riesgo para las API

Otras fuentes de riesgo habituales para las empresas que publican API son las siguientes:

• Control de versiones inadecuado de los servicios subyacentes a las API, lo que provoca desajustes en la autenticación, la autorización y el análisis de entradas.
• Ausencia o inadecuación del registro de la actividad de las API y de la supervisión de los registros.

Los 10 principales riesgos de las API según OWASP

El Open Worldwide Application Security Project (OWASP) tiene su propia lista, citada a menudo, de los 10 principales riesgos de seguridad de las API:

1. Autorización rota a nivel de objeto rota.
2. Autenticación defectuosa.
3. Autorización rota a nivel de propiedad de objeto.
4. Consumo de recursos sin restricciones.
5. Autorización rota a nivel de función.
6. Acceso sin restricciones a flujos empresariales sensibles.
7. Falsificación de peticiones del lado del servidor.
8. Mala configuración de la seguridad.
9. Gestión inadecuada del inventario.
10. Consumo inseguro de APIs.

Riesgos del consumo de API

Los riesgos de las API no se limitan a su publicación; considere los siguientes riesgos relacionados con su consumo.

Consumo inseguro de datos

Cuando una organización utiliza API para recuperar datos de sistemas ajenos, se crea el riesgo de que esos datos sean malos e incluso maliciosos. Podría llevar a la organización a tomar malas decisiones y emprender acciones incorrectas o informar de falsedades en lugar de hechos a reguladores, clientes o socios.

Mitigación

La validación de las entradas es fundamental para proteger las API. Lleve un registro de la procedencia de los datos para que los problemas puedan atribuirse e investigarse adecuadamente.

Riesgo de terceros no documentado

Las empresas se exponen a problemas cuando asumen riesgos de terceros, es decir, riesgos derivados de los proveedores de sus proveedores.

Tantas API consumen otras API de terceros, que a su vez pueden consumir otras API, y así sucesivamente, que puede ser difícil saber cuántas entidades diferentes pueden estar implicadas en última instancia en el suministro de la respuesta a una solicitud de API. Esto puede dar lugar a una vasta superficie de ataque.

Mitigación

Controle su ecosistema de API limitando el número de API que utilizan sus propias API. Busque acuerdos contractuales con esos otros proveedores de API para definir y limitar su riesgo frente a terceros.

Riesgo no documentado para los procesos empresariales

Cuando los procesos de negocio dependen del consumo de la API, pero esa dependencia no está documentada, es muy fácil que el proceso se rompa.

Los cambios en el proceso de negocio pueden realizarse sin tener en cuenta que requieren cambios en el uso de la API, lo que puede provocar, por ejemplo, que el proceso no funcione correctamente. O los cambios en el funcionamiento de la API pueden dar lugar a cambios sutiles en su comportamiento que son problemáticos, pero no inmediatamente evidentes.

Mitigación

Documente exhaustivamente todos los procesos empresariales. Utilice arquitecturas de confianza cero para impedir que los sistemas internos accedan a API internas o externas sin permiso explícito.

Los riesgos inherentes a las API no son exclusivos de éstas. Para gestionar los principales riesgos de las API y garantizar que la red de la organización permanezca segura, los sistemas de TI y ciberseguridad deben estar familiarizados con los tipos de problemas que generan los riesgos, así como con las herramientas y estrategias diseñadas para mitigarlos.

John Burke es CTO y principal analista de investigación de Nemertes Research. Con casi dos décadas de experiencia en tecnología, ha trabajado en todos los niveles de TI, como especialista en soporte al usuario final, programador, administrador de sistemas, especialista en bases de datos, administrador de redes, arquitecto de redes y arquitecto de sistemas. Sus áreas de interés incluyen IA, nube, redes, infraestructura, automatización y ciberseguridad.