Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>

Vea qué solución de pruebas de API resultó ganadora en el informe GigaOm Radar. Obtenga su informe analítico gratuito >>
Saltar a la sección
¿Cómo automatiza las pruebas de API para que sean escalables y sostenibles? Continúe para obtener la respuesta a esta pregunta y más.
Saltar a la sección
Saltar a la sección
Dado que las pruebas de penetración son costosas y pueden tardar mucho en ejecutarse, debemos realizar las pruebas de seguridad de API de una manera que sea escalable y sostenible.
Hablar de la seguridad de las API y de por qué deberíamos preocuparnos es un poco como hablar de comer nuestras verduras. Todos sabemos que comer nuestras verduras es bueno para nuestra salud, pero ¿cuántos de nosotros lo hacemos realmente? La seguridad de las aplicaciones es un poco así. Si bien es esencial para la salud de nuestras aplicaciones y nuestros negocios, esforzarse por lograrlo no es tan interesante como crear nuevas funciones interesantes para las aplicaciones. Pero solo tenemos que mirar los titulares de las noticias recientes para comprender lo importante que es.
Tradicionalmente, la validación de una aplicación o API por seguridad se ha realizado al final del proceso de desarrollo. Sin embargo, esto es intrínsecamente problemático. Por lo general, es demasiado tarde en el proceso para que se solucionen los errores descubiertos: puede que esté demasiado cerca de la fecha de lanzamiento para solucionar los problemas, o el equipo puede haber pasado a otros proyectos, o la arquitectura de la aplicación puede ser inherentemente insegura.
Además, los servicios y las aplicaciones de hoy en día se publican con más frecuencia que nunca, a menudo hasta varias veces al día. Esta cadencia de liberación rápida hace que el enfoque tradicional sea insostenible. En este blog revisaré un paso a paso Lista de verificación de seguridad de la API para hacer que las pruebas de seguridad de la API sean una parte automatizada del proceso de CI.
Para resolver este problema, recurriremos a una solución que la industria ha estado utilizando para abordar los problemas de calidad del software con ciclos de lanzamiento acelerados: la integración continua. La integración continua produce compilaciones cada vez que se registra un nuevo código y valida el nuevo código mediante la ejecución de análisis estáticos y pruebas unitarias para cada compilación. Si los equipos son sofisticados, incluso podrían estar creando y ejecutando pruebas funcionales automatizadas mediante CI (quizás no para cada compilación, ya que las pruebas funcionales suelen tardar mucho tiempo en ejecutarse, pero al menos a intervalos específicos, como una vez al día).
Podemos aplicar esta misma solución a las pruebas de seguridad automatizadas para nuestras API al incorporar las pruebas de penetración en nuestros flujos de trabajo de CI. Esto asegurará que probaremos las vulnerabilidades de seguridad antes y nos dará pruebas de regresión de seguridad que pueden detectar nuevos problemas tan pronto como se presenten. Pero tendremos que ser inteligentes al respecto, ya que las pruebas de penetración son caras y pueden tardar mucho en ejecutarse. Debemos hacerlo de una manera escalable y sostenible.
Supongo que nuestros equipos ya están escribiendo y ejecutando pruebas funcionales automatizadas para nuestras API. (Si no estamos haciendo esto, debemos comenzar aquí y no estamos listos para considerar la automatización de nuestras pruebas de seguridad). Si estamos ejecutando pruebas funcionales automatizadas para nuestras API, entonces, como parte de nuestros procesos normales de desarrollo y control de calidad, podemos identificar un subconjunto de esas pruebas funcionales para usar como pruebas de seguridad. Prepararemos y ejecutaremos este subconjunto como pruebas de seguridad.
Permítanme describir cómo funciona esto usando Prueba SOA de Parasoft y su incorporado pruebas de penetración soporte, que se incluye en el 2021.2 liberación.
Para empezar, supongamos que tenemos un escenario SOAtest con 1 prueba de configuración que limpia la base de datos y 3 pruebas que realizan 3 llamadas API diferentes. Queremos realizar pruebas de penetración para cada una de las 3 API que se llaman en el escenario:
Primero prepararemos el escenario para la seguridad agregando una herramienta de prueba de penetración a cada una de las pruebas en el escenario:
Luego ejecutaremos este escenario usando SOAtest. A medida que se ejecuta cada prueba, SOAtest realizará la llamada API definida en la prueba y capturará el tráfico de solicitud y respuesta. La herramienta de prueba de penetración en cada prueba pasará los datos de tráfico a una instancia integrada de la herramienta de prueba de penetración OWASP ZAP, que realizará pruebas de penetración en la API en función de los parámetros de API que observa en los datos de tráfico, utilizando su propia heurística.
La herramienta de prueba de penetración informará los errores encontrados asociados con la prueba que accedió a la API. Aquí hay un informe SOAtest de muestra con todos los errores organizados por CWE y por gravedad:
Los resultados de SOAtest pueden informarse en DTP, el panel de análisis e informes de Parasoft, para obtener capacidades de informes adicionales. Aquí hay una representación de cómo funciona esto:
La reutilización de las pruebas funcionales para su uso como pruebas de seguridad ofrece los siguientes beneficios:
Hay algunas cosas a tener en cuenta al reutilizar las pruebas funcionales para su uso como pruebas de penetración:
Necesitamos considerar si ejecutar nuestras pruebas funcionales y de seguridad dentro del mismo entorno de prueba o en uno diferente. Restablecer el entorno entre las ejecuciones de prueba funcional y de seguridad, o usar un entorno separado, promueve una mejor estabilidad de la prueba, pero generalmente no es necesario. A menudo podemos reutilizar el mismo entorno, pero cuando lo hacemos, debemos ejecutar las pruebas funcionales primero y las pruebas de seguridad al final, ya que las pruebas de seguridad pueden desestabilizar el entorno para las pruebas funcionales. Cuando usamos diferentes entornos, debemos asegurarnos de configurar los escenarios de prueba funcionales originales con variables para que sea fácil apuntar las pruebas a diferentes puntos finales para diferentes entornos. SOAtest admite esto mediante el uso de variables de entorno.
Nuestras API también pueden depender de otras API fuera de nuestro control. Podemos considerar el uso virtualización de servicios para aislar nuestro entorno así que no dependemos de esos sistemas externos. Esto ayudará a estabilizar nuestras pruebas y, al mismo tiempo, evitará consecuencias no deseadas en los sistemas externos debido a nuestros esfuerzos de pruebas de penetración.
Podemos garantizar una mejor calidad en nuestras API trasladando las pruebas de seguridad al desarrollo y control de calidad como parte de un proceso automatizado. Podemos aprovechar nuestras pruebas funcionales de API existentes para crear pruebas de seguridad automatizadas, lo que nos permitirá descubrir y corregir errores de seguridad en una etapa más temprana del proceso. Y con suerte, esto nos ayudará a no convertirnos en uno de los próximos grandes titulares en las noticias.
Cómo reducir el tiempo de prueba de API con automatización impulsada por IA