Pruebas automatizadas de seguridad de aplicaciones

¿Qué pasa JS Nation? Soy Scott Gerlach, co-fundador y oficial principal de seguridad en StackHawk. Espero que estén disfrutando mucho de JS Nation y aprovechándolo al máximo.

Hablemos de StackHawk. Rápidamente, StackHawk es una herramienta dinámica de pruebas de seguridad de aplicaciones. 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 utilizar StackHawk para ejecutar pruebas de seguridad activas en tus 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 y CI/CD, para ser parte de tu sólida estrategia de pruebas para el ciclo de vida del desarrollo de aplicaciones. También facilita encontrar, entender y solucionar errores de seguridad.

¿Cómo funciona StackHawk, preguntas? Excelente pregunta. StackHawk ejecuta 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 implemente las 10 mejores prácticas de OWASP para la seguridad de aplicaciones. Podemos hacer esto en tu aplicación en tu localhost, 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 clientes de StackHawk se escanean en un promedio de menos de diez minutos.

Encontrar y solucionar problemas de seguridad es simple 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 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 entender rápidamente cuál es el problema con descripciones simples y ejemplos de patrones para ayudarte a identificar el anti-patrón, poder recrear el problema con herramientas como un simple comando curl para reproducir el ataque, y entrar en el 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 integrarlo en tu proceso de CI y, lo que es más importante, obtener comentarios sobre los resultados del escaneo en el proceso de CI. 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 incluso si el tuyo en particular no está, es muy probable que Stackhawk funcione en tu plataforma siempre y cuando pueda ejecutar un contenedor Docker. Puedes ejecutar Docker, puedes ejecutar Stackhawk. También puedes ver aquí que Stackhawk se integra con tus herramientas de flujo de trabajo e 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 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é. Así que Docker run Stackhawk.

Le proporcioné el YAML de StackHawk. Lo veremos en un segundo. Como puedes 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. Así que atacó activamente esta aplicación en busca de posibles problemas de seguridad. Cuando terminó, obtuvimos un resumen de estos hallazgos.

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 en el que ya hice algo antes. De hecho, hice un ticket con esto, así que ahora está en estado firmado. También tenemos otras cosas que podemos analizar, pero echemos un vistazo a esas también.

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 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 estábamos viendo. Estábamos viendo este mismo escaneo exactamente. 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 de la derecha, 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 de caso cuando aquí. Podemos reproducir esto si queremos. Todo esto te ayuda a entender lo que el escáner está tratando de hacer y qué problema cree que ha encontrado. Curiosamente, tenemos este botón de validación muy útil 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. 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 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. Puedes ver la información importante que se encuentra aquí, como dónde encontrar la aplicación que necesito probar. En este caso, se está ejecutando en mi máquina local, en 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 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 API REST y GraphQL. Ahora supongamos que no tenemos tiempo para solucionar este problema en particular. Necesitamos lanzar esta función para nuestro cliente. Pero queremos solucionarlo. Entonces podemos enviar rápidamente esto a un ticket de JIRA. Puedo enviar esto a un ticket de JIRA Cloud o JIRA Data Center en este momento desde esta pantalla en particular. Así puedo enviar este problema directamente a JIRA, y ahora puedo priorizarlo y sacarlo de la lista de 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 de triaje. Entonces, cuando volvamos aquí a nuestro resumen de hallazgos, verás 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 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 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. StackHawk siempre es gratuito para usar en una sola aplicación. Gracias por ver, a todos. Espero que estén disfrutando mucho de JS Nation. Ven a vernos en StackHawk.