Pruebas automatizadas de seguridad de aplicaciones

¿Qué tal TestJS Summit? Soy Scott Gerlach, Oficial Principal de Seguridad y Cofundador aquí en StackHawk. Gracias por tomarte el tiempo para conocer StackHawk y espero que estés teniendo una gran conferencia con TestJS Summit. En pocas palabras, StackHawk es una herramienta de prueba de seguridad de aplicaciones dinámicas. Puedes usarla para probar tus aplicaciones HTTP en ejecución y puntos finales de API en busca de errores de seguridad y evitar que se vuelvan vulnerables. Puedes usar StackHawk para realizar pruebas activas de seguridad en tu API REST en ejecución, API GraphQL, API SOAP, aplicación del lado del servidor y aplicaciones de una sola página. StackHawk fue diseñado para la automatización y CI/CD para ser parte de tu estrategia sólida de pruebas para el ciclo de vida de desarrollo de tu aplicación. También facilita encontrar, comprender

y solucionar bugs de seguridad es fácil. ¿Cómo funciona StackHawk te preguntas? Excelente pregunta. StackHawk realiza pruebas de seguridad activas en tus aplicaciones en ejecución para asegurarse de que tu 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 tu aplicación en ejecución en tu host local, en flujos de trabajo de CI CD y en 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 utilizando estándares abiertos para informar al escáner, especificación de API abierta, GraphQL, consultas de introspección de SOAP, WSDL, además de la sintonizació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 simple con StackHawk. Nuestro enfoque como empresa es ayudar a los desarrolladores a encontrar y, lo más importante, solucionar problemas de seguridad. El escáner y la plataforma de StackHawk están construidos en torno a 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ás probando. Cuando se clasifican los hallazgos de StackHawk, la plataforma intenta brindarte la versión más simple de la información necesaria para ayudarte a comprender rápidamente cuál es el problema con descripciones simples y ejemplos de patrones para ayudarte a identificar el antipatrón, poder recrear el problema con herramientas como el comando curl para repetir el ataque y ponerte en modo de depuración, recorriendo el código lo más rápido posible para ayudarte a solucionar problemas y volver a tu trabajo regular de crear valor para tus clientes. Todo esto está habilitado para CI-CD. Nuevamente, puedes integrar esto en tu proceso de CI y, lo que es más importante, obtener comentarios en el proceso de CI sobre los hallazgos del escaneo. Esta información se puede utilizar para interrumpir una compilación si así lo deseas, según la gravedad de los hallazgos no clasificados. La mayoría de los logotipos de los principales jugadores de CI se muestran aquí en esta diapositiva y aunque tu plataforma en particular no esté, es muy probable que StackHawk funcione en tu plataforma siempre que pueda ejecutar un contenedor Docker. Si puedes ejecutar Docker, puedes ejecutar StackHawk. También puedes ver aquí que StackHawk se integra con tu flujo de trabajo y herramientas de información. Podemos notificarte los resultados del escaneo en un canal de Slack, publicar esa información en Datadog o enviarte un mensaje simple de webhook que luego puedes utilizar para procesar y hacer con los datos lo que elijas. Echemos un vistazo a cómo se ve el escáner de StackHawk en funcionamiento. Como puedes ver aquí, tengo una aplicación del lado del servidor estándar. Esta es una aplicación de extracción de solicitudes 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é. Entonces Docker run StackHawk, le proporcioné el archivo YAML de StackHawk, lo veremos en un segundo. Como puedes ver, hizo un rastreo estándar, buscando todas las cosas interesantes en la página web que pudo encontrar, y luego hizo un ataque. Así que atacó activamente esta aplicación en busca de posibles problemas de seguridad. Cuando todo terminó, obtuvimos un resumen de estos hallazgos. De hecho, tengo un problema de inyección SQL que debo solucionar. Puedes ver que es nuevo. También tengo un problema de scripting entre sitios que ya he solucionado antes. De hecho, hice un ticket con esto. Así que ahora está en estado asignado. También tenemos muchas otras cosas que podemos ver, pero echemos un vistazo

también. Aquí, en la parte inferior, tenemos un enlace a este escaneo. Así que podemos tomar 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 eligieras interrumpir una compilación, tendrías este mismo enlace en la salida de CI/CD. Así que podemos ir aquí a nuestro navegador web y entrar directamente en el escaneo que estamos viendo. Estábamos viendo este mismo escaneo. Tenemos el problema de inyección SQL que podemos ver rápidamente. Puedes ver que tenemos un problema de inyección SQL. Estamos describiendo 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 frameworks de lenguaje que muestran el patrón de cómo prevenir la inyección SQL en Spring, Laravel, Django y Rails, para que puedas ayudar a identificar el anti-patrón que estamos buscando. Echemos un vistazo a este problema en particular aquí. Podemos ver que en la ruta SQL de las encuestas, tenemos un método de envío 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. De hecho, podemos ver que el escáner hizo una inyección de caso aquí, así que podríamos reproducir esto si quisiéramos. Todo esto ayuda a comprender lo que el escáner intenta hacer y qué problema cree que ha encontrado. Pero interesantemente, tenemos este botón de validación realmente genial aquí arriba. Como mencioné antes, este botón de validación te proporciona un comando curl de exactamente lo que el escáner hizo para identificar este problema en particular. Entonces, puedes copiar y repetir este ataque contra una aplicación.

Echemos un vistazo a ese YAML de StackHawk. Aquí puedes ver el código que he usado 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 de StackHawk. Entonces, puedes ver la información importante que está aquí es ¿dónde encuentro la aplicación que necesito probar? En este caso, se está ejecutando en mi máquina local, en local-host 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 deseas que el escáner escanee. Si deseas agregar una especificación de Open API o GraphQL, se necesita una configuración adicional mínima para que eso suceda y apuntar el escáner a esas definiciones estándar de la industria de API REST 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 Jira

ticket. Así que puedo enviar esto a un ticket de Jira Cloud o Jira data center ahora mismo desde esta pantalla en particular. Así que puedo enviar este problema directamente a Jira, y ahora puedo priorizarlo y sacarlo del backlog cuando esté listo para hacerlo en el próximo sprint o en la próxima épica. Como verás, esto ahora se ha convertido en un problema con estado de triaje. Entonces, cuando volvamos aquí a nuestro resumen de hallazgos, verás que nuestro cross-site scripting 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 ya las has triajeado y dejará de intentar llamar tu atención sobre ellas. Si has configurado las compilaciones para que se interrumpan, esto deshará el mecanismo de interrupción de la compilación y tu compilación continuará normalmente. Espero que hayas disfrutado mi charla hoy y tal vez hayas aprendido algo nuevo sobre cómo StackHawk puede integrarse en tu flujo de trabajo de desarrollo. Si quieres probar StackHawk y ver cómo puedes integrarlo en tu proceso de desarrollo para seguir empujando los límites en la calidad del 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. Disfruta del TestJS Summit.