Pruebas automatizadas de seguridad de aplicaciones

¿Qué tal, gente de DevOpsJS? Scott Kerlock, CSO y cofundador aquí en StackHawk. Espero que estén teniendo un gran tiempo aprendiendo mucho aquí en DevOpsJS.

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 security errores 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 como parte de tu sólida estrategia de pruebas para el ciclo de vida del desarrollo de aplicaciones. También facilita encontrar, comprender y solucionar errores de seguridad. ¿Cómo funciona StackHawk, preguntas? ¡Gran pregunta! StackHawk realiza pruebas de seguridad activas en tus aplicaciones en ejecución para garantizar que tu aplicación maneje de manera segura la entrada y salida del usuario, así como implementar las mejores prácticas de seguridad de aplicaciones OWASP top 10. Podemos hacer esto en tu aplicación en ejecució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 hacemos 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 OpenAPI, GraphQL y consultas de introspección, SOAP y 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 10 minutos o menos.

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 comprender 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 el comando curl para repetir el ataque y ponerte en modo de depuración, avanzando rápidamente a través del código para ayudarte a solucionar problemas y volver a tu trabajo habitual de crear valor para tus clientes.

Todo esto es compatible con CI/CD. Nuevamente, puedes integrarlo en tu proceso de CI y, lo que es más importante, obtener comentarios sobre los hallazgos 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. Aquí se muestran los logotipos de la mayoría de los principales jugadores de CI, y aunque tu plataforma en particular no esté aquí, es muy probable que StackHawk funcione en ella siempre que pueda ejecutar un contenedor Docker. Si 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 de webhook simple que luego puedes utilizar para procesar y hacer lo que desees con los datos.

Echemos un vistazo a cómo se ve la ejecución del escáner de StackHawk. Como puedes 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. Aquí en mi línea de comandos, tengo un simple comando Docker que ejecuté. Así que ejecuté 'docker run stackhawk'. Le proporcioné el archivo YAML de StackHawk, lo veremos en un momento. Como puedes ver, hizo un rastreo estándar buscando 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. En realidad, tengo un problema de inyección SQL que debo solucionar. Puedes ver que es nuevo. También tengo un problema de cross-site scripting con el que ya hice algo antes. De hecho, hice un ticket con esto. Ahora está en estado asignado. Tenemos muchas otras cosas que también podemos ver, pero echemos un vistazo a eso también. Aquí en la parte inferior, en realidad tenemos un enlace a este escaneo.

Entonces, 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. Así que si eligieras interrumpir una compilación, tendrías el mismo enlace en la salida de CI/CD.

Entonces, podemos ir aquí a nuestro navegador web y entrar directamente en el escaneo que estábamos 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 remediarlo, 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 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 de caso-cuando aquí. Podríamos reproducir esto si quisiéramos. 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 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. Así que 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 de StackHawk. Puedes ver la información importante que se encuentra aquí es 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 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 OpenAPI o GraphQL, se necesita una configuración adicional mínima para que eso suceda 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.

Entonces podemos enviar esto rápidamente a un ticket de JIRA. Así que puedo enviar esto a un ticket de JIRA Cloud o JIRA Data Center 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 el próximo EPIC.

Como verás, esto ahora se ha convertido en un problema clasificado. Así que cuando volvamos aquí a nuestro resumen de hallazgos, podrás ver que nuestro Cross-Site scripting ha sido clasificado y nuestras inyecciones SQL han sido clasificadas. La próxima vez que el escáner encuentre estas cosas, recordará que ya las has clasificado y dejará de intentar llamar tu atención sobre ello. 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 de 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. Eso es todo por mi parte, gracias por ver. Espero que tengas un buen tiempo en DevOpsJS. No olvides agradecer a alguien por las cosas que aprendiste hoy.