¡Descubre GoogleTest, con certificación TÜV y la tecnología Agentic AI para pruebas de C/C++!
Obtenga los detalles »
White Paper
¿Te interesa saber qué contiene la guía? Empieza con la vista previa a continuación.
Los adversarios actuales tienen objetivos claros, ya sea robar secretos comerciales, información personal de los consumidores o perjudicar a una empresa mediante un ataque de denegación de servicio. Encontrar vulnerabilidades de día cero y atacar aplicaciones personalizadas es difícil. Siempre se prefiere un vector de ataque más sencillo, ya sea atacar a un proveedor en una cadena de suministro con malas prácticas de seguridad de software, engañar a un usuario para que revele credenciales internas o explotar una vulnerabilidad conocida en un componente común de software de código abierto.
Las API representan más del 80% de todo el tráfico web y ofrecen a los atacantes técnicas de ataque similares a las del software de código abierto vulnerable.
A menudo, los problemas que dan lugar a las brechas de seguridad relacionadas con las API no se deben a que el atacante (y en algunos casos, el investigador de seguridad) sea especialmente astuto o diligente. En cambio, muchos de estos problemas están relacionados con un diseño e implementación deficientes de la API.
Los pilares fundamentales de la seguridad del software son la autenticación y autorización robustas, el principio de mínimos privilegios y la protección de datos, así como la realización de pruebas para detectar casos de abuso y mal uso. Las recientes vulnerabilidades de seguridad en Clubhouse, John Deere y Experian son ejemplos de cómo no se siguieron las prácticas básicas de seguridad del software, lo que provocó la filtración de información sobre usuarios, clientes y consumidores.
"Las API mal diseñadas pueden perturbar los negocios y erosionar la confianza de los consumidores, especialmente cuando exponen problemas de privacidad."
—Experto en soluciones de seguridad en Parasoft
"Las API mal diseñadas pueden perjudicar a las empresas y minar la confianza de los consumidores, especialmente cuando exponen problemas de privacidad. Las vulnerabilidades de la API de Clubhouse, que permiten el ghosting, el trolling y la interceptación de comunicaciones, son ejemplos de por qué la seguridad debe diseñarse desde el principio y seguir buenas prácticas de ingeniería de software, donde el principio de mínimo privilegio es un elemento fundamental para eliminar una serie de problemas de seguridad", explica el experto en soluciones de seguridad de Parasoft.
En todos los casos, los investigadores de seguridad que identificaron las vulnerabilidades simplemente utilizaron la API —tal como fue diseñada— para acceder a información de millones de usuarios y/o clientes, además de hacer un uso indebido de su funcionalidad prevista. Algunos diseños de la API permitían el acceso a cualquier usuario sin autenticación y ofrecían la posibilidad de consultar a cualquier usuario (o a todos) y descargar nombres, direcciones, compras y otra información. Estos fueron errores evitables en el diseño, la implementación y las pruebas de las API.
Una API bien diseñada requiere la colaboración de los responsables de producto, arquitectos y personal de seguridad para comprender adecuadamente los casos de abuso y mal uso e incorporar medidas de seguridad. Siguiendo los ejemplos anteriores, los controles de autenticación son fundamentales, ya que el mecanismo de autenticación está expuesto a todos, incluidos los adversarios de la organización.
Por lo tanto, los controles de autenticación van más allá de simplemente exigir que los usuarios y los sistemas se autentiquen. Incluyen controles para prevenir el relleno de credenciales y los ataques de fuerza bruta, las contraseñas débiles, la divulgación de información confidencial como tokens de autenticación y claves de cifrado débiles.
Los controles de autenticación fuertes son solo un primer paso. Como se señala en el Top 10 de seguridad API de OWASPLas organizaciones también deben garantizar la autorización adecuada tanto a nivel de objeto como a nivel de función.
El descubrimiento de API es fundamental. Se requiere visibilidad de todas las API. No se puede proteger algo sin antes saber que existe. Comprender la superficie de ataque y qué API están expuestas es esencial para las pruebas de seguridad. La cobertura de pruebas de API y el descubrimiento de API son datos importantes para minimizar el riesgo asociado con los ataques a API. Como se mencionó, el cambio de aplicaciones monolíticas a microservicios ha incrementado considerablemente la cantidad de API en la organización promedio. Este cambio fundamental exigirá que las organizaciones sean más proactivas en el descubrimiento de API y el análisis de la superficie de ataque.
En buenas prácticas, los proyectos de software incluyen documentación detallada para el personal interno, con el fin de simplificar el mantenimiento y ayudar a los desarrolladores que se incorporan al proyecto a comprender el funcionamiento de la aplicación. Del mismo modo, las API requieren documentación para los desarrolladores que las utilizan, ya sean desarrolladores y evaluadores internos o terceros. En la práctica, la presión por añadir funcionalidades y acelerar el lanzamiento al mercado suele implicar que la documentación sea limitada.
Esto es especialmente cierto en el caso de las API, que suelen ser más sencillas y estar destinadas al uso interno. Sin la documentación interna adecuada, los ingenieros de DevOps tienen un conocimiento incompleto sobre el funcionamiento de una API. Sin contratos, definiciones ni especificaciones de API, los equipos de control de calidad y seguridad deben modelar el comportamiento previsto de las API y adivinar los casos de uso y mal uso.
Los recursos de seguridad son escasos en la mayoría de las organizaciones. Se trata de un problema nacional cada vez mayor. Los equipos de control de calidad e ingeniería DevOps suelen centrarse en las pruebas funcionales, asegurando que las características descritas en el documento de requisitos cumplan con las especificaciones.
Si bien esto incluye casos de uso como pruebas de rendimiento y capacidad, puede omitir pruebas de seguridad que a menudo se centran en casos de abuso y mal uso, como llamar a una API con argumentos intencionadamente incorrectos o no manejar adecuadamente los valores devueltos por la API.
Los equipos de seguridad y pruebas suelen estar familiarizados con los casos de uso de una interfaz de usuario. Los casos de uso de las API son más complejos, en particular entre microservicios.
Si bien los problemas y vulnerabilidades de seguridad mencionados anteriormente son sencillos, el rápido aumento de los microservicios y las API resultantes complica la seguridad, lo que podría permitir a atacantes sofisticados vincular múltiples API en un ataque de varias etapas. Las políticas de control de acceso con diferentes jerarquías, grupos y roles pueden resultar confusas para los defensores y dar lugar a controles de seguridad inadecuados.
Pruebas y seguridad de las API Requieren comprender la lógica de una aplicación, sobre la cual la seguridad suele tener menos información. Las API son como bloques de Lego que se pueden ensamblar de diversas maneras. Los atacantes pueden usar las API de forma no prevista, incluso conectándolas para atacar una aplicación. ¿De cuántas maneras se puede acceder al carrito de compras o almacenar información de pago?
"Las API son sorprendentemente flexibles. Poder probar exhaustivamente las posibles combinaciones es fundamental para garantizar la seguridad de sus API."
—Arthur Hicken, Director de Evangelización de Parasoft
Las pruebas exhaustivas requieren visibilidad programática de las API y sus interacciones, casos límite, protocolos y conocimiento de los tipos de datos esperados. Crear pruebas es posible con los recursos suficientes, por supuesto, pero esta habilidad tiene una curva de aprendizaje muy pronunciada.
Las herramientas tradicionales utilizadas de forma tradicional son solo una solución parcial. Herramientas de análisis estático Por lo general, estas herramientas examinan el código fuente. Si bien identifican algunos problemas con la API, carecen de conocimiento sobre la funcionalidad prevista, lo que limita su exhaustividad.
Los escáneres de análisis dinámico también son útiles, pero a menudo solo buscan puntos de entrada en la interfaz de usuario y pueden desconocer las API y su funcionalidad.
Si bien un experto en pruebas de penetración puede identificar vulnerabilidades en las API, esta metodología no es escalable y resulta poco práctica en términos de tiempo y costo. Además, es incompatible con metodologías de desarrollo rápido como CI/CD y DevSecOps.
Estas herramientas no comprenden los mecanismos de autenticación de API y necesitan conocer protocolos como OAuth2 y JSON Web Tokens.
También presentan dificultades con los tipos de contenido y las respuestas HTTP, que influyen en la detección de vulnerabilidades en las API. Además, estas herramientas no pueden rastrear enlaces para descubrir API, lo que modifica radicalmente las pruebas de seguridad para las API.
Adición Pruebas de seguridad API Es posible integrar la tecnología DevOps en el ciclo de vida del desarrollo de software, incluso en entornos de desarrollo rápido, cuando las organizaciones proporcionan a los ingenieros de DevOps las herramientas y el soporte adecuados.
Es fundamental que las pruebas de seguridad consideren tanto los fallos de diseño comunes como los errores de implementación y configuración. Desarrollar software más seguro no es ningún secreto. Existen diversas directrices y estándares que las organizaciones pueden utilizar para identificar y mitigar los riesgos.
Una de ellas, la OWASP Application Security Verification Standards (ASVS), resulta especialmente útil a la hora de diseñar e implementar API. ASVS se describe a sí misma como «una lista de requisitos o pruebas de seguridad de aplicaciones que pueden utilizar arquitectos, desarrolladores, evaluadores, profesionales de la seguridad, proveedores de herramientas y usuarios para definir, crear, probar y verificar aplicaciones seguras».
Si bien obtener la certificación ASVS es un objetivo admirable, las organizaciones que buscan mejorar gradualmente sus programas de seguridad de software pueden utilizar las directrices de ASVS de una manera menos formal.
Integración de las actividades de seguridad de la API Es posible comenzar en las primeras etapas del ciclo de vida del desarrollo de software, incluso en entornos de desarrollo rápido, cuando las organizaciones proporcionan a sus equipos de desarrollo las herramientas y el apoyo adecuados.
Las pruebas de seguridad tempranas son esenciales para prevenir y detectar problemas de seguridad en las API, pero todo comienza con un buen diseño. Diseñar una API segura no es ningún secreto. Entre otras cosas, las API requieren definiciones claras de los parámetros permitidos por los controles de seguridad, medición de velocidad para prevenir ataques de fuerza bruta y la aplicación de mecanismos de autenticación robustos para evitar el uso indebido de la API.
Posponer las pruebas de seguridad hasta etapas avanzadas del ciclo de vida del desarrollo de software genera retrasos y mayores costos de desarrollo. Corregir errores se vuelve más costoso en la fase de mantenimiento. El aumento de los costos se debe, en gran medida, a la dificultad de refactorizar el software para corregir errores o modificar bibliotecas de código abierto, manteniendo las características y la funcionalidad del diseño original.
En los estándares ASVS, el enfoque de "desplazamiento a la izquierda" considera la funcionalidad de la API, la autenticación y la autorización en la fase de diseño del ciclo de vida. Esto implica autenticar la comunicación entre los componentes de la aplicación, incluidas las API; que todos los componentes utilicen el principio de mínimo privilegio; cifrar las llamadas a las API; y que las URL de las API no expongan información confidencial, como los tokens de sesión.
OWASP ofrece orientación a través de OWASP API Top 10, que describe la opinión consensuada sobre las vulnerabilidades más comunes y dañinas que se encuentran en las API. Muchas de ellas están relacionadas con problemas de gestión de identidad y acceso, mientras que otras, como las de inyección y registro de eventos, ya se utilizan e integran en la mayoría de los conjuntos de pruebas de seguridad de aplicaciones.
Un método mejor para probar las API consiste en aprovechar las pruebas funcionales para proporcionar visibilidad de las API subyacentes a la aplicación y su funcionalidad, y aumentar la generación de pruebas utilizando inteligencia artificial (IA) para crear casos de prueba adecuados.
"Pruebas de API Puede ser sorprendentemente complejo. Requiere conocimientos sobre pruebas, el uso de las API y cómo podrían utilizarse de maneras distintas a las de las historias de usuario. Al añadir seguridad, se necesitan aún más conocimientos, ya que la capa de API es más profunda y técnica que la capa de interfaz de usuario", explica Arthur Hicken, evangelista jefe de Parasoft.
"Las pruebas de API pueden ser sorprendentemente complejas. Cuando se añade la seguridad a la ecuación... la capa de API es más profunda y técnica que la capa de interfaz de usuario."
—Arthur Hicken, Director de Evangelización de Parasoft
SOAtest de Parasoft Smart API Test Generator aprovecha un complemento del navegador que utiliza IA para convertir automáticamente las pruebas de interfaz de usuario manuales y automatizadas en pruebas de API automatizadas. En lugar de simplemente recopilar el tráfico, grabarlo y reproducirlo, El generador de pruebas de API inteligente aplica IA Para descubrir patrones significativos, aplicar modelos de amenazas y comprender las relaciones entre las llamadas a la API. Posteriormente, puede generar escenarios de prueba de API automatizados que realizan las mismas acciones que las pruebas de interfaz de usuario, pero de forma totalmente automatizada y fácilmente extensible.
¿Listo para sumergirte más profundamente?
