Pruebas de seguridad automatizadas para aplicaciones JS

Hola, Test.js Summit. ¿Cómo están? Soy Scott Gerlach, CSO y cofundador aquí en StackHawk. Gracias por tomarte el tiempo para conocer StackHawk. Espero que estén aprendiendo muchas cosas nuevas en Test.js Summit, y espero poder enseñarles una más.

En StackHawk, realizamos pruebas de seguridad de aplicaciones, específicamente pruebas de seguridad de aplicaciones dinámicas. Hablemos sobre los beneficios de DAST. DAST puede ayudarte a identificar y priorizar en qué enfocar tu tiempo para solucionar problemas, ya que ayuda a identificar lo que es descubrible y probablemente explotable en tu aplicación en ejecución. Si estás abrumado con una avalancha de tareas de auditoría de NPM, es una buena idea abordarlas. Pero a menudo la lista es larga y no todo es una simple actualización de versión. Pero además, ¿cómo sabes si el código que escribiste es seguro? ¿Y en qué deberías invertir tu tiempo si la ruta de actualización en la auditoría de NPM no es sencilla? Esta es la superpotencia de DAST.

DAST puede ayudarte a encontrar errores en tu aplicación que sean descubribles, y probablemente explotables en tu código en ejecución. Puede que estés pensando, pero los frameworks básicamente han evitado que ocurran problemas en las aplicaciones. Y sí, muchos frameworks han hecho un buen trabajo al prevenir problemas como inyecciones de SQL y scripting entre sitios. Pero la mayoría de ellos tienen la versión insegura de eso para ayudarte a hacer cosas complicadas y, desafortunadamente, cometer errores. Pero algunas personas no conocen DAST y aquellos que sí lo conocen pueden haber tenido problemas con DAST.

Veamos un ejemplo. En los viejos tiempos, cuando construíamos aplicaciones en el lado del servidor que ejecutaban la capa de datos y la capa de presentación, todo estaba bien. El escáner DAST heredado podía escanear y probar la aplicación heredada sin muchos problemas. Obtenías buenos resultados, identificabas algunos errores graves de seguridad de la aplicación y todo estaba bien. Pero luego algo cambió. Luego comenzamos a construir interfaces de JavaScript y la interfaz de JavaScript troleaba al escáner DAST heredado y cuando digo troleaba, lo digo en serio. Por ejemplo, ¿cuándo termina el desplazamiento de la página? No termina. ¿Dónde están todos los forms? Depende. El escáner DAST heredado seguía funcionando, estaba feliz, asumiendo completamente que estaba obteniendo toda la información que necesitaba para probar estas nuevas aplicaciones. Los resultados eran terribles. Los escaneos tardaban una eternidad, falsos positivos por días, etc. Y la peor parte, había alguien más en ese asiento trasero también. Nuestras APIs de respaldo están ahí controlando todos los data, hablando con los backends de almacenamiento de datos, ayudando a renderizar elementos en la página y el escáner DAST heredado cree que la interfaz está enviando todas estas solicitudes al backend. ¿Terminamos probando la API aquí? No. ¿Estamos cubriendo la API, toda la API? Probablemente no.

¿Estamos haciendo solicitudes simples a la API? Bueno, la buena interfaz de JavaScript. Depende. Depende del navegador o emulador de navegador que esté utilizando la herramienta DAST heredada y qué tan bien lo esté conduciendo. Qué elementos puede ver, qué puede renderizar. Si has incorporado soporte en tu interfaz de aplicación JavaScript para versiones específicas de navegadores específicos. Ahora puedes pensar en esto como scripts de Selenium. Y en los scripts de Selenium, escribes una prueba específica. Quiero ir a esta página y luego quiero hacer clic en este botón y luego esto debería aparecer, ¿verdad? Ese tipo de prueba de Selenium. DAST es así, excepto que esperas que encuentre todas las posibles rutas de entrada de usuario por sí mismo y haga un buen trabajo. Simplemente no va a suceder. No funciona bien. Entonces, ¿cómo podemos volver a pruebas mejores, mejores resultados, escaneos más rápidos y más precisos, descubriendo estos errores de seguridad de aplicaciones que están integrados en nuestras aplicaciones JavaScript ahora? La clave aquí es conducir la API directamente. Utilizando estándares de la industria como colecciones de Postman, especificaciones de OpenAPI, GraphQL, consultas de introspección, puedes tener acceso directo a la API, comprender lo que hace y los datos que controla y obtener pruebas rápidas y exhaustivas. No importa si estás construyendo una API que no tiene una interfaz en absoluto. Mente explotada. Aún hay cosas buenas que encontrar en la prueba de la interfaz en la configuración de cookies y XSS del DOM. Comenzar protegiendo todos los datos que podrías terminar poniendo en riesgo es un mejor punto de partida. ¿Cuáles son algunas de las claves a tener en cuenta en una herramienta de prueba de aplicaciones dinámicas que te ayudará a probar las API directamente? En primer lugar, que se pueda ejecutar en cualquier lugar. Debe poder ejecutarse en tu CI/CD, debe poder ejecutarse en producción, pero lo más importante, debe poder ejecutarse en tu localhost mientras estás desarrollando. Debe poder proporcionar datos de prueba reales, por lo que en las capturas de pantalla que tenemos aquí, hemos activado la biblioteca Faker para que Faker proporcione datos. En realidad, hemos ingresado datos para algunos valores. Muchas opciones diferentes para poder decir, `oye, API, así es como se ve realmente los datos`. Úsalo también con tus pruebas de seguridad. Ejecuta pruebas personalizadas para el control de acceso roto y el acceso directo inseguro a objetos. Estas son dos de las principales cosas de seguridad de API de OWASP, y son difíciles de probar sin conocimiento sobre cómo funciona la API. A medida que desarrollas la API, puedes escribir cosas como verificaciones de tenencia, ¿puede el cliente A ver los datos del cliente B? Busca cosas como, ¿puede un usuario regular acceder a las funciones de administrador? Esas son algunas de las cosas realmente difíciles de probar. Ahora puedes escribir esa prueba una vez y seguir ejecutándola una y otra vez para asegurarte de que la API permanezca segura. Como dije, debes buscar algo que esté diseñado para escanear aplicaciones modernas, incluidas aplicaciones del lado del servidor, aplicaciones de una sola página, APIs REST, APIs GraphQL y APIs SOAP. Todo esto conduce a una prueba de seguridad de aplicaciones más rápida, un tiempo de corrección más rápido y una vuelta más rápida a tu trabajo regular de generar valor en la aplicación que estás construyendo.

¿Cómo funciona StackHawk? 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. Cuando se clasifican los hallazgos de StackHawk, la plataforma te proporciona 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 antipatrones.

Puedes recrear el problema con herramientas como simples comandos curl para reproducir el ataque, y luego entrar en modo de depuración en tu IDE y comenzar a revisar el código lo más rápido posible para solucionar esos problemas y volver a tu trabajo regular. Todo esto está habilitado para CI/CD. Nuevamente, puedes integrarlo en tu proceso de CI y, lo que es más importante, recibir comentarios en el proceso de CI y los hallazgos del escaneo. Esta información se puede utilizar para detener una compilación si así lo deseas, según la gravedad de esos hallazgos no clasificados. La mayoría de los principales actores de CI están integrados con StackHawk. La documentación está disponible en docs.stackhawk.com si estás interesado. Si tu versión particular de CI no está en la lista, es muy probable que StackHawk funcione con ella siempre y cuando puedas ejecutar Docker o un proceso de Java.

Aquí está quizás la parte más importante. Como mencioné antes, puedes ejecutar estas mismas pruebas de AppSec localmente que puedes hacer en CI. Por lo tanto, puedes identificar un problema, solucionarlo y validar que lo has solucionado localmente antes de enviar tu código de vuelta al pipeline de CI/CD, cruzar los dedos y esperar que esta vez lo haya logrado. Espero que hayas disfrutado mi charla hoy y tal vez hayas aprendido algo nuevo sobre StackHawk y cómo se puede integrar en tu desarrollo de API y flujo de trabajo de pruebas. Si deseas 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. Gracias por ver y disfruta el resto de TestJS Summit. ♪♪♪