Video Summary and Transcription
DAST ayuda a priorizar la solución de problemas de seguridad de la aplicación mediante la identificación de vulnerabilidades descubribles y explotables. StackHawk realiza pruebas de seguridad activas en las API para garantizar el manejo seguro de la entrada y salida de usuario. También implementa las mejores prácticas de API OWASP top 10. La herramienta se puede utilizar localmente y en los pipelines de CI/CD.
1. Introducción a DAST y sus beneficios
En StackHawk, realizamos pruebas de seguridad de aplicaciones, específicamente pruebas de seguridad de aplicaciones dinámicas (DAST). DAST ayuda a priorizar la solución de problemas de seguridad de aplicaciones mediante la identificación de vulnerabilidades descubribles y explotables. Aborda los desafíos de probar los frontends de JavaScript y los escáneres DAST heredados, que a menudo no cubren la capa de API. Al conducir directamente la API utilizando la introspección de GraphQL, se pueden obtener mejores resultados, escaneos más rápidos y precisos, y una mejor cobertura de la capa de datos.
¡Hola, GraphQL Galaxy! Soy Scott Grillock, CSO y cofundador de StackHawk. Gracias por tomarte el tiempo para conocer StackHawk y espero que estés aprendiendo muchas cosas nuevas en GraphQL Galaxy 2022. Espero poder enseñarte una más.
En StackHawk, realizamos pruebas de seguridad de aplicaciones. Específicamente, pruebas de seguridad de aplicaciones dinámicas (DAST). Hablemos de los beneficios de DAST. DAST puede ayudarte a priorizar tu tiempo en qué solucionar en problemas de seguridad de aplicaciones porque ayuda a identificar qué es descubrible y probablemente explotable, porque está probando la API de GraphQL en ejecución. Este es el superpoder de DAST, ¿en qué debería enfocar mi tiempo para solucionar problemas de seguridad de la API?
Tal vez estés pensando, pero los frameworks básicamente han evitado que ocurran los problemas comunes de seguridad de aplicaciones, y sí, muchos frameworks han hecho un buen trabajo al prevenir problemas como la inyección de SQL y el scripting entre sitios. Casi todos ellos tienen una versión insegura de todos esos mecanismos de protección para ayudarte a hacer cosas complicadas y, desafortunadamente, cometer errores, sin mencionar cosas como el filtrado de tenencia y la autorización de funciones que pueden ser difíciles de hacer correctamente. Algunas personas no conocen DAST, y aquellos que lo conocen pueden haber tenido problemas con DAST. Veamos un ejemplo.
Así que aquí estamos de vuelta en los buenos y viejos tiempos de los DAST heredados y cuando construíamos aplicaciones del lado del servidor que ejecutaban las capas de datos y presentación, todo estaba bien. El escáner DAST heredado podía escanear y probar la aplicación heredada sin muchos problemas. Obtienes buenos resultados e identificas algunos errores graves de seguridad de aplicaciones, y luego algo cambió. Luego comenzamos a construir frontends de javascript. Y el frontend de javascript realmente troleó a ese escáner DAST heredado. Cuando digo que troleó al escáner DAST heredado, me refiero a que realmente lo troleó. Como, ¿cuándo termina el desplazamiento de la página? Nunca termina. ¿Dónde están todos los formularios? Bueno, aún no se han renderizado, porque tu mouse no está en este píxel exacto. El DAST heredado seguía su feliz camino, asumiendo totalmente que estaba obteniendo toda la información que necesitaba para probar estas nuevas aplicaciones. Las fallas eran terribles, los escaneos tardaban una eternidad, falsos positivos por días, etc. Y la peor parte es que nunca se dio cuenta de que había alguien más en ese asiento trasero también. Nuestras API de respaldo están ahí, controlando todos los datos, hablando con los backends de almacenamiento de datos, ayudando a renderizar elementos en la página, y el escáner DAST heredado cree que el frontend está enviando todas estas solicitudes al backend. ¿Terminamos incluso probando la API aquí? ¿Estamos cubriendo todo? ¿Estamos siquiera haciendo solicitudes simples a la API? Bueno, debido a los frontends de JavaScript, depende en cierta medida. Depende del navegador y el emulador de navegador que esté utilizando tu herramienta DAST heredada y qué tan bien está conduciendo ese navegador. Puedes pensar en esto como scripts de Selenium, pero en lugar de un conjunto específico de funciones, lo estás ejecutando para encontrar todas las posibles rutas de entrada de usuario por sí mismo y esperando que haga un buen trabajo. Incluso Google no lo hace bien. Entonces, ¿cómo podemos volver a tener una mejor seguridad de aplicaciones, seguridad de la API? Mejores resultados, más rápidos, escaneos más precisos, mejor cobertura, especialmente en esta capa de datos donde se almacenan todos los activos que estamos protegiendo. Al conducir esta API directamente utilizando estándares de la industria como la introspección de GraphQL, puedes tener acceso directo a la API, comprender lo que hace y los datos que controla para obtener resultados rápidos, exhaustivos y precisos de pruebas de seguridad de la API. Sin mencionar que ahora puedes probar microservicios mientras los estás construyendo y encontrar estos errores de seguridad de la API de aplicaciones antes de que se envíen a producción.
2. Beneficios de StackHawk para las pruebas de seguridad de aplicaciones dinámicas
Todavía hay cosas buenas que encontrar al probar su frontend, configuraciones de cookies, DOM XSS, muchos encabezados diferentes. ¿Cuáles son algunas de las claves a buscar en una herramienta de pruebas de seguridad de aplicaciones dinámicas que te ayudará a probar las API directamente? Aquí es donde entra StackHawk. StackHawk realiza pruebas de seguridad activas contra tu API en ejecución para garantizar que tu aplicación maneje la entrada y salida del usuario de manera segura, además de implementar las 10 mejores prácticas de seguridad de API de OWASP. Hacemos esto contra tu aplicación en ejecución en tu host local en CI/CD y contra aplicaciones que aún no se han publicado en Internet.
Todavía hay cosas buenas que encontrar al probar su frontend, configuraciones de cookies, DOM XSS, muchos encabezados diferentes. Pero comenzar donde se encuentra los datos es una mejor idea.
¿Cuáles son algunas de las claves a buscar en una herramienta de pruebas de seguridad de aplicaciones dinámicas que te ayudará a probar las API directamente? Aquí es donde entra StackHawk. StackHawk realiza pruebas de seguridad activas contra tu API en ejecución para garantizar que tu aplicación maneje la entrada y salida del usuario de manera segura, además de implementar las 10 mejores prácticas de seguridad de API de OWASP.
Lo hacemos contra tu aplicación en ejecución en tu host local en CI/CD y contra aplicaciones que aún no se han publicado en Internet. También hemos agilizado las pruebas dinámicas al colocar el escáner lo más cerca posible de la aplicación y utilizar estándares abiertos para informar al escáner, como las consultas de introspección de GraphQL. No solo hacemos que las pruebas se puedan ejecutar en cualquier lugar, también hemos habilitado el uso de datos reales en las pruebas, ya sea generados con bibliotecas de datos falsos o proporcionados directamente a través de la configuración. El uso de datos reales es importante para poder probar de manera precisa las API de GraphQL. Ejecutar pruebas personalizadas no es un problema para StackHawk. Pruebas de cosas como el control de acceso roto o el acceso directo inseguro a objetos, esos son dos de los principales problemas de seguridad de API de OWASP. Puedes escribir pruebas personalizadas con StackHawk. Nuevamente, diseñado para probar aplicaciones modernas, incluido GraphQL utilizando interfaces de GraphQL, presentando datos en un formato GraphQL, hace que las pruebas de GraphQL sean fáciles, reproduciendo escenarios de falla y solucionando problemas de seguridad de API con StackHawk es muy fácil. Nuestro enfoque como empresa es ayudar a los desarrolladores a encontrar y, lo que es más importante, solucionar problemas de seguridad. El escáner y la plataforma de StackHawk se construyeron en torno a este modelo de simplicidad. Cuando StackHawk encuentra un problema de seguridad de API en tu aplicación, la plataforma intenta brindarte la versión más simple de la información necesaria para ayudarte a comprender rápidamente qué problema es, con descripciones simples y ejemplos de patrones para ayudar a identificar el anti-patrón, pudiendo recrear problemas con herramientas simples como curl para reproducir el ataque, obtener la depuración y recorrer el código lo más rápido posible para ayudarte a solucionar problemas y volver a tu trabajo habitual de crear valor para tus clientes. Todo esto está habilitado para CI/CD. Nuevamente, puedes integrarlo en tu proceso de CI y, lo que es más importante, obtener comentarios en el proceso de CI sobre los resultados del escaneo. Esta información se puede utilizar para interrumpir una compilación si así lo deseas, según la gravedad de los problemas no clasificados. La mayoría de los principales jugadores de CI tienen sus logotipos en esta diapositiva. Siempre que puedas ejecutar Docker o un proceso Java en tu sistema de CI, puedes ejecutar StackHawk. Y aquí está quizás la parte más importante. Puedes ejecutar estas mismas pruebas de seguridad de aplicaciones localmente. Si estás desarrollando una API en tu máquina local, puedes probar problemas de seguridad de API mientras escribes código. Puedes identificar el problema, solucionarlo y validar que lo has solucionado antes de enviar tu código de vuelta al pipeline CI/CD. Espero que hayas disfrutado mi charla hoy y tal vez hayas aprendido algo nuevo sobre cómo StackHawk se puede integrar en tu proceso de desarrollo de API de GraphQL. Si quieres probar StackHawk y ver cómo se puede integrar en tu proceso de desarrollo para seguir empujando los límites en cuanto a calidad de desarrollo de software, visítanos en stackhawk.com. Gracias por ver y disfruta de GraphQL Galaxy 2022.
Comments