Plantas vs Ladrones: Pruebas Automatizadas en el Mundo de la Seguridad Web

Hola a todos, y estoy muy feliz de verlos aquí, o, bueno, no puedo verlos a través de la pantalla, pero sé que están ahí. Estoy feliz de tenerlos aquí en React Day Berlin. Y de hecho, esta charla fue una de las razones por las que me puse nostálgico al prepararla. Y no es solo la época navideña, y por supuesto esto también me da sentimientos nostálgicos también.

Es el tema de mi charla, de hecho. Tal vez algunos de ustedes ya reconozcan el título. Pero supongo que este es un tema que los mantendrá alejados del ambiente navideño, al menos por un poco, ¿de acuerdo? En el lado técnico, esta charla es sobre seguridad y sobre pruebas. Así que dos temas que me apasionan y que realmente amo. Y espero que podamos construir algunas defensas maravillosas usando la automatización de pruebas.

Bien, las pocas personas que ya podrían haber captado esta cosa de la nostalgia, tal vez reconozcan la fuente en el título o el título en su totalidad, Plants vs. Beefs, porque se deriva de Plants vs. Zombies. Este es un juego creado por PopCup, la compañía se llamaba así, en 2009, creo. Sí. Y fue un juego maravilloso, multiplataforma, de hecho el único juego que jugué en mi teléfono móvil porque soy un jugador de consola y PC, pero eso no es importante ahora.

Es un juego de defensa de torres donde intentas básicamente defender una base contra enemigos, ¿verdad? Y en Plants vs. Zombies, como el nombre ya lo implica, intentarás proteger tu casa contra zombis en un apocalipsis zombi. Lo sé, no es muy navideño, pero un apocalipsis zombi usando plantas dentro de tu jardín. Bueno, por supuesto, esta es una maravillosa alegoría, ¿verdad? Es nostálgico, es nerd, pero ¿qué tiene que ver eso con el desarrollo web?

Bueno, ¿y si te dijera que es una maravillosa alegoría sobre la seguridad web? Realmente lo creo porque, veámoslo así, tenemos un zombi, que es una amenaza y atacante, un riesgo de seguridad y explotar cualquier cosa que podría ser un peligro para tu sistema, ¿verdad? Y la planta aquí, es la contramedida, la estrategia de mitigación, una solución de seguridad, cualquier cosa que podría proteger tu aplicación contra atacantes, contra esos riesgos de seguridad o exploits. Con una lente más general aquí, puedes ver que la casa es básicamente el área protegida, la parte protegida en nuestra aplicación que podría ser datos que queremos proteger porque es sensible, es importante.

O queremos cumplir con las leyes, necesitamos proteger nuestros datos o proteger características porque queremos que las personas básicamente paguen algo de dinero por aplicaciones, ¿verdad? O al menos ser usuarios registrados de los que sabemos. Así que la propiedad aquí, la cosa completa, incluyendo la casa, incluyendo el jardín, son nuestras defensas contra esos trucos. Así que defensas contra los zombis, ¿verdad? Y defensas contra amenazas de seguridad. Así que si consideramos nuestro jardín, nuestras defensas, construyamos nuestro jardín, ¿verdad? Porque nuestras plantas dentro de este jardín son nuestras líneas de defensa. Todas las defensas que tenemos bajo nuestro cinturón. Y mi primer pensamiento sería como, de acuerdo, mejores prácticas. Somos geniales construyendo nuestras aplicaciones de una manera segura, ¿verdad? Las pruebas pueden ser una idea también, en mi mente, al menos. No solo porque me apasionan las pruebas, porque sé que podría ayudarnos y ser una línea de defensa también. Entonces, ¿pueden las pruebas ayudarnos? Y por supuesto, el primer pensamiento dentro de mi mente, y supongo que en sus mentes también, es herramientas, como Sonocube, como Snick, o todas esas cosas que prueban problemas de seguridad y te notifican. Pero, por supuesto, sería el camino fácil.

Simplemente diría algo así como, está bien, paguemos por algunas herramientas, instalémoslas, aprendámoslas, eso es todo. Bueno, ¿y si no quiero aprender nuevas herramientas o gastar dinero en, de nuevo, nuevas herramientas, si no quiero depender de terceros, básicamente, verdad? ¿O si quiero aprender lo que esas herramientas ya están haciendo? Bueno, hay muchas razones para optar por las pruebas también. E incluso si es solo una línea de defensa entre muchas.

Pero antes de eso, rápidamente, déjame hacer el importante descargo de responsabilidad o una mención honorable donde lo compraste. Aprende tu aplicación. Sigues siendo la persona más importante a cargo, ¿verdad? Esto se reflejará en tus esfuerzos de prueba, pero generalmente en la calidad de tu aplicación también. Así que aprende las vulnerabilidades de tu aplicación para que sepas cómo construir tu aplicación de manera segura. Y por supuesto, sabe qué probar, pero llegaremos a eso un poco más tarde.

Y ten en cuenta una cosa, las pruebas son siempre el mensajero, no más que eso porque solo te notificarán sobre problemas de seguridad, aún necesitas actuar por tu cuenta. Así que básicamente, ten en cuenta que todavía juegas un papel en eso. No puedes automatizar todo, pero escucha las advertencias, escucha a tu mensajero, escucha las pruebas.

Bien, entonces, ¿cómo podemos aprender nuestra aplicación y aprender vulnerabilidades y aprender dónde mirar para escribir esas pruebas? Bueno, hay un grupo de personas o un proyecto que nos ayuda mucho. Se llama OWASP, que es una abreviatura de Open Worldwide Application Security Project. Y es un proyecto cuyo objetivo es aumentar la seguridad dentro de la web. Así que publicaron un ranking de los 10 principales riesgos de seguridad más importantes, y lo actualizan en un cierto ritmo. Supongo que el último fue en 2021. Y hasta donde sé, ahora en diciembre, están recopilando el conjunto de datos para un nuevo ranking en 2025. Así que mantente atento, podría haber algunos cambios, pero por ahora, el de 2021 es el último ranking y es el más reciente. Así que para eso, echaremos un vistazo a los tres principales riesgos. Así que alerta de spoiler, todos somos desarrolladores front-end, estamos haciendo React, e incluso si estás usando otros frameworks, todavía estás trabajando en front-end.

Así que hay un punto que miraremos explícitamente porque es importante para los desarrolladores front-end. Pero llegaremos a eso. No quiero apresurarme en esta charla, aunque seré consciente de tu tiempo. Bien, entonces, ¿dónde mirar? Como se dijo, los tres riesgos más importantes según OWASP, que son el primero, el más importante de todos, el control de acceso roto, lo que significa que un usuario puede actuar fuera de sus permisos, pudiendo leer o cambiar cosas que no deberían poder. El segundo será la inyección. No, voy demasiado rápido, lo siento. Es el fallo criptográfico. Así que básicamente, que las necesidades criptográficas no se cumplen. Las cosas no están debidamente encriptadas. Tal vez datos, tal vez conexión, no estás usando HTTP, cosas así.

Así que este es el rango dos. Y finalmente, donde fui un poco demasiado rápido, y supongo que ya lo adivinaste que este es nuestro punto de enfoque, es la inyección. Si un atacante proporciona una entrada no confiable a tu programa, básicamente, el código del atacante será compilado, interpretado y ejecutado como si fuera tu propio código, lo cual es bastante malo, ¿no es así? Así que sí, estos son los tres principales. La inyección es nuestro enfoque principal y sí, echemos un vistazo a cómo las pruebas pueden ayudarnos en este sentido. Y podrías haberlo adivinado, pero no es un gran problema si no porque estás aquí básicamente para aprender sobre ello. Intentaremos combatir los problemas de seguridad escribiendo nuestras pruebas, escribiendo pruebas adecuadas, usando casos de prueba para cubrir algunos problemas de seguridad. Y en esta charla, uso pruebas de extremo a extremo y Cypress para mis ejemplos, pero trato de ser lo más agnóstico posible. Así que si estás usando Playwright, Test Buffet, o incluso eres lo suficientemente valiente como para usar Selenium, lo siento, no importa qué marco de automatización de pruebas uses, en la mayoría de los casos, no todos, pero en la mayoría de los casos, puedes hacerlo en otros marcos también. Y sí, echemos un vistazo a cómo diseñar nuestros casos de prueba, especialmente para la inyección. Porque es un ejemplo perfecto porque sí, es fácil de reproducir, ¿verdad? Como las pruebas de extremo a extremo básicamente simulan usuarios reales, pueden simular un atacante real. Y sí, mis pensamientos sobre eso serían como tener una prueba negativa donde básicamente intentas inyectar un script o algún SQL en algún campo de entrada, cosas así, para un formulario de muestra, por ejemplo, y como siguiente paso, tal vez incluso aleatorizar los campos de entrada que elijas, ¿verdad? Bueno, veamos si esto está funcionando. UvaSp de alguna manera, afortunadamente, nos ayudará en este sentido porque tienen un DemoChop. Es una tienda en línea, que es insegura y un poco sofisticada por diseño. Así que está rota. No es segura. No la uses en producción, pero tal vez ejecútala en un contenedor Docker y prueba todas las cosas que hicieron mal. Incluso tienen desafíos para practicar. Así que básicamente, hackea la tienda. Y en esta charla, de hecho, haremos dos desafíos como casos de prueba. Sí, el primero. Vamos por la prueba. Así que como ves, iremos por esta letra del menú, que es el conteo de NAVBAR. Debería ser visible, renderizado para que podamos interactuar con él, y lo hacemos clic para abrir el menú. Luego, habrá un punto para iniciar sesión, que copié de antemano. Igual que debería ser visible, así que está renderizado, y quiero hacer clic en él para llegar al formulario de inicio de sesión, ¿verdad? Bien, veamos si la prueba ya lo está haciendo. Bien, ahí vamos. El formulario de inicio de sesión está ahí. Obtengamos el selector copiándolo del corredor de pruebas aún visible. Y luego, queremos escribir todas las cosas que necesitamos, como iniciar sesión. No estamos usando un correo electrónico o algo válido, pero iremos por una pequeña parte de una consulta.

Esta consulta se usará básicamente en lugar del problema, un problema, y obtendrá el primer usuario de la base de datos para iniciar sesión. En este sentido, la contraseña no importará porque lo haremos mediante integración SQL, exactamente, como podrías haber adivinado. Vamos a enviar el formulario. Para tener una prueba adecuada, que debería fallar, quiero tener un mensaje de error allí también. Echemos un vistazo. Quiero hacer clic en él, habilitarlo, para que podamos iniciar sesión.

Estaba un poco confundido. Ahora, solo quiero tener un inicio de sesión inválido para tener un mensaje de error para probar un correo electrónico o contraseña inválidos. Veamos si el error aparecería. No lo hará, pero por supuesto, vamos por una prueba adecuada. Intentemos no usar errores tipográficos aquí. Tengo un error tipográfico allí. Volvamos y ejecutemos la prueba. Debería fallar ahora porque, como ves, hemos iniciado sesión. Podemos ver la cesta del usuario. Podemos ver el mensaje de la cuenta. Podemos ver el menú. Podemos ver todo. Bastante malo, ¿verdad?

Si quieres detectar inyecciones mediante una prueba, puedes intentar escribir una prueba negativa, que es una prueba que escucha el comportamiento de error y trata de ver básicamente qué sucede si haces una inyección adicional dentro de un campo de entrada. También podrías optar por otra forma de prueba cuando se trata de políticas de seguridad de contenido, lo cual es bastante genial, como la prueba de CFP usando Cypress. Este ejemplo es tomado por Gleb Bamutov, quien es un autor maravilloso escribiendo un maravilloso artículo. Si quieres echarle un vistazo, hay un código QR. También puedes verificar los encabezados CSP. Básicamente, el CSP, política de seguridad de contenido, definirá fuentes confiables para el contenido, que está permitido cargar, así que básicamente lo que está listado.

Para probar eso, puedes optar por la configuración de Cypress para habilitarlo. La lista de permitidos de CSP experimental necesitaría listar los encabezados que deseas revisar. Entonces, básicamente puedes verificarlo. Tal vez en una prueba de API, donde intentas verificar los encabezados que están allí y son válidos, o puedes optar por un caso de prueba normal como aquí, donde básicamente simulas un ataque de seguridad mediante validaciones de CSP, donde deberías verlo bloqueado. Si deseas tener más detalles, porque quiero ser consciente de tu tiempo, intenta echar un vistazo al artículo de Gleb. Es bastante genial.

Bueno, sería realmente malo si no cubro el problema número uno, ¿verdad? Control de acceso roto. Aunque la mayoría de las cosas allí serán hechas por el backend, como los roles de usuario. Puedes pensar en usar herramientas como FGA o OpenFGA para tener un RBAC, como básicamente control de recursos, control de acceso, la solución en su lugar. También puedes echar un vistazo a las pruebas, porque escribir un caso de prueba adecuado puede ayudarte aquí también. Lo siguiente es simular un usuario con permisos insuficientes intentando hacer algo o intentando leer cosas, información que no se les permite leer. Así que, sí, echemos un vistazo a eso.

Volveré al ejemplo de ovas produce. Así que, vamos a echar un vistazo. Allí, hacemos el inicio de sesión basado en la primera prueba como hicimos antes. Lo puse en un comando personalizado para ahorrarnos tiempo. Visito la tienda y quiero ir al panel de administración, al que deberíamos poder llegar como un cliente normal de la tienda, ¿verdad? Así que, obtengamos la tarjeta que tenemos, que es básicamente la misma que en el formulario de inicio de sesión también. Debería ser visible para que la página esté cargada, podamos interactuar. Y luego veamos si estamos bloqueados. Entonces, aparece un error 403 u otro mensaje de error. Veamos si esto realmente está sucediendo. Así que, veamos cuando lo estoy probando por mi cuenta. Sí, 403, no tienes permitido acceder a esta página, así que podemos guiarnos por este mensaje de error. Bien, vamos. Echemos un vistazo allí. ¿Qué pasa si estamos ejecutando la prueba? Así que, vamos por control de acceso roto. Iniciaremos sesión y veremos la vista general de administración, ¿verdad? Esto es bastante subóptimo, digamos así. Así que, sí, la prueba fallará, lo cual es válido porque queríamos tener una prueba negativa. Pero como ves, pudimos acceder a la página de administración. No estamos bloqueados al hacerlo.

La prueba es un mensajero que nos permite ver que hay un problema. Bien, algunas palabras pequeñas para fallos criptográficos también. Y aunque esto es más un tema de backend también, la automatización de pruebas puede ayudarte con esto también. Así que, está incorporado básicamente si usas Cypress, por ejemplo. Como Cypress funciona desde dentro del navegador, necesitan adherirse a las reglas de la política de mismo origen lo que llevará a Cypress a dar error cada vez que intentes navegar de regreso a un sitio HTTP cuando estabas usando HTTPS antes. Así que básicamente, las pruebas de Cypress fallarán si tienes un fallo de cifrado en tu página, lo cual es bastante genial, ¿verdad? Así que no necesitamos escribir nada como un caso de prueba o algo así.

Pero aún así, podrías decir, bueno, las pruebas tienen un gran defecto, ¿verdad? Bueno, ¿cómo manejamos problemas de seguridad que no conocemos en este momento? Obviamente, las bases de datos CVE están ahí para eso, pero no siempre podemos revisarlas, ¿verdad? Entonces, ¿cómo podemos manejar tales problemas?

Bueno, hay herramientas que te pueden ayudar. Y en este sentido, todavía haré algunas herramientas como mencionará Hanne, porque sería difícil hacerlo sin ellas. Porque en la prueba, siempre probarás las cosas que buscas, que tú como desarrollador escribes dentro de la prueba. Así que en este sentido, echa un vistazo a esas. Pero habrá algunas que son de código abierto, y al menos planes comunitarios donde no necesitas pagar dinero por ellas. Así que la primera, que es mi favorita con una salvedad, es Cypress y Overstep. Así que es un plugin para Cypress combinándolo con Overstep, y es bastante antiguo. Así que con suerte, yo mismo o alguien en el público tendrá algo de tiempo más tarde para básicamente actualizarlo, porque ayuda mucho tener pruebas de seguridad dentro de tus aplicaciones. Pero por ahora, al menos es un gran ejemplo de cómo hacerlo. Incluso puedes encontrar pruebas de ejemplo en este repositorio también. Así que no nos hace daño echar un vistazo, ¿verdad?

Y aparte de eso, Overstep tiene maravillosas recomendaciones para herramientas, por ejemplo, análisis de código, ayudantes IADE, todo tipo de herramientas, que son en su mayoría de código abierto, o al menos tienen un plan comunitario. Así que échales un vistazo, si estás interesado en aprender. Por último, pero no menos importante, introduciré una pequeña lente de aseguramiento de calidad QA a esta cuestión de probar la seguridad con marcos de prueba de método básico, básicamente cómo incorporar la prueba de seguridad dentro de mis planes de prueba, pipelines o flujos de trabajo. Y primero y ante todo, estoy usando pruebas de extremo a extremo como ejemplo aquí, debido al tiempo limitado y es básicamente el tipo de prueba en el que tengo más experiencia. Pero puedes usar pruebas unitarias, pruebas de integración, pruebas de componentes también. Así que no estás limitado a pruebas de extremo a extremo si no quieres, especialmente cuando se trata de casos de prueba de API. Incluso podría ser mejor hacer pruebas de integración o pruebas unitarias porque son básicamente más rápidas y más aisladas. Así que por favor no te sientas limitado a cada prueba, ¿de acuerdo?

Así que cuando se trata de incorporar pruebas de seguridad en mi pipeline, vamos así. Primero, aprenderé mi aplicación, como hablamos antes, y las vulnerabilidades que son relevantes para mi aplicación para saber qué probar. Luego elaboraré un plan de pruebas. Así que, ¿qué capas quiero incluir? Tal vez unitarias, integración, E2E, lo que sea. Tal vez haga un pequeño análisis de riesgos para saber, de acuerdo, qué vulnerabilidades son más importantes cubrir primero o cubrir más a menudo. Qué casos de prueba necesito escribir para el riesgo, y luego escribir mis casos de prueba, por supuesto. Después, los ejecutaré, tal vez localmente, tal vez ya dentro de mi CI y analizaré el resultado para obtener algunos aprendizajes para ver si necesito reforzar otras pruebas o dejar fuera algunas otras, solo analizarlas y aprender de ellas. Y luego pienso en incluir herramientas de prueba si las necesito y combinarlas. Y por último, lo repetiré. Así que repetir ambas reglas, pero también las ejecuciones de prueba. Así que tengo mi pipeline programada para cada noche, cuando, por ejemplo, el tiempo no es tanto un problema. Y luego básicamente, ejecutamos esas pruebas en un cierto ritmo, pero también básicamente repito mi plan también. Así que piensa en nuevos casos de prueba, ejecútalos, aprende de ellos.

Sí, la forma en que solías escribir pruebas, ¿verdad? Así que creo que las pruebas son un complemento maravilloso para mantener tu aplicación segura. Son el mensajero perfecto si estás usando casos de prueba adecuados, tal vez para casos de inyección, para control de acceso roto como una prueba negativa, para seguridad de contenido, encabezados de políticas, cosas así. Para unirse a la implementación de mejores prácticas en la aplicación, construyéndola de manera robusta y segura.

Creo que el atacante no puede eludir nuestras defensas como este musulmán, no podemos eludir esta defensa de nuez, ¿verdad? Un zombi no puede saltar sobre ella. Así que mi deseo para mis aplicaciones y las tuyas también es que se vean así. Muchas defensas diferentes manteniendo a todos los atacantes, todos los problemas, todas las vulnerabilidades a raya. Para que tus clientes o tus usuarios se sientan seguros cuando se trata de tu aplicación y confíen en ti.

Si hay como tres o cuatro partes que quiero que recuerdes de esta charla, es esto. La automatización es un complemento maravilloso para tener un mensajero maravilloso que te informe si tienes problemas de seguridad dentro de tu aplicación. Los pasos simples en las automatizaciones de pruebas son más útiles y son básicamente frutos al alcance cuando se trata de tener una línea de defensa de pruebas, ¿verdad? Así que escribe casos de prueba, utiliza tus características de los marcos de prueba. Creo que estos pasos son simples de implementar. Combina tus propios casos de prueba que escribes básicamente de tu propia mente. Y tal vez algunas herramientas para cosas que no conoces para tener defensas maravillosas. Y considera usar todos los tipos de pruebas dentro de tu plan de pruebas. No solo en tendencia, sino también unitarias o de integración o de componentes por así decirlo. Si logramos hacer esto dentro de una aplicación, estoy feliz, pero ¿quién soy yo? Mi nombre es Ramona Schwering. Trabajo como defensora de desarrolladores en Offseral y puedes encontrar todo sobre mí básicamente en mi blog. Puedes verlo en este código QR. Si tienes alguna pregunta, estaré en línea en el chat o en Discord. Y espero poder verte en otra Good Nation Conference en persona la próxima vez. Así que aparte de eso, nos vemos pronto. Espero que tengas un maravilloso tiempo de Navidad. ¡Adiós!