Añadir cabeceras HTTP de seguridad en WordPress

En éste artículo vamos a ver cómo podemos enviar cabeceras HTTP de seguridad en nuestra web. Creo que es algo que no se utiliza mucho, a pesar de que tan sólo añadiendo unas líneas a nuestro functions.php o .htaccess podemos incrementar la seguridad de nuestro sitio.

Lo primero de todo, puedes comprobar si tu sitio usa este tipo de cabeceras a través de esta herramienta online: https://securityheaders.io/.

 

X-Frame-Options

El objetivo de establecer esta cabecera es proteger contra los ataques de clickjacking. Sirve para prevenir que la página pueda ser abierta en un iframe.

Fuente: Wikipedia

El clickjacking, o secuestro de clic, es una técnica maliciosa para engañar a usuarios de Internet con el fin de que revelen información confidencial o tomar control de su computadora cuando hacen clic en páginas web aparentemente inocentes. En uno de los muchos navegadores o plataformas con alguna vulnerabilidad, un ataque de clickjacking puede tomar la forma de código embebido o script que se ejecuta sin el conocimiento del usuario; por ejemplo, aparentando ser un botón para realizar otra función.

Los valores que puede tomar esta cabecera son:

  • DENY: prohíbe cualquier intento
  • SAMEORIGIN: permite usar el contenido sólo desde el propio dominio
  • ALLOW FROM: permite usar el contenido en las URLs indicadas

 

X-Content-Type-Options

El objetivo de establecer esta cabecera es evitar que se cargue un archivo JS ó CSS con un MIME-Type diferente al declarado. Es decir, si declaramos esa cabecera y establecemos el valor nosniff no se cargará por ejemplo un archivo CSS a menos que su MIME coincida con “text/css”.

Lo mismo para los archivos JS, se bloqueará la carga de estos archivos a menos que el MIME-Type coincida con:

  • “application/ecmascript”
  • “application/javascript”
  • “application/x-javascript”
  • “text/ecmascript”
  • “text/javascript”
  • “text/jscript”
  • “text/x-javascript”
  • “text/vbs”
  • “text/vbscript”

 

Esto es muy útil ya que permite bloquear archivos enmascarados que puedan ejecutar código malicioso en nuestro sitio.

 

X-XSS-Protection

El objetivo es habilitar o no el filtro anti XSS de los navegadores. Se trata de una capa adicional que bloquea ataques XSS a través del navegador y que ya implementan IE y Chrome

Fuente: Wikipedia

XSS, del inglés Cross-site scripting es un tipo de inseguridad informática o agujero de seguridad típico de las aplicaciones Web, que permite a una tercera persona inyectar en páginas web visitadas por el usuario código JavaScript o en otro lenguaje similar (ej: VBScript), evitando medidas de control como la Política del mismo origen. Este tipo de vulnerabilidad se conoce en español con el nombre de Secuencias de órdenes en sitios cruzados.

Los valores que podemos establecer son:

  • X-XSS-Protection: 1; mode=block Activado
  • X-XSS-Protection: 0; mode=block Desactivado

 

Strict-Transport-Security

HTTP Strict Transport Security (HSTS) es un mecanismo de política de seguridad web según la cual un servidor web declara a los navegadores compatibles que deben interactuar con ellos solamente mediante conexiones HTTP seguras (TLS/SSL).

La vulnerabilidad más importante que la cabecera de seguridad HSTS puede prevenir es la extracción de SSL en ataques man-in-the-middle (ataque en el que se adquiere la capacidad de leer, insertar y modificar a voluntad, los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre ellos ha sido violado).

Un ataque de extracción SSL convierte una conexión segura HTTPS en una conexión normal HTTP

 

Content-Security-Policy

Content Security Policy (CSP) es un estándar de seguridad informático introducido para evitar cross-site scripting (XSS), clickjacking y otros ataques de inyección de código resultantes de la ejecución de contenido malicioso en el contexto de la página web.

Tiene un poco de miga ya que puedes definir el bloqueo a la carga de scripts, CSS e imágenes de dominios externos. Si utilizas un cdn debes tenerlo en cuenta y personalizar esta cabecera en función de tus necesidades. Incluso si cargas fuentes o maps de google, analíticas, banners o publicidad de terceros, etc…

Es decir, hay que crear listas blancas donde definir la fuente o el origen que permitimos para los scripts, estilos, imágenes, fuentes, frames, objetos (<object>, <embed> o <applet>), conexiones AJAX, elementos media (<audio>, <video>), formularios…

En el ejemplo más abajo he puesto la cabecera por defecto para permitir estos elementos sólo de tu propio dominio. Aquí tienes un generador online para crear esta cabecera de seguridad de forma personalizada.

Es soportada por la amplia mayoría de los navegadores web modernos.

 

Public-Key-Pins

HTTP Public Key Pins (HPKP) es un mecanismo de seguridad que permite a los sitios web con certificado HTTPS resistir la suplantación de certificados fraudulentos por parte de un atacante.

Cuando se visita una web bajo SSL se produce una cadena de certificación que comprueba que el certificado de seguridad está asociado a ese dominio, que es válido, que está aprobado, etc. Un atacante podría alterar esa cadena con certificados fraudulentos.

La cabecera de seguridad HPKP requiere una configuración avanzada. Os dejo más info aquí (en inglés).

 

¿Cómo añadir las cabeceras de seguridad HTTP a nuestro WordPress?

Podemos añadir estas cabeceras de seguridad en nuestro sitio de 2 formas diferentes, a través de nuestro archivo functions.php, o mediante el fichero .htaccess.

 

Añadir cabeceras de seguridad a través de functions.php

Simplemente añadimos estas líneas en nuestro functions.php:

 

Añadir cabeceras de seguridad a través de .htaccess

Simplemente añadimos estas líneas en nuestro .htaccess:

Si te ha gustado, valora este artículo para mejorar la calidad del blog o compártelo en Redes Sociales…
1 Star2 Stars3 Stars4 Stars5 Stars (1 votos, valoración 5,00 sobre 5) Loading...

Web Hosting
  • Pingback: Añadir cabeceras HTTP de seguridad en WordPress - Via Activa SL()

  • Pingback: Herramientas De Auditoría WordPress | Via Activa SL()

  • arocha01

    Buenas Tardes Pablo, estoy realizando una tesis de seguridad de aplicaciones web y realizando pruebas de pentesting con herramientas automatizadas detecta en CMS como WordPress, Joomla e Drupal la ausencia de estos headers, leyendo articulos como este queda claro que son necesarios pero siempre me queda la duda del porque no son colocados de manera predeterminada por los desarrolladores en el core del propio Worpress por ejemplo, tienes alguna idea? Saludos!!

    • Hola Arocha

      Para cualquier CMS de los que comentas la seguridad es un factor importantísimo. La prueba la tienes en las continuas actualizaciones que corrigen vulnerabilidades que se van detectando.

      Por ejemplo WordPress lleva unas 170 versiones y en todas y cada una de ellas se corrige alguna vulnerabilidad. Desde su nacimiento se endurece continuamente su CORE contra amenazas de seguridad, incluyendo el Top 10 de amenazas identificado por el Open Web Application Security Project (https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline)

      Respecto a las cabeceras de seguridad no es algo propio del CMS, dependerá de si lo soporta tu servidor y tu navegador (https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Main).

      No obstante si tienes cualquier duda al respecto te aconsejaría que te dieras de alta en el slack oficial de WP, donde podrás encontrar desarrolladores de WordPress y preguntar tus dudas (https://wp.slack.com/)

      • arocha01

        Muchas gracias por tu rapida respuesta Pablo!