5 malas prácticas que conducen a APIs inseguras en el cómputo de nube

Las interfaces de programación de aplicaciones (APIs) de nube pública abren numerosas posibilidades productivas para los desarrolladores. Estas interfaces aportan funciones básicas a las aplicaciones y conectan aplicaciones y programas a servicios externos. Las API debidamente integradas benefician a todos los usuarios y refuerzan la propuesta de valor de un servicio en el mercado del software.

Dicho esto, las API inseguras en la computación en la nube pueden exponer los entornos a amenazas maliciosas. Las empresas tienen la responsabilidad de proporcionar productos seguros, pero a veces los errores provocan problemas de seguridad. Estos son solo algunos ejemplos de descuidos que pueden generar problemas:

• no examinar las API o realizar una revisión exhaustiva del código antes de la implementación;
• los desarrolladores no configuran correctamente sus API; y
• falta de ofuscación con la lógica empresarial y los puntos finales.

Estos tres casos apenas arañan la superficie cuando se evalúan vulnerabilidades comunes de APIs. A continuación, revisaremos las amenazas comunes y las malas prácticas a tener en cuenta que crean APIs inseguras en la computación en la nube.

1. Exposición no deseada

Una buena API ofrece una funcionalidad relevante y comentarios del usuario final, ya sea cuando algo sale mal o funciona como se esperaba. Un usuario final no ve lo que sucede en segundo plano. Todas las entradas se suministran en la interfaz, a través de la interfaz gráfica de usuario (GUI).

Por ejemplo, la API de identidad de PayPal permite a los clientes acceder a sitios web a través de su cuenta de PayPal. Los usuarios finales interactúan con los campos de inicio de sesión, pero la API hace silenciosamente el trabajo pesado para autorizar y recuperar la información de la cuenta.

Una exposición puede ofrecer información accidental sobre cómo funciona este proceso, qué causa errores y cómo funciona el back-end para lograr sus objetivos. En otras palabras, se muestran los trabajos técnicos de la API. Si bien la documentación de la API proporciona información detallada aquí, algunas cosas no deben publicitarse. Los actores malvados pueden aprovechar la información, como la lógica empresarial, la estructura o la sintaxis de la API y los puntos finales, y lanzar un ataque.

Del mismo modo, las exposiciones no son solo técnicas. Las API mal codificadas pueden otorgar visibilidad o acceso no deseado a datos protegidos, lo que invita a infracciones. Estos eventos son costosos, traicionan la confianza del usuario y abren la infraestructura a otros problemas.

Nota clave: asegúrense siempre de proteger los datos de la aplicación. Del mismo modo, diseñen cualquier mensaje de código de error o comentarios con un enfoque contextual, sin información confidencial sobre la arquitectura de API. Además, no publiquen las respuestas del encabezado a los usuarios finales.

2. Controles de acceso a medias

Los equipos de TI deben asegurarse de que solo las personas adecuadas accedan a la información protegida. Además, todos los servicios protegidos deben verificar que los usuarios sean quienes dicen ser. Muchas API no validan adecuadamente las entradas del usuario, lo que puede crear vulnerabilidades entre sistemas.

Las APIs brindan acceso a los datos del usuario de otras fuentes y utilizan aplicaciones como puertas de enlace a esta información. Desafortunadamente, los protocolos de autenticación y autorización a medias pueden promover el intercambio excesivo de datos.

Por ejemplo, supongamos que está comprando algo en una tienda en línea que tiene una opción integrada de pagos de terceros. Los usuarios finales pueden apreciar esta opción, ya que pueden confiar en los servicios de pago y las credenciales existentes sin entregar información confidencial al comerciante. Idealmente, la API de pagos no compartirá ninguna credencial o información de pago con esa tienda en línea. Sin embargo, las APIs mal codificadas e implementadas pueden filtrar accidentalmente credenciales a destinatarios no deseados.

Nota clave: usen APIs que implementen algún tipo de sistema de tokens, en particular OAuth 2.0. Esto facilita el acceso controlado a datos externos sin derramar, metafóricamente, los frijoles. Las API son recursos fantásticos; sin embargo, algunos datos deben almacenarse en silos para permanecer seguros.

3. Cifrado deficiente

Hay dos tipos de datos: datos en movimiento y datos en reposo. Algunas APIs dejan datos desprotegidos durante el transporte, lo que ocurre cuando se realiza una solicitud HTTP. La API sale y recupera información de la base de datos, punto A, y la envía al servicio de destino, punto B.

¿Y si hay un hombre en el medio, generando un ataque tipo man in the middle (Mitm)? Algunos desarrolladores no se dan cuenta de que no todas las rutas de datos son seguras. Otros implementan protocolos obsoletos o escudos débiles que no evitan los intentos de piratería.

Los datos en reposo normalmente residen en bases de datos. Las APIs se conectan directamente a estas bases de datos, por lo que el cifrado deficiente es tan problemático. Cuando el cifrado es inexistente o incluso deficiente, los datos confidenciales como registros personales, credenciales e información de pago siguen siendo vulnerables. Es posible que estas APIs ni siquiera cumplan con los estándares obligatorios, como HIPAA, Sarbanes-Oxley Act y PCI DSS.

Nota clave: lo ideal es favorecer APIs que admitan un cifrado sólido, AES 256 o Triple DES. Para los datos en movimiento, las APIs deben usar la capa de sockets seguros y la seguridad de la capa de transporte (TLS). Asegúrense de utilizar las versiones más recientes, ya que TLS 1.0 o 1.1 pueden ser insuficientes para algunas aplicaciones.

4. Ignorar los límites y las limitaciones

Un tipo de ataque común que se observa hoy en día es un ataque DDoS, en el que las redes externas envían picos de tráfico a un servicio determinado. Las APIs pobremente limitadas facilitan estos ataques, ya que permiten a los atacantes inundar servidores y redes con solicitudes falsas. Este tipo de ataque genera un rendimiento deficiente, interrupciones del servicio y caídas del servicio.

Muchas APIs no limitan la frecuencia con la que se pueden llamar o imponen límites demasiado altos. Eso significa que una aplicación es susceptible a ciclos interminables de actividad derivados de la API. Naturalmente, la terminación temporal de esa API impide el acceso a las funciones principales de la aplicación, pero también crea una mala experiencia de usuario.

Cuando una empresa no tiene en cuenta los controles de limitación de una API, la degradación del rendimiento se convierte en una preocupación real. Los usuarios podrían paralizar la asignación de recursos y el rendimiento en todo su ecosistema de servicios.

Nota clave: elijan APIs con límites de velocidad configurables y controles de aceleración. Estos determinarán la frecuencia con la que se llama a una API, generarán un mejor tiempo de actividad, impulsarán el rendimiento y protegerán sus servicios de los malos actores. Busquen límites de varios niveles que se apliquen a la API, la aplicación y los recursos mismos. Esto también asegura un mayor control sobre el comportamiento del usuario.

5. Apresurarse al mercado

Hablando fundamentalmente, los desarrolladores de APIs no pueden esperar lanzar un buen producto sin un escrutinio. Al limpiar el código e implementar ciclos exhaustivos de revisión y prueba, los equipos de TI pueden reducir significativamente la cantidad de errores que acompañan inicialmente a una producción.

Surge un problema cuando los plazos tienen prioridad sobre la calidad de la API. Los desarrolladores a menudo tienen mucho por hacer y se espera que generen cantidades masivas de código en muchos casos. Esta presión conduce a errores de programación. Lanzar un producto API por la puerta virtualmente garantiza una API insegura en la computación en la nube.

Una empresa normalmente se apresura cuando espera hacerse un hueco en el mercado antes que sus competidores. Si bien una API puede ser abierta o gratuita, aún puede generar ingresos para sus creadores. Lo mismo se aplica a los desarrolladores externos, cuya inclusión de API ayuda a atraer usuarios. Es posible que los desarrolladores no prueben correctamente cómo una API determinada se adapta a su código o no determinen si los controles integrados ofrecen suficientes protecciones de datos.

Nota clave: ambas partes deben poner a prueba una API. La batalla entre seguridad e ingresos no es un juego de suma cero. De hecho, la creación de APIs que sean conocidas por ser seguras puede impulsar la adopción a largo plazo.