Lectores como tú ayudan a apoyar a MUO. Cuando realiza una compra utilizando enlaces en nuestro sitio, podemos ganar una comisión de afiliado.
Cuando desea visitar un sitio web, el navegador de Internet que utiliza recibe algunos datos de ese sitio. Como resultado, se produce un diálogo entre su dispositivo y el sitio web. Esto sucede con el protocolo llamado HTTP. Es posible tomar algunas medidas de seguridad adicionales al intervenir en este diálogo.
Si está ejecutando un sitio web o aspira a una carrera como desarrollador web, los encabezados de seguridad HTTP son invaluables para usted, ya que juegan un papel activo en la seguridad tanto del usuario como del sitio web.
¿Qué es HTTP Strict-Transport-Security (HSTS)?
HTTP Strict Transport Security (HSTS) obliga a los usuarios a utilizar HTTPS para cada solicitud que realicen en su navegador. Esta es una forma sólida de combatir los ataques cibernéticos como las degradaciones y garantizar la seguridad de todo el tráfico.
Activar HSTS es bastante fácil. Considere el diálogo entre el cliente y el servidor. Cuando intenta acceder a un sitio a través de su navegador, usted es el cliente. El sitio que desea abrir depende del servidor. Su objetivo es decirle al servidor: "Quiero abrir este sitio". Esta es una operación de solicitud. El servidor, por otro lado, lo dirige al sitio si cumple con las condiciones deseadas.
Tenga esto en cuenta con respecto a este indicador de encabezado HTTP de muestra:
Estricta-Transporte-Seguridad: max-age=16070200;
Cuando agrega este indicador a la información del encabezado de la respuesta HTTP, todas las solicitudes generadas por el usuario se convertirán en HTTPS. Independientemente de lo que el usuario escriba aquí, el navegador evaluará automáticamente el protocolo como HTTPS y establecerá una conexión segura.
Cómo usar HSTS
En lugar de agregar toda esta información de encabezado HTTP en la capa de código, puede hacerlo en Apache, IIS, Nginx, Tomcat y otras aplicaciones de servidor web.
Para habilitar HSTS en Apache:
LoadModule headers_module módulos/mod_headers.so
<VirtualHost*:443>
Encabezado siempre colocarEstricto-Transporte-Seguridad "max-edad=2592000; incluir subdominios"
</VirtualHost>
Para habilitar HSTS en Nginx:
add_header Strict-Transport-Security max-age=2592000; incluir subdominios
Para habilitar HSTS con IIS web.config:
<sistema.webServer>
<httpProtocolo>
<encabezados personalizados>
<agregar nombre ="Estricta-Transporte-Seguridad" valor="max-edad=63072000"/>
</customHeaders>
</httpProtocol>
</system.webServer>
Para usuarios de Cloudflare
Cloudflare ofrece un servicio HTTPS gratuito para todos con su servicio Keyless SSL; antes de solicitar la precarga de HSTS, debe saber que su certificado no le pertenece. Muchos sitios usan certificados SSL porque son una forma sencilla de mantener los datos seguros.
Sin embargo, Cloudflare ahora admite la función HSTS. Puede activar todas las funciones de HSTS, incluida la precarga, a través de la interfaz web de Cloudflare sin tener que lidiar con las configuraciones en el servidor web.
¿Qué es X-Frame-Options?
X-Frame-Options es un encabezado de seguridad compatible con todos los navegadores modernos. X-Frame-Options tiene como objetivo proteger contra el robo de clics como el Clickjacking. Como sugiere el nombre, se trata del funcionamiento de un marco en línea vulnerable, también conocido como iframe. Estos son elementos en un sitio que incrustan otra página HTML dentro del sitio "principal", para que pueda usar contenido de otras fuentes en su sitio. Pero los atacantes usan iframes bajo su propio control para hacer que los usuarios realicen acciones que no quieren.
Por esta razón, debe evitar que los atacantes puedan encontrar iframes en el sitio.
¿Dónde y cómo usar X-Frame-Options?
Lo que hace X-Frame-Options, algunos desarrolladores lo intentan hacer con lenguajes como JavaScript. Esto no es del todo incorrecto. Sin embargo, todavía existe un riesgo porque los códigos escritos en muchos aspectos no son suficientes. Por lo tanto, sería prudente dejar esta tarea en manos del navegador de Internet que esté utilizando.
Sin embargo, como desarrollador, hay tres parámetros que debe conocer acerca de X-Frame-Options:
- Denegar: evita por completo que se llame a la página en cualquier iframe.
- MISMO ORIGEN: Evite que cualquier dominio que no sea el suyo llame dentro del iframe.
- PERMITIR-DE uri: Aceptar llamadas iframe de URI dadas como parámetro. Bloquea a otros.
Aquí el MISMO ORIGEN característica se destaca más. Porque si bien puede llamar a las aplicaciones en sus diferentes subdominios con iframes dentro de cada uno, puede evitar que se llamen a través del dominio bajo el control del atacante.
Estos son ejemplos de cómo puede usar SAMEORIGIN y X-Frame-Options con NGINX, Apache e IIS:
Usando X-Frame-Options SAMEORIGIN para Nginx:
add_header X-Frame-Opciones SAMEORIGIN;
Usando X-Frame-Options SAMEORIGIN para Apache:
El encabezado siempre agrega X-Frame-Options SAMEORIGIN
Usando X-Frame-Options SAMEORIGIN para IIS:
<httpProtocolo>
<encabezados personalizados>
<agregar nombre ="Opciones de marco X" valor="MISMO ORIGEN" />
</customHeaders>
</httpProtocol>
Simplemente agregar el encabezado SAMEORIGIN solo brindará mayor seguridad a sus visitantes.
¿Qué es la protección X-XSS?
El uso de la información del encabezado X-XSS-Protection puede proteger a los usuarios de los ataques XSS. En primer lugar, debe eliminar vulnerabilidades XSS en el lado de la aplicación. Después de proporcionar seguridad basada en código, se requieren medidas adicionales, es decir, encabezados de protección X-XSS, contra las vulnerabilidades XSS en los navegadores.
Cómo usar la protección X-XSS
Los navegadores modernos pueden detectar posibles cargas útiles de XSS filtrando el contenido generado por la aplicación. Es posible activar esta función con la información del encabezado X-XSS-Protection.
Para habilitar el encabezado X-XSS-Protection en Nginx:
add_header X-Frame-X-XSS-Protección 1;
Para habilitar el encabezado X-XSS-Protection en Apache:
El encabezado siempre agrega X-XSS-Protection 1
Para habilitar el encabezado X-XSS-Protection en IIS:
<httpProtocolo>
<encabezados personalizados>
<agregar nombre ="Protección X-XSS" valor="1" />
</customHeaders>
</httpProtocol>
Para evitar que se ejecute el bloque de código con el ataque XSS de forma predeterminada, puede usar algo como esto:
Protección X-XSS: 1; modo=bloque
Este cambio menor debe realizarse si existe una situación potencialmente peligrosa y desea evitar que se reproduzca todo el contenido.
¿Qué es X-Content-Type-Options?
Los navegadores realizan un análisis llamado MIME Type Sniffing en el contenido que les presenta la aplicación web. Por ejemplo, si hay una solicitud de acceso a un archivo PDF o PNG, los navegadores que realizan un análisis de la respuesta HTTP infieren el tipo de archivo.
Considere un archivo con una extensión jpeg pero que en realidad tiene contenido de texto/HTML. Después de usar las extensiones y pasar las protecciones en el módulo de carga, el archivo se carga correctamente. El archivo cargado se llama a través de la URL y, como resultado, el rastreo de tipo MIME devuelve Texto/HTML. Representa el contenido como HTML. Ahí es cuando ocurre la vulnerabilidad XSS.
Por lo tanto, debe evitar que los navegadores decidan sobre el contenido mediante el rastreo de tipo MIME. Para hacer esto, puedes usar nosniff.
Encabezado X-Content-Type-Options para Nginx:
add_header X-Content-Type-Options nosniff;
Encabezado X-Content-Type-Options para Apache:
Encabezado siempre X-Content-Type-Options nosniff
Encabezado X-Content-Type-Options para IIS:
<httpProtocolo>
<encabezados personalizados>
<agregar nombre ="Opciones de tipo de contenido X" valor="olfateando" />
</customHeaders>
</httpProtocol>
¿Qué es el indicador de cookies HttpOnly?
Las aplicaciones web rastrean las sesiones de los usuarios a través de la identificación de la sesión. Los navegadores almacenarán esto y lo agregarán automáticamente a cada solicitud HTTP dentro del alcance de la cookie.
Es posible usar cookies para propósitos sin embargo, aparte de la transferencia de la clave de sesión. Los piratas informáticos podrían encontrar los datos del usuario utilizando la vulnerabilidad XSS antes mencionada o mediante un ataque de falsificación de solicitud entre sitios (CSRF). Entonces, ¿qué cookies son más importantes en términos de seguridad?
Puede considerar la información contenida en la última imagen en la que hizo clic en la galería de imágenes como un ejemplo. De esta forma, el tráfico HTTP es menor y una parte de la carga puede ser resuelta por el navegador de Internet del usuario con secuencias de comandos del lado del cliente.
Ahí es donde Sólo Http viene en. A continuación se muestra un ejemplo de cómo debe ser la asignación de cookies:
Colocar-Galleta: usuario=t=cdabe8a1c2153d726; camino=/; Sólo Http
Observe el valor HttpOnly enviado en el Establecer-Cookie operación. El navegador verá esto y no procesará los valores con el indicador HttpOnly cuando se acceda a la cookie a través del documento.cookie variable. Otro indicador utilizado en el proceso de configuración de cookies es el indicador seguro. Esto indica que el valor de la cookie se agregará al encabezado solo para solicitudes HTTPS. Los sitios de comercio electrónico generalmente lo usan porque quieren reducir el tráfico de red y aumentar el rendimiento.
Con este método, puede ocultar datos críticos de los usuarios, como nombres de usuario, contraseñas e información de tarjetas de crédito. Pero hay un problema. A los usuarios que completan el proceso de inicio de sesión se les asigna un valor de cookie sin el indicador Seguro. El usuario puede tener la clave de sesión cuando realiza una solicitud HTTP a enlaces que no son HTTPS. Agregar la bandera segura es fácil:
Colocar-Galleta: usuario=t=cdabe8a1c2153d726; camino=/; Seguro
¿Cuándo no debería usar HttpOnly? Si confía en Javascript, debe tener cuidado, ya que esto puede hacer que su sitio sea menos seguro.
Los pequeños pasos funcionan para una seguridad web más amplia
No necesita software avanzado ni conocimientos de servidor para aumentar la seguridad de las aplicaciones web. Al cambiar solo unas pocas líneas, puede evitar algunos ataques graves. Por supuesto, esto no es suficiente. Sin embargo, es un paso pequeño pero efectivo para la seguridad del sitio web. El conocimiento es el mejor preventivo, por lo que también es útil conocer los matices sutiles de cómo HTTPS protege los datos durante la transferencia.