Skip to main content

Mitigar el clickjacking: ¡la forma DevSecOps!

Escrito por

25 de mayo de 2020

0 minutos de lectura

En las últimas semanas, recibimos algunos reportes (a través de nuestro programa de recompensas por errores) de que algunos de nuestros dominios internos eran vulnerables a ataques de clickjacking. Por supuesto, nuestro sitio principal estuvo protegido desde el primer día, pero algunos subdominios pequeños no contaban con esta protección. Resolver el problema fue fácil, pero quisimos ir un paso más allá y asegurarnos de que todos nuestros endpoints estuvieran protegidos para dejar de preocuparnos por este problema. Veamos cómo lo hicimos.

¿Qué es el clickjacking?

Según la definición de OWASP:

"El clickjacking, también conocido como «ataque de manipulación de la interfaz de usuario», ocurre cuando un atacante usa varias capas transparentes u opacas para engañar a una persona y hacer que haga clic en un botón o enlace de otra página, cuando en realidad intentaba hacer clic en la página que está en primer plano. De esta manera, el atacante «secuestra» los clics que iban dirigidos a su página y los redirige a otra, probablemente propiedad de otra aplicación, dominio o ambos."

Se trata de un ataque bastante serio. El vector de ataque habitual consiste en crear otro sitio web e insertar el sitio objetivo en un iframe. Así, el atacante puede lanzar fácilmente un ataque de clickjacking y engañar a usuarios desprevenidos para que hagan clic en el sitio web malicioso.

Cómo mitigar el clickjacking

Como vimos, el principal vector de ataque es el uso de iframes. Por lo tanto, basta con indicarle al navegador que nuestro sitio no se puede cargar dentro de un iframe para mitigar por completo este ataque. Por suerte, existe un encabezado que hace exactamente eso: x-frame-options. Solo tenemos que configurarlo y listo.

Pero hay un pequeño problema: ¿cómo podemos saber cuáles de nuestros endpoints tienen este encabezado y cuáles no? En Snyk tenemos muchos endpoints y es muy difícil llevar un control de todos. Necesitamos una herramienta que nos ayude.

Te presentamos OWASP AMASS

OWASP AMASS es una herramienta de OWASP que ofrece «mapeo exhaustivo de la superficie de ataque y descubrimiento de activos», justo lo que necesitamos. Una de sus funciones es la enumeración de DNS, que permite encontrar todos los registros DNS de un dominio determinado. Es muy fácil de usar:

amass enum -d <domain> -o out.txt

Esto buscará todos los registros pertinentes y los guardará en out.txt. Ahora solo tenemos que recorrer la lista y revisar si cada registro DNS tiene el encabezado x-frame-options. Para ello, usaremos una herramienta llamada, como era de esperarse, Security Headers Checkers.

Escaneo de encabezados de seguridad

Security Headers Checker es una utilidad de Python que puede analizar una URL para detectar varios problemas de seguridad, incluidos los encabezados de seguridad faltantes, como x-frame-options. Tiene muchas funciones interesantes y, lo que es más importante, su archivo README documenta bien todos los problemas que puede detectar y por qué deberías prestarles atención. Para este caso, la función más relevante es que acepta un archivo con una lista de URL, como el que genera AMASS. Así que solo tenemos que:

python ./securityheaders/securityheaders.py out.txt --checkers HeaderMissingChecker --format json  --flatten --file ./result

Le pasamos la salida de amass y limitamos la revisión a HeaderMissingChecker, porque eso es lo que nos interesa. El siguiente argumento es el formato: elegí JSON, pero hay muchos otros formatos disponibles.

Ahora tenemos un archivo con todas las URL vulnerables y solo necesitamos un truco rápido de JQ para filtrar las URL sin el encabezado x-frame-options, ya que Security Headers reporta muchos otros encabezados interesantes. Es muy sencillo:

jq 'map(select(.header == "x-frame-options"))’ ./result/1.csv 

Sí, la extensión del archivo de salida es csv: es un error :)

Ya tenemos la lista y solo queda el verdadero trabajo: revisarla y empezar a corregir todos esos endpoints vulnerables. El siguiente paso es ejecutar esto a diario para asegurarnos de que no aparezcan nuevos endpoints sin el encabezado x-frame-option. Otro desafío es comprobar que todas las URL que encontramos sean sitios web; las API no necesitan protección contra clickjacking.

Conclusión

Este incidente demuestra la importancia de contar con un programa de recompensas por errores, es decir, una forma de permitir que los investigadores reporten problemas de seguridad en tu sistema. Pero es aún más importante saber cómo gestionar esos reportes: corregir el problema no es suficiente. Si no agregas una prueba que reproduzca el problema, no puedes asegurarte de que no vuelva a ocurrir. Todos somos humanos y cometemos errores. ¡Asegurémonos de usar código que nos ayude a no cometer el mismo error otra vez!

Comienza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag con nuestro taller virtual 101 a pedido.

Leer más

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

Blog

Tu backlog de vulnerabilidades ya no es deuda técnica: es una superficie de ataque

Un backlog de vulnerabilidades en crecimiento es más que deuda técnica: es una superficie de ataque. Descubre por qué las suposiciones obsoletas sobre el riesgo, los atacantes automatizados y los hallazgos encadenados requieren un nuevo enfoque.