Soy consciente de los enfoques modernos contra el clickjacking, como el encabezado X-Frame-Options o los scripts de framekiller. Pero todas estas tácticas impiden que el contenido esté dentro del iframe. ¿Pero qué sucede si hay un requisito para que el contenido esté en iframe, como el botón "Seguir" de Twitter o el botón "Me gusta" de Facebook? ¿Cómo proteger dichos iframes del clickjacking?
Los botones para compartir a menudo usarán un iframe para protegerse de CSRF . En este contexto, CSRF y ClickJacking tienen un impacto idéntico, que a veces se llama " LikeJacking ". Tienes que elegir ser vulnerable a CSRF O puedes usar un iframe para evitar CSRF pero luego te expones a ti mismo a ClickJacking. Sucede que ClickJacking es el menor de dos males. FaceBook resuelve este problema de lógica con acción legal . Puedes hacer "LikeJacking" y ClickJacking contra tus Términos de servicio y demandarlos como FaceBook.
Puede que haya una solución técnica para este problema. Le envié un correo electrónico a Seguridad de Google sobre este tema y me dijeron que estaban usando " Signal Analysis" para determinar si se estaba produciendo un comportamiento. Que es una respuesta bastante gaseosa para decir lo menos. Al ser Google, hacen spider todas las páginas que les gustan, y podrían determinar si un método de secuestro de clics , como una máscara SVG fue aplicada a su iframe por la página principal. Pero esto es sólo especulación.
Es posible que desee consultar con una de las DNSBL. Algunos de ellos tienen direcciones URL que se encuentran en los mensajes de correo electrónico no deseado. No puedo recomendar cuál de los dos tiene la mejor base de datos, pero puedes buscar en línea para verificar DNSBL en línea y ver los sitios web ofensivos si están allí. Dicha verificación se puede realizar en tiempo real durante la ejecución de la página.
URS DNSBLs Un URI DNSBL es un DNSBL que enumera los nombres de dominio y las direcciones IP que se encuentran en los enlaces de "clics" contenidos en el cuerpo de spam, pero que generalmente no se encuentran dentro de los mensajes legítimos. Los DNSBL URI se crearon cuando se determinó que gran parte del correo no deseado pasaba a través de los filtros de correo no deseado durante ese breve período de tiempo entre el primer uso de una dirección IP de envío de correo no deseado y el punto en el que esa dirección IP de envío se enumeraba por primera vez en la mayoría de los envíos basados en IP. DNSBLs. En muchos casos, dichos correos no deseados contienen en sus enlaces nombres de dominio o direcciones IP (denominados colectivamente como URI) donde ese URI ya se detectó en el spam capturado anteriormente y donde ese URI no se encuentra en el correo electrónico que no es spam. Por lo tanto, cuando un filtro de spam extrae todos los URI de un mensaje y los compara con un URI DNSBL, entonces el spam se puede bloquear incluso si la IP de envío de ese spam aún no se ha incluido en ninguna IP DNSBL de envío.
Lea otras preguntas en las etiquetas web-application web-browser appsec client-side clickjacking