5 cabeceras de seguridad HTTP que debe conocer para el SEO

5 cabeceras de seguridad HTTP que debe conocer para el SEO

Mientras que algunos pueden decir que la seguridad del sitio web no es una preocupación relacionada con el SEO, se convierte en SEO cuando un sitio es hackeado y el tráfico de búsqueda disminuye a cero.


Las cabeceras de seguridad deberían ser una de las principales preocupaciones de todos los que publican algo en Internet.


La buena noticia es que son relativamente sencillas de configurar y le ayudarán a mantener su sitio web y sus visitantes a salvo.


En este post, aprenderás qué son las cabeceras de seguridad y cómo funcionan, así como las 5 principales cabeceras de seguridad, cómo implementarlas, qué plugins de WordPress puedes utilizar para configurar las cabeceras de seguridad y mucho más.


¡Empecemos!


¿Qué son las cabeceras de seguridad?

Las cabeceras de seguridad son directivas que los navegadores deben seguir y que se transmiten a través de la respuesta de la cabecera HTTP.


Una cabecera HTTP es una respuesta de un servidor web a un navegador que intenta acceder a una página web.


La respuesta de la cabecera comunica cosas como que la página web no existe (cabecera de respuesta 400).


O que está bien descargar una fuente de Google, pero que no hay que confiar en ningún otro dato fuera del dominio de la página web.


En ese ejemplo, la parte que indica al navegador que está bien descargar las fuentes de Google pero que no confíe en ningún otro archivo que no sea el propio sitio web es una directiva de seguridad.


Una directiva de seguridad como esa bloqueará el navegador para que no descargue archivos maliciosos de otro sitio web.


Las cabeceras de seguridad introducen restricciones e instrucciones que evitan eventos de seguridad no deseados.


¿Por qué utilizar cabeceras de seguridad?

El software de bots automatizados está constantemente sondeando y probando sitios web en busca de debilidades de seguridad.


Estas vulnerabilidades pueden ser introducidas por el sistema de gestión de contenidos, por la biblioteca JavaScript utilizada para añadir funcionalidad, y por las debilidades de seguridad introducidas por un plugin o un tema.


Se dice que los sitios web que utilizan cabeceras de seguridad están reforzados contra las amenazas de seguridad.


Aunque un sitio web puede prescindir de las cabeceras de seguridad manteniendo sus componentes actualizados y utilizando plugins de seguridad, hacerlo expone innecesariamente al sitio web y a sus visitantes a riesgos de seguridad.


Por ejemplo, los plugins de seguridad no pueden detener las inyecciones de anuncios que roban al propietario del sitio los ingresos por publicidad.


Quizá la mejor razón para utilizar cabeceras de seguridad es que son relativamente fáciles de implementar y garantizan que un sitio web siga funcionando con normalidad.


Top 5 Security Headers

1. Content-Security-Policy (CSP)

Una política de seguridad de contenidos (CSP) ayuda a proteger un sitio web y a sus visitantes de los ataques de Cross Site Scripting (XSS) y de los ataques de inyección de datos.


Cross-Site Scripting (XSS)

Los ataques XSS (Cross-Site Scripting) se producen cuando los hackers se aprovechan de un agujero de seguridad para cargar scripts maliciosos en un sitio web que luego se descargan en el navegador de la víctima.


Los ataques XSS se aprovechan de los fallos de un sistema de gestión de contenidos que permite inyectar entradas inesperadas debido a una insuficiente higienización de los archivos de entrada del usuario.


Por ejemplo, normalmente, un formulario de correo electrónico debería estar codificado para esperar una entrada restringida.


Un formulario mal codificado puede permitir otro tipo de entrada que puede conducir a una inyección de archivos maliciosos.


Un ataque XSS puede ser utilizado para robar contraseñas o como parte de un evento de hacking de varios pasos.


Injection Attacks

El Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP) describe los ataques de inyección como un grave riesgo para la seguridad:


La inyección es el intento de un atacante de enviar datos a una aplicación de forma que cambie el significado de los comandos que se envían a un intérprete.
Por ejemplo, el ejemplo más común es la inyección SQL, en la que un atacante envía "101 OR 1=1" en lugar de sólo "101". Cuando se incluye en una consulta SQL, estos datos cambian el significado para devolver TODOS los registros en lugar de sólo uno.

...Frecuentemente estos intérpretes se ejecutan con mucho acceso, por lo que un ataque exitoso puede fácilmente resultar en violaciones de datos significativas, o incluso la pérdida de control de un navegador, aplicación o servidor. En conjunto, los ataques de inyección son un gran porcentaje del riesgo grave de seguridad de las aplicaciones".

OWASP

La política de seguridad de contenidos por sí misma no protege al 100% a un sitio de los ataques, pero sí ayuda a disminuir la posibilidad de un ataque de cross site scripting.


Una cabecera CSP ordena al navegador que sólo descargue recursos de un grupo de dominios y sólo de esos dominios.


Cualquier atacante que descargue scripts maliciosos de otro servidor fuera de ese grupo de confianza será bloqueado.


La creación de una política de seguridad de contenidos puede ser tan estricta o tan indulgente como lo requiera un editor.


Advertencia: Sin embargo, configurar uno puede ser un poco complicado porque tienes que listar todos los scripts y recursos que se descargan desde fuera de tu dominio para poder ponerlos en la lista blanca.


2. Encabezado de seguridad de transporte estricto (HSTS)

La cabecera Strict-Transport-Security también se llama cabecera HTTP Strict Transport Security (HSTS).


Muchos sitios web sólo tienen una redirección 301 de HTTP a HTTPS.


Pero eso no es suficiente para mantener el sitio web seguro porque el sitio web sigue siendo vulnerable a un ataque de tipo man-in-the-middle.


HSTS evita que un atacante rebaje la conexión HTTPS a una conexión HTTP, lo que permite al atacante aprovecharse de las redirecciones inseguras.


Por ejemplo, si una persona teclea ejemplo.com para acceder a un sitio, sin teclear realmente la parte https (o simplemente teclea http por costumbre), entonces existe la oportunidad de un ataque man-in-the-middle.


Este tipo de ataque puede comprometer la conexión de los visitantes del sitio web y cualquier información sensible intercambiada entre el visitante y el sitio web se hace visible para el atacante.


Por ejemplo, un atacante puede interceptar las cookies que contienen información sensible como las credenciales de acceso.


El gobierno de los Estados Unidos enumera tres escenarios en los que HTTPS puede ser degradado a HTTP y posteriormente permitir que un atacante comprometa la seguridad.


Estas son las tres formas en que HTTPS puede ser degradado:


  • Cuando un usuario escribe "gsa.gov" en la barra de URL, los navegadores utilizan por defecto http://.
  • Un usuario puede hacer clic en un enlace antiguo que utiliza por error una URL de http://.
  • La red de un usuario puede ser hostil y reescribir activamente los enlaces de https:// a http://.

La cabecera HSTS evita que esto ocurra obligando al navegador a no aceptar en absoluto una conexión HTTP.


La cabecera HTTP Strict Transport Security (HSTS) indica al navegador que sólo se puede acceder a todo el sitio web mediante un protocolo seguro HTTPS.


3. X-Content-Type-Options

Este encabezado de seguridad detiene ciertos tipos de exploits que pueden ocurrir, por ejemplo, a través de contenido malicioso generado por el usuario.


Los navegadores pueden "olfatear" si un contenido es una imagen (.jpg), una película (.mp4) o texto, HTML, JavaScript y otros tipos de contenido que pueden descargarse de un sitio web.


El "sniffing" permite que un navegador descargue los elementos de la página web y los renderice correctamente, en particular en situaciones en las que faltan los metadatos que el navegador necesita para renderizar el elemento.


El "sniffing" permite al navegador averiguar de qué elemento se trata (una imagen, un texto, etc.) y, a continuación, renderizar ese elemento.


Sin embargo, los piratas informáticos intentarán engañar a los navegadores para que piensen que un archivo JavaScript dañino es en realidad una imagen, permitiendo que el navegador descargue el archivo y que posteriormente lo ejecute, causando cualquier número de resultados negativos para el visitante del sitio, especialmente con lo que se conoce como un ataque Drive-by Download.


El encabezado X-Content-Type-Options puede detener ese y otros ataques relacionados al deshabilitar la capacidad de los navegadores de "olfatear" el tipo de contenido.


4. X-Frame-Options

La cabecera de seguridad X-Frame-Options ayuda a detener los ataques de click-jacking.


Mozilla describe el Click-jacking como:


...la práctica de engañar a un usuario para que haga clic en un enlace, botón, etc. que es distinto de lo que el usuario cree que es.Esto puede utilizarse, por ejemplo, para robar las credenciales de acceso o para obtener el permiso involuntario del usuario para instalar un programa malicioso.
Developer Mozilla

El encabezado X-Frame-Options funciona impidiendo que una página web se renderice dentro de un iframe, por ejemplo.


Sin embargo, impide algo más que los ataques basados en iframe.


Microsoft define el frame sniffing de esta manera:


 El Framesniffing es una técnica de ataque que aprovecha la funcionalidad del navegador para robar datos de un sitio web.Las aplicaciones web que permiten que su contenido se aloje en un IFRAME multidominio pueden ser vulnerables a este ataque.
La cabecera X-Frame-Options puede utilizarse para controlar si una página puede colocarse en un IFRAME.
Dado que la técnica de Framesniffing se basa en poder colocar el sitio víctima en un IFRAME, una aplicación web puede protegerse enviando una cabecera X-Frame-Options adecuada.
Microsoft

La cabecera X-Frame-Options es importante para proteger a los visitantes de su sitio, así como la reputación del mismo.


La página web de OWASP sobre el click-jacking describe cómo Adobe Flash fue víctima de un ataque de click-jacking que permitió a los hackers tomar el control de los micrófonos y las cámaras, consolidando así la reputación negativa de Flash como una pesadilla de seguridad.


Ser conocido en las redes sociales y en todo Internet como un peligro para la seguridad es malo para el negocio.


El encabezado X-Frame-Options es una medida de seguridad útil para implementar.


5. Referrer-Policy

El propósito de una cabecera Referrer-Policy es permitir al editor de un sitio web controlar qué información se envía cuando un visitante del sitio hace clic en un enlace para visitar otro sitio web.


Cuando un visitante del sitio hace clic en un enlace y llega a otro sitio, el navegador del visitante proporciona información sobre qué página web envió esa visita.


Cuando usted mira los registros de su servidor, se envía la información de referencia que indica qué sitios enviaron a los visitantes.


Sin embargo, hay algunas situaciones en las que la URL del sitio que remite a un visitante podría contener información sensible que podría filtrarse a un tercero.


La política de referencia funciona limitando la cantidad de información que se envía después de que un visitante del sitio haga clic en un enlace.


El editor de un sitio web puede optar por no enviar ninguna información sobre el referente, puede optar por enviar sólo el nombre de dominio o puede enviar la cadena de URL completa.


Hay ocho directivas que se pueden enviar con la cabecera Referrer-Policy:


  1. no-referrer.
  2. no-referrer-when-downgrade.
  3.  origin.
  4. origin-when-cross-origin.
  5. same-origin.
  6. strict-origin.
  7. strict-origin-when-cross-origin.
  8. unsafe-url.

Una configuración común de la política de referencia es el encabezado "no-referrer-when-downgrade", que significa que la información de referencia se enviará a las URL de confianza que están en HTTPS, pero que no se enviará ninguna información de referencia a los sitios web HTTP que no son de confianza.


Es importante señalar que la configuración de la política de referencia no afectará a los enlaces de afiliados.


La información del referente está codificada dentro de la URL de la página de destino, por lo que la información del referente y las ganancias son registradas por el comerciante que recibe la referencia del afiliado.


Cómo implementar las cabeceras de seguridad

Hay múltiples maneras de establecer cabeceras de seguridad, y una forma popular es con un archivo .htaccess.


Una de las ventajas de utilizar el archivo .htaccess es que evita que el editor tenga que descargar otro plugin.


Los plugins mal codificados pueden convertirse en un riesgo para la seguridad, por lo que minimizar el número de plugins instalados puede ser útil.


Importante: La implementación de cada cabecera de seguridad va a ser diferente de acuerdo a las especificidades de cada sitio web, especialmente la Content-Security-Policy (CSP).


Plugins de WordPress para establecer cabeceras de seguridad

Hay algunos plugins populares que ya están instalados en millones de sitios web que vienen con la opción de establecer encabezados de seguridad.


Si usted ya tiene estos plugins instalados, entonces la opción de usar un plugin en lugar de complicarse con un archivo .htaccess está ahí para aquellos que prefieren la comodidad.


Really Simple SSL Pro

Más de cinco millones de sitios web ya tienen instalado Really Simple SSL.


La actualización a la versión Pro, de precio razonable, ofrece la opción de configurar hasta ocho cabeceras de seguridad de forma sencilla.


Redirection

El plugin WordPress Redirection, 100% gratuito, existe desde hace más de diez años y está instalado en más de dos millones de sitios web.


Este plugin le permite elegir entre muchas cabeceras de seguridad preestablecidas diferentes, además de las cinco principales enumeradas en este artículo.


Preestablecido significa que puede elegir entre las directivas estándar.


Además, el plugin Redirection te permite crear tus propias cabeceras de seguridad si hay algo que no encuentras.


Reactions

2

0

0

0

Access hereTo be able to comment

TheWhiteCode.com is not the creator or owner of the images shown, references are: