Pruebas automatizadas de seguridad de aplicaciones con StackHawk

¡Hola, Node Congress! Soy Scott Gerlach, Director de Seguridad y cofundador aquí en StackHawk. Espero que estén teniendo una gran conferencia y aprendiendo mucho sobre Node. Hablemos de StackHawk. Rápidamente, StackHawk es una herramienta dinámica de pruebas de seguridad de aplicaciones. Puede utilizarla para probar sus aplicaciones HTTP en ejecución y puntos finales de API en busca de errores de seguridad y evitar que se vuelvan vulnerables. Puede utilizar StackHawk para realizar pruebas de seguridad activas en su API REST en ejecución, API GraphQL, API SOAP, aplicaciones del lado del servidor y aplicaciones de una sola página.

StackHawk fue creado para la automatización en CI/CD y formar parte de su sólida estrategia de pruebas para el ciclo de vida del desarrollo de aplicaciones. También facilita la búsqueda, comprensión y solución de errores de seguridad. ¿Cómo funciona StackHawk, preguntan? ¡Excelente pregunta! StackHawk realiza pruebas de seguridad activas en sus aplicaciones en ejecución para garantizar que su aplicación maneje de manera segura la entrada y salida del usuario, así como implementar las mejores prácticas OWASP top 10 para la seguridad de la aplicación. Podemos hacer esto en su aplicación en ejecución en su host local, en flujos de trabajo de CI/CD y en aplicaciones que aún no se han publicado en Internet. También hemos hecho que las pruebas dinámicas sean rápidas. 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 especificaciones de API abiertas, GraphQL, consultas de introspección, SOAP, WSDL, además de la configuración del escáner que hemos realizado, la mayoría de las aplicaciones de los clientes de StackHawk se escanean en un promedio de menos de 10 minutos.

Encontrar y solucionar problemas de seguridad es sencillo con StackHawk. 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 basan en este modelo de simplicidad. El escáner se configura mediante YAML que se encuentra junto con el código de la aplicación que está probando. Cuando se clasifican los hallazgos de StackHawk, la plataforma intenta proporcionarle la versión más simple de la información necesaria para ayudarlo a comprender rápidamente cuál es el problema, con descripciones simples y ejemplos de patrones para ayudarlo a identificar el anti-patrón, poder recrear el problema con herramientas como un simple comando cURL para repetir el ataque y llevarlo al modo de depuración para recorrer el código lo más rápido posible y ayudarlo a solucionar problemas y volver a su trabajo regular de crear valor para sus clientes. Todo esto está habilitado para CI/CD. Nuevamente, puede integrarlo en su 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 lo desea, según la gravedad de los hallazgos sin clasificar. La mayoría de los principales logotipos de los jugadores de CI se muestran aquí en esta diapositiva y, incluso si el suyo no está, es muy probable que StackHawk funcione en su plataforma siempre que pueda ejecutar un contenedor Docker. Si puede ejecutar Docker, puede ejecutar StackHawk. También puede ver aquí que StackHawk se integra con sus herramientas de flujo de trabajo e información. Podemos notificarle los resultados del escaneo en un canal de Slack, publicar esa información en Data Dog o enviarle un mensaje de webhook simple que luego puede utilizar para procesar y hacer lo que desee con los datos.

Echemos un vistazo a cómo se ve el escáner de StackHawk en funcionamiento. Como pueden ver aquí, tengo una aplicación del lado del servidor estándar. Esta es una aplicación de encuestas que quiero probar en busca de problemas de seguridad. Así que aquí en mi línea de comandos, tengo un simple comando de Docker que ejecuté. Así que, docker run stackhawk. Le proporcioné el archivo YAML de StackHawk, lo veremos en un momento.

Como pueden ver, realizó un rastreo estándar en busca de todas las cosas interesantes en la página web que pudo encontrar, y luego realizó un ataque. Por lo tanto, atacó activamente esta aplicación en busca de posibles problemas de seguridad. Cuando todo terminó, obtuvimos un resumen de estos hallazgos.

Entonces, en realidad tengo un problema de inyección SQL que debo solucionar, pueden ver que es nuevo. También tengo un problema de scripting entre sitios con el que ya he hecho algo antes. De hecho, hice un ticket de esto. Ahora está en estado asignado. También tenemos muchas otras cosas que podemos ver, pero echemos un vistazo a esas también.

En la parte inferior, tenemos un enlace a este escaneo, por lo que podemos copiar este enlace y pegarlo en un navegador. Por cierto, la salida en un sistema CI/CD se vería muy similar a esto, porque esta es la salida estándar. Entonces, si elige interrumpir una compilación, tendría este mismo enlace en la salida de CI/CD. Podemos ir aquí a nuestro navegador web y entrar directamente en el escaneo que estamos viendo. Estábamos viendo este mismo escaneo exactamente.

Tenemos este problema de inyección SQL que podemos ver rápidamente. Pueden ver que tenemos un problema de inyección SQL. Describimos rápidamente qué es la inyección SQL, cómo remediarla, de qué se trata y qué riesgos puede representar para una aplicación. También tenemos enlaces a diferentes marcos de lenguaje que muestran el patrón de cómo prevenir la inyección SQL en Spring, Laravel, Django y Rails para que puedan ayudar a identificar el anti-patrón que estamos buscando. Echemos un vistazo a este problema en particular aquí.

Pueden ver que en la ruta SQL de PULS, tenemos un método POST que tiene algún tipo de problema. En nuestro panel derecho, tenemos una solicitud y una respuesta de lo que el escáner realmente hizo y luego regresó. Podemos ver que el escáner hizo una solicitud aquí contra la aplicación y esta respondió de alguna forma. Podemos ver que el escáner hizo una inyección de caso-cuando aquí. Podríamos reproducir esto si quisiéramos. Todo esto te ayuda a entender lo que el escáner está tratando de hacer y qué problema cree que ha encontrado. Pero interesantemente, tenemos este botón VALIDATE realmente genial aquí arriba.

Como mencioné antes, este botón VALIDATE te proporciona un comando curl de exactamente lo que el escáner hizo para identificar este problema en particular. Puedes copiar y reproducir este ataque contra una aplicación. Echemos un vistazo a ese YAML de StackHawk. Aquí pueden ver el código que he utilizado para construir mi aplicación de encuestas. Dentro de este repositorio también he almacenado el YAML de StackHawk.

El YAML de StackHawk es cómo se configura el escáner StackHawk. Entonces puedes ver la información importante que está aquí, ¿dónde encuentro la aplicación que necesito probar? En este caso, se está ejecutando en mi máquina local, en localhost 8020. ¿En qué entorno estoy y cuál es el ID de la aplicación? Esa es la cantidad mínima de información que necesitas para ejecutar un escaneo de StackHawk en tu aplicación. Hay otras piezas de información que ayudan a ajustar el escáner a tu aplicación, como la autenticación, cómo manejar cookies y tokens CSRF, así como cosas que no quieres que el escáner escanee. Si deseas agregar una especificación de OpenAPI o GraphQL, se necesita una configuración adicional mínima para hacerlo, para apuntar el escáner a esas definiciones estándar de la industria de REST API y GraphQL. Ahora, digamos que no tenemos tiempo para solucionar este problema en particular. Necesitamos lanzar esta función para nuestro cliente. Pero queremos solucionarlo, así que podemos enviar rápidamente esto a un ticket de Jira. Así que puedo enviar esto a un ticket de Jira en la nube o en el centro de datos de Jira en este momento, desde esta pantalla en particular. Así que puedo enviar este problema directamente a Jira, y ahora puedo priorizarlo y sacarlo de la lista de tareas pendientes cuando esté listo para hacerlo en el próximo sprint o en el próximo EPIC. Como verán, esto ahora se ha convertido en un problema con estado de triaje. Entonces, cuando volvamos aquí a nuestro resumen de hallazgos, pueden ver que nuestro scripting entre sitios ha sido triajeado y nuestras inyecciones SQL también han sido triajeadas. La próxima vez que el escáner encuentre estas cosas, recordará que las has triajeado y dejará de intentar llamar tu atención sobre ellas. Si has configurado las compilaciones para que se rompan, esto deshará el mecanismo de ruptura de la compilación y tu compilación continuará como de costumbre. Espero que hayas disfrutado mi charla hoy y tal vez hayas aprendido algo nuevo sobre cómo Stackhawk se puede integrar en tu flujo de trabajo de desarrollo. Si deseas probar Stackhawk y ver cómo puedes integrarlo en tu proceso de desarrollo para seguir empujando los límites en cuanto a calidad de desarrollo de software, siempre puedes comenzar una prueba gratuita en stackhawk.com y Stackhawk siempre es gratuito para usar en una sola aplicación. Gracias por ver. Espero que estés disfrutando del Congreso de Node. Que tengas un excelente día. Gracias por ver.