Pruebas automatizadas de seguridad de aplicaciones

¿Qué tal, gente de React? Soy Scott Gerlach, cofundador y oficial principal de seguridad aquí en StackHawk. Espero que estén disfrutando mucho de la React Summit.

Hablemos de StackHawk. En pocas palabras, StackHawk es una herramienta dinámica de pruebas de seguridad de aplicaciones. Puedes usarla para probar tus aplicaciones HTTP en ejecución y los puntos finales de la API en busca de errores de seguridad y evitar que se vuelvan vulnerables. Puedes utilizar StackHawk para realizar pruebas de seguridad activas 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 formar parte de tu sólida estrategia de pruebas en el ciclo de vida del desarrollo de tu aplicación. También facilita la búsqueda, comprensión y solución de errores de seguridad.

¿Cómo funciona StackHawk, preguntas? ¡Excelente pregunta! StackHawk realiza pruebas de seguridad activas en tus aplicaciones en ejecución para asegurarse de que tu aplicación maneje la entrada y salida del usuario de manera segura, y también implementa las mejores prácticas OWASP top 10 para la seguridad de aplicaciones. 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 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, especificación OpenAPI, 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 están construidos en torno a este modelo de simplicidad. El escáner se configura a través de 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 proporcionarte 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 anti-patrón, poder reproducir el problema con un simple comando curl para repetir el ataque, y llevarte al modo de depuración para revisar el código lo más rápido posible y 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 hallazgos de las pruebas. Esta información se puede utilizar para interrumpir una compilación si así lo deseas. Según la gravedad de los hallazgos no clasificados, se muestran los logotipos de la mayoría de los principales jugadores de CI aquí en esta diapositiva, y aunque el tuyo en particular no esté, es muy probable que Stackhawk funcione en tu plataforma siempre y cuando 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 de las pruebas en un canal de Slack, publicar esa información en Data Dog, o enviarte un mensaje simple de web hook que luego puedes 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 Pulse que quiero probar en busca de problemas de seguridad. Así que aquí en mi línea de comandos, tengo un simple comando Docker que ejecuté. Docker run Stackhawk, le pasé el archivo stackhawk.yaml, lo veremos en un momento. Como puedes ver, hizo un rastreo estándar en busca de todas las cosas interesantes en la página web que pudo encontrar, y luego realizó 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. Así que en realidad tengo un problema de inyección SQL que debo solucionar, puedes ver que es nuevo. También tengo un problema de scripting entre sitios con el que ya he hecho algo antes, en realidad hice un ticket de esto. Así que ahora está en estado asignado. También tenemos muchas otras cosas que podemos ver. Pero echemos un vistazo a esos dos.

Aquí abajo, 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 CICD se vería muy similar a esto, porque esta es la salida estándar. Así que si eligieras romper una compilación, tendrías este mismo enlace en la salida de CICD. Así que podemos ir aquí a nuestro navegador web y entrar directamente en el escaneo que estábamos viendo. Estábamos viendo este mismo escaneo exacto. Tenemos este 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 plantear 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 POST que tiene algún tipo de problema. En nuestro panel derecho, tenemos una solicitud y 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 Case When aquí. Podemos reproducir esto si queremos. Todo esto te ayuda a comprender lo que el escáner está tratando de hacer y qué problema cree que ha encontrado. Pero, interesantemente, tenemos este botón de Validar muy genial aquí arriba. Como mencioné antes, este botón de Validar te proporciona un comando curl de exactamente lo que el escáner hizo para identificar este problema en particular. Entonces, puedes copiar y reproducir 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 se encuentra aquí, ¿dónde encuentro la aplicación que necesito probar? En este caso, se está ejecutando en mi máquina local, así que localhost:8020. ¿En qué entorno estoy? ¿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 API abierta 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 API REST y GraphQL.

Ahora supongamos que no tenemos tiempo para solucionar este problema en particular. Necesitamos lanzar esta función para un cliente, pero queremos solucionarlo, así que podemos enviar esto rápidamente a un ticket de JIRA. Puedo enviar esto a un ticket de JIRA Cloud o JIRA DataCenter desde esta pantalla en particular. 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 la próxima época.

Como verás, esto ahora se ha convertido en un problema con estado clasificado, así que cuando volvamos aquí a nuestro resumen de hallazgos, puedes ver que nuestro scripting entre sitios ha sido clasificado y nuestras inyecciones SQL también han sido clasificadas. La próxima vez que el escáner encuentre estas cosas, recordará que las has clasificado 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 de mi charla hoy y tal vez hayas aprendido algo nuevo sobre cómo StackHawk podría integrarse 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 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 vernos a todos! Espero que disfruten realmente de React Summit. ¡Ven a vernos!