Esta semana trataremos la seguridad web, ya que son varios los protocolos y cabeceras necesarias para securizar la comunicación entre tu web y la de tus usuarios. Aunque al aplicar medidas de seguridad no sólo te beneficiarás de esta, sino que también mejorarás el posicionamiento SEO de tu web, tal como comentamos en ¿Está tu web técnicamente a la altura?
Conozcamos cada uno de estos protocolos y/o cabeceras de seguridad web:
HTTPS
Seguro que has oído hablar de HTTPS….
“Estás loco comprando en esa web sin HTTPS. ¡Estamos en 2019! “
“Chrome ahora marcará las webs como inseguras si no tienen HTTPS”
HTTPS es la versión segura del Protocolo (HTTP). Es el método para garantizar una comunicación segura entre tus usuarios y tu web. Reconocido informalmente como el famoso candado verde del navegador, que indica que la conexión se realiza mediante HTTPS de forma segura.
Tradicionalmente, HTTPS se usaba únicamente en e-commerce para los pagos mediante tarjeta de crédito, con el fin de asegurar que los detalles del pago, de carácter más sensible, se enviaban de forma segura, evitando que fueran robados.
Sin embargo, mejorar la seguridad online se ha convertido en algo cada vez más importante en los últimos años y Google se ha puesto a la cabeza de ello. Tanto que en 2017 anunció que HTTPS es uno de los valores que influye en su algoritmo de posicionamiento SEO y que desde julio de 2018 Google Chrome marca todas las páginas HTTP como "No seguro".
Si todavía no tienes HTTPS, aquí te facilito un manual para configurar HTTPS en Nginx y aquí otro para HTTPS en Apache2. Pero antes deberás disponer de un certificado. Te recomendamos encarecidamente que dispongas de un certificado SSL-Wildcard para poder cubrir todos tus subdominios, es posible que necesites a algún técnico que te ayude.
Además de HTTPS, para garantizar que la conexión siempre se realice mediante HTTPS, por regla general se realiza una redirección o rewrite de las peticiones HTTP a las HTTPS, pero las buenas prácticas nos indican que no es suficiente, deberíamos integrar HSTS. Veamos qué es y cómo integrarlo.
HTTP Strict-Transport-Security (HSTS)
HTTP Strict Transport Security permite que tu web indique al navegador que nunca debe cargar el sitio utilizando HTTP y que debe convertir automáticamente todos los intentos de acceso HTTP a solicitudes HTTPS. Principalmente consiste en un encabezado HTTP, Strict-Transport-Security, que devuelve el servidor web con la cabecera ‘Strict-Transport-Security’.
En otras palabras, HSTS le indica al navegador que cambie el protocolo de HTTP a HTTPS y que lo haga para cada solicitud, sin redirecciones. El navegador dejará de solicitar la web mediante HTTP.
Veamos el encabezado de itdo.com como ejemplo:
strict-transport-security: max-age=31536000; includeSubdomains; preload
- max-age: especifica cuánto tiempo debe recordar un navegador para obligar al usuario a acceder a un sitio web utilizando HTTPS.
- includeSubdomains: indica que aplicará HSTS a todos los subdominios de itdo.com como www.itdo.com.
- preload: es un mecanismo mediante el cual el navegador verifica si el dominio está verificado en una lista oficial utilizada por Chrome, Firefox y Safari. Las webs con preload no dependen de la emisión del encabezado de respuesta HSTS para aplicar la política, en lugar de eso, el navegador ya sabe que el dominio requiere el uso de HTTPS antes de que se produzca cualquier comunicación. Esto no quiere decir que el servidor web deba dejar de emitir el encabezado de respuesta de HSTS. Debes dejarlo para los navegadores que no utilizan esta lista oficial de HSTS ‘preload’. Para formar parte de esta lista has de emitir tu solicitud mediante la web HSTS Preload.
Aquí te dejo un manual para configurar HSTS en Nginx y aquí otro para HSTS en Apache2.
Además de la combinación de HTTPS con HTST, también te ayudará a mejorar la seguridad una correcta configuración de cabeceras como CSP y X-Frame-Options.
Mejora la seguridad con CSP y X-Frame-Options
Content Security Policy (CSP)
CSP (Política de seguridad de contenido) te permitirá detectar y mitigar ciertos tipos de ataques como cross-site scripting (XSS) y otros ataques de inyección de código.
Con CSP puedes definir una lista blanca de tipos de contenido validados por tu web. Al restringir los ficheros que el navegador web puede descargar para tu web, como JS, HTML y CSS, CSP puede actuar como una contramedida efectiva para los ataques XSS.
CSP divide los tipos de recursos que puede cargar una web con una serie de directivas: default-src (por defecto), img-src (imágenes), font-src (fuentes), style-src (estilos), script-src (scripts), etc… en cada directiva especificamos el posible origen del recurso.
Un ejemplo en Apache para un blog WordPress:
Header set Content-Security-Policy \
"default-src 'self' *.github.com *.wordpress.org secure.gravatar.com w.org s.w.org;\
font-src 'self' 'unsafe-inline' data: *.googleapis.com fonts.gstatic.com;\
style-src 'self' 'unsafe-inline' data: *.googleapis.com assets-cdn.github.com;\
media-src 'self' *.youtube-nocookie.com;\
frame-src 'self' *.youtube-nocookie.com;"Un ejemplo en Nginx:
add_header Content-Security-Policy \
"script-src 'self' 'unsafe-inline' 'unsafe-eval' *.youtube.com *.googleapis.com *.google-analytics.com;\
frame-src 'self' *.youtube.com;\
font-src 'self' https://themes.googleusercontent.com;\
object-src 'self'";Si especificamos recursos con una directiva dedicada, ésta tiene prevalencia sobre default-src. Por ejemplo, si ponemos una directiva font-src, el origen de dichos recursos será el especificado (en este caso 'self' 'unsafe-inline' data: *.googleapis.com fonts.gstatic.com) y no default-src. Todas las directivas disponibles podéis encontrarlas en la web de Mozilla.
¿Hasta qué punto tenemos que ser restrictivos con las directivas CSP?
Tú pones el limite. A la hora de aplicar las directivas casi seguro que tendrás que debugar con el navegador (F12 en Firefox/Chrome/Chromium) para ir ajustando las cabeceras según tus necesidades:
Puedes empezar aplicando una política restrictiva para no permitir nada por defecto e ir permitiendo exclusiones. Aquí te dejo la política restrictiva:
Header set Content-Security-Policy \
"default-src 'none';\
script-src 'self';\
connect-src 'self';\
font-src 'self' fonts.googleapis.com;\
img-src 'self';\
style-src 'self';\
frame-src 'self';" X-Frame-Options
Con el encabezado X-Frame-Options podrás proteger a los usuarios contra ataques de clickjacking. Evitarás que un atacante pueda cargar un iFrame de tu web desde otro dominio, quedando expuesta tu web desde otra web que no controlas.
Es bastante fácil: <iframe src="https://www.example.com"></iframe>.
Para evitar esto, deberemos añadir la cabecera X-Frame-Options. Las opciones son:
- DENY: Esta configuración es la más restrictiva e impide que la web se pueda incluir en un iFrame. Esta opción es óptima si no tienes la necesidad de usar iFrame.
- SAMEORIGIN: Este caso lo utilizaremos para permitir los iFrame del mismo dominio que el original, el resto quedaran denegados.
- ALLOW-FROM: Aquí podrás especificar la dirección para que estas únicamente estén permitidas para cargar la web mediante iFrame.
La cabecera para Nginx:
add_header X-Frame-Options "SAMEORIGIN" always;La cabecera para Apache2:
Header always set X-Frame-Options "SAMEORIGIN"Conclusiones
HTTPS junto con HSTS es imprescindible para cualquier negocio que quiera ofrecer una experiencia segura a sus visitantes y desee alcanzar un ranking alto en Google.
Además, si combinas con otros parámetros de seguridad como CSP o X-Frame-Options reforzarás la confianza de tus usuarios con una web segura.
Son medidas que no debes pasar por alto, ya que sobretodo incrementarás el tráfico web cumpliendo con los requisitos de ranking para Google, así que si usas medidas de seguridad con HTTPS y HSTS mejorarás tu posicionamiento SEO.
Desde ITDO te recomendamos cumplir con todos los requisitos de seguridad posibles. Que tus conexiones sean todas encriptadas y ha ser posible con la máxima calificación SSL:
¿Está tu web segura? ¿Tu posicionamiento SEO es el indicado para tu negocio? Escríbenos si necesitas soporte y te ayudamos a mejorar tu trafico web.
Fotografía by Pixabay
Referencias:
