Clickjacking


-- Descargar Clickjacking como PDF --


Es probable que aún no hayan oido/leido de clickjacking. Por lo que voy a comenzar con una introducción:

Qué es clickjacking?

Muy probablemente, todos nos hemos encontrado con esto alguna vez en internet, sobre todo si queremos descargar algo de una página. Por ejemplo, el típico caso, buscamos descargar un programa y caemos en un sitio que no es el oficial. Vemos un botón «Download»(Descargar) grande, hermoso y pensamos que ahí se descarga… La inocencia te valga! En lugar de eso, se nos abre un número n de ventanas con publicidad. Probablemente hasta avisos porno. Pero claro! El botón legítimo de descarga, era uno chiquito más abajo de la pantalla. Toda una estafa no?

Hay sitios web que utilizan clicjacking intencionalmente para forzar al visitante a ver publicidad que les da ganancias, ya sea las necesarias para mantener el sitio web o bien para ganancia adicional. Este no es el peor caso, aunque crean que sí.

Puede pasar, que tengamos un sitio web para nuestro negocio. Un atacante hace un sitio web en blanco, probablemente con un dominio muy parecido al nuestro y solo le pone un botón, ya sea de descarga de algo, o de compra, o lo que sea. Ese botón lo sitúa, siguiendo nuestro ejemplo, en la cabecera del sitio, o sea en la parte de arriba.

Debajo de la cabecera utiliza una función para «llamar» a nuestro sitio, de manera que el resultado será una réplica de nuestro sitio, pero con el botón que el atacante puso arriba. A este botón, finalmente, puede hacerlo hacer lo que él quiera, literalmente. Desde descargar un programa  que es similar a lo que el visitante de nuestro sitio venía a buscar, pero probablemente infectado, hasta ejecutar peticiones  ocultas a otros sitios, utilizando al visitante(sin él saberlo) como máquina zombie en un ataque a mayor escala a otra víctima. Las posibilidades son muchas y variadas.

Obviamente que el atacante está utilizando nuestro sitio para engañar a la gente. Uno pensaría que esto no debiera ser posible, pero lo es. Hay buenas razones para usar este método para fines constructivos, como por ejemplo reutilizar una página en varios sitios. Y hay gente que sabe usarlo para sus propios fines no tan inocentes.

Vamos un poco más profundo:

Para quien tiene un servidor, deben saber que se pueden tomar medidas para proteger nuestros sitios de éste tipo de ataques, que se basan en el uso del header x-frame. Por lo tanto, la defensa se basa en restringir el uso de dicho header:

Dicho header tiene 3 opciones:

  • DENY: Es la mejor opción, siempre que sea posible. Si bien lo más común es que no haga falta permitirlo, hay situaciones en las que puede ser necesario permitir el header, para uso propio. Un caso común es el de incrustar partes de un sitio nuestro,  en otro sitio nuestro, o en el de un partner, por ejemplo.
  • SAMEORIGIN: Esta opción permite solo al propio sitio a hacer uso del header. En pocas palabras, solo se permite incrustar contenido de nuestro sitio, en páginas del mismo sitio.
  • ALLOW-FROM uri, Esta opción permite definir los sitios(las URLs mejor dicho, que pueden hacer uso de contenido de nuestro sitio. Actualmente, no todos los navegadores suportan esta opción y es importante saber que, en un navegador que no lo soporte, el comportamiento por defecto será simplemente un allow(O sea que será lo mismo a que no haya ningún parámetro).

Es importante también, saber que las opciones arriba expuestas fueron creadas en 2009, por lo que navegadores en versiones anteriores muy probablemente sean vulnerables a clickjacking.

Cómo implementar las opciones de x-frame:

IIS 7+:

Si bien esta no es la única defensa posible, voy a recomendarla y comentarla mejor, porque a mi juicio es la manera más sencilla(Y la que yo he utilizado por el momento.  las x-frame options se pueden definir a nivel de HTTP response header. En IIS 7 y superiores es muy sencillo de aplicar:

  • Abrir el IIS y elegir el servidor. Esto también se puede hacer a nivel de sitio, en lugar de a nivel global como estoy mostrando. El procedimiento es el mismo, solo que tenemos que elegir el sitio en particular.

    Clickjacking Defense IIS 7
    Pantalla principal de IIS 7
  • En el panel central, dentro de la sección IIS, podemos encontrar la opción HTTP response headers.

    Clickjacking Defense IIS 7
    La opción HTTP Resonse Header
  • Hacemos click en Add

    Clickjacking Defense IIS 7
    Hacemos click en Add
  • En Name, ponemos el nombre del header, en el caso de este artículo, es X-Frame.
  • Finalmente, en Value ponemos el valor que queramos aplicar.

    Clickjacking Defense IIS 7
    La opción Allow-From require que agreguemos URL

IIS 6:

En IIS también es sencillo, aunque no se puede hacer a nivel servidor, sino sitio por sitio. Los pasos son prácticamente los mismos pero cambia el lugar de las opciones:

Clickjacking Defense IIS 6
Elegimos el sitio y accedemos a sus propiedades.
Clickjacking Defense IIS 6
Elegimos el tab HTTP Headers
Clickjacking Defense IIS 6
Agregamos Name y Value, tal como en IIS 7

Apache:

Veamos ahora cómo proteger de clickjacking a nuestros sitios hosteados con apache.

En el caso de Apache, es bastante simple también. Solo basta acceder por SSH y editar el httpd.conf, agregar la línea:

Header always append X-Frame-Options SAMEORIGIN

y finalmente reiniciar apache.

En caso que no tengamos acceso SSH al servidor(Por ejemplo, en un servidor web compartido), pueden implementar el código en su archivo .htaccess. Edítenlo desde el administrador de archivos o via FTP y agreguen la siguiente línea:

Header append X-FRAME-OPTIONS "SAMEORIGIN"

Si quieren testear los cambios efectuados, pueden hacerlo de muchas maneras. Dos de las más sencillas:

  • Crear un nuevo archivo html que contenga código embebiendo el sitio supuestamente protegido. Pueden usar el siguiente código:
<html> 
  <head> 
    <title>Clickjack test page</title> 
  </head> 
  <body> 
    <p>Website is vulnerable to clickjacking!</p> 
    <iframe src="http://www.sitioprotegido.net" width="500" height="500"></iframe> 
  </body> 
</html>
Referencias:

Página en la wiki oficial de OWASP(en inglés)

Artículo de geekflare sobre cómo proteger servidores apache (en inglés)

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *