X-Frame-Options : Minimizando las amenazas de ataques clickjacking

Un ataque de clickjacking hace creer al usuario que está realizando acciones sobre una aplicación web cuando en realidad está actuando sobre un marco superpuesto creado por un atacante. Por ejemplo, creemos que estamos tecleando nuestras credenciales en Facebook cuando realmente estamos escribiendo en un formulario construido ex profeso para interceptarlas (Figura 1).

P27

Figura 1. Ejemplo de ataque de clickjacking. Tomado de http://www.hacker9.com.

La principal causa por la cual es factible hacer este ataque es por la presencia de la etiqueta <iframe> de HTML, la cual permite embeber una página web dentro de otra página web. Por supuesto, no podemos decir que siempre sea mala su utilización, de otro modo los banners de publicidad se las verían muy difícil para subsistir. Sin embargo, si nuestra aplicación web va a involucrar procesos de autenticación, entradas de datos e interacción activa con los usuarios, la aplicación web puede ser víctima de un clickjacking si permite que se le invoque desde un <iframe>.

Si usted quiere conocer si su aplicación web puede ser embebida dentro de una etiqueta <iframe>, puede visitar el sitio www.w3schools.com, siempre y cuando la aplicación esté de cara a Internet y ejecutar el procedimiento que se muestra en la figura 2:

P27.1.png

Figura 2. Comprobando si una aplicación web de cara a Internet puede ser embebida dentro de una página web. Elaboración propia.

En el caso de que su aplicación web esté todavía en desarrollo o sea de uso interno en su organización, puede comprobarla creando una página web simple en su escritorio con gedit, notepad, nano, o cualquier otro editor de texto y conteniendo el siguiente código base:

P27.3.png

Para evitar, por tanto, que las páginas de nuestra aplicación web puedan ser embebidas y sufrir un ataque de clickjacking, debemos aplicar algunas medidas, dentro de las cuales está especificar el campo X-Frame-Options en los encabezados de respuesta HTTP: X-Frame-Options: (DENY, SAMEORIGIN, ALLOW-FROM uri)

  • DENY: Se instruye al navegador que la página web no puede ser mostrada en un <iframe> (X-Frame-Options:DENY).
  • SAMEORIGIN: Se instruye al navegador que la página web puede ser mostrada desde un <iframe> igual a su propio dominio (X-Frame-Options: SAMEORIGIN).
  • ALLOW-FROM uri: Solo se podrán mostrar dentro de un <iframe> desde las URL especificadas (X-Frame-Options: ALLOW-FROM https://example.com/).

En la siguiente figura vemos como se refleja el campo X-Frame-Options en una respuesta HTTP:

P27.2.png

Figura 3. Ejemplo de una respuesta HTTP donde se incluye el campo X-Frame-Options con valor SAMEORIGIN. Elaboración propia.

Para incorporar el campo de encabezado X-Frame-Options en las respuestas HTTP podemos aplicar los siguientes métodos:

  • Si usamos Apache como servidor de aplicaciones podemos incluir en el .htaccess la siguiente directiva:
    • Header always append X-Frame-Options SAMEORIGIN
  • En el caso de nginx puede introducirse la directiva en el fichero de configuración:
    • add_header X-Frame-Options SAMEORIGIN;   
  • En el caso de PHP podemos usar la función header de la siguiente manera:
    • header( ‘X-Frame-Options: SAMEORIGIN’ );

Por supuesto, los demás servidores de aplicaciones y lenguajes de programación tienen métodos para incluir campo de encabezado X-Frame-Options en las respuestas HTTP, es solo cuestión de buscar en Internet cual método es más conveniente según la aplicación que estemos desarrollando.

Para despedirme, les dejo unos vínculos donde pueden profundizar mejor como combatir los ataques de clickjacking:

Espero que te haya gustado el post y hayas aprendido algo nuevo. Hasta el próximo encuentro 🙂

 

Anuncios

10 comentarios en “X-Frame-Options : Minimizando las amenazas de ataques clickjacking

  1. Estimado Joel, gracias por tu comentario. Es importante saber que puedes añadir campos de encabezado HTTP tanto desde el servidor como desde tu aplicación web. Existen plugin para CMS como Drupal o WordPress que los adicionan de forma transparentes o puedes, por ejemplo,si desarrollas una aplicación web personalizada en PHP, aplicar la función header para añadir los encabezados correspondientes (http://php.net/manual/es/function.header.php). Otros lenguajes de programación también incorporan esta facilidad.

    No tengo experiencia en el trabajo con IBM HTTP Server pero puedo recomendarte revisar la página de IBM (https://www.ibm.com/support/knowledgecenter/SS3NGB_1.6.0/ioc/install_config_X-Frame-Options_HTTP.html) donde explican que puedes añadir(des-comentar) la siguiente regla: “Header always append X-Frame-Options SAMEORIGIN” en el archivo httpd.conf.

    En esta página también puedes encontrar la misma solución: https://geekflare.com/secure-apache-from-clickjacking-with-x-frame-options/

    Espero que te haya sido útil la entrada y la explicación, gracias nuevamente por tu aporte.

    Le gusta a 1 persona

  2. Pingback: Apuntes sobre el Referer spoofing, el Referer spam y otros problemas de seguridad relacionados | Behique Digital

  3. Pingback: Guía de Pruebas de OWASP 4.0 | Behique Digital

  4. Muy interesante el comentario, personalmente, pienso que usar marcos en las páginas es al que hace al sitio bastante vulnerable, pues se permite la entrada de código html no propio a la página. Es posible que algunos de los ataques que se reporten, de robo de identidad y de credenciales en los lugares públicos de conexión a internet sean por esta causa o también personas que simulen un sitio igual que el de la autenticación web brindando un servicio de conexión que solo tiene el propósito de capturar credenciales

    Le gusta a 1 persona

  5. Hola Yuniel, básicamente lo más importante es incorporar el campo de encabezado X-Frame-Options, ya sea a través de la configuración del servidor web o de código PHP.

    Me gusta

  6. ¿Cómo el atacante introduce la etiqueta iframe en la página web. En caso de que otro usuario intente acceder a esa página web, el código de la etiqueta iframe se queda guardado en la pagina ?, cómo se refleja en los demás clientes, se queda guardado por mucho tiempo, o se mantiene ahí ?, gracias

    Le gusta a 1 persona

  7. Muchas gracias Kelly por tu aporte. Realmente ellos no introducen la etiqueta en una página legítima, es al revés. Utilizan una página con un iframe trasnparente y cuando el usuario piensa que está interactuando con la página original realmente está escribiendo los datos en un iframe de la página maliciosa. En la figura 1 se presenta un ejemplo de ello.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s