Mejores prácticas para referidos y políticas de referidos

Mejores prácticas para establecer su Política de referencia y utilizar la referencia en las solicitudes entrantes.

30 de julio de 2020
Actualizado 27 de agosto de 2020

Aparece en:
Seguro y a salvo

Resumen

• La fuga inesperada de información de origen cruzado dificulta la privacidad de los usuarios de la web. Una política de referencia protectora puede ayudar.
• Considere establecer una política de referencia de strict-origin-when-cross-origin. Conserva gran parte de la utilidad del remitente, al tiempo que mitiga el riesgo de filtrar orígenes cruzados de datos.
• No utilice referencias para la protección de falsificación de solicitudes entre sitios (CSRF). Utilizar Tokens CSRF
  en su lugar, y otros encabezadosConcepto de Encabezados¿Qué son los Encabezados?Los Encabezados, además conocidos como headers en inglés, son una parte fundamental del diseño de cualquier web, dado que consiste en la parte principal que se ve de esta al acceder, la parte de arriba de cualquier página. El lugar más visible y al que todos los usuarios que visitan un lugar de Internet acceden cuando entran en él, pudiendo tener así una imagen rápida más como una capa adicional de seguridad.

Referer y Referer-Policy 101

Las solicitudes HTTPEl HTTP (Hyper Text Transfer Protocol) es un protocolo que se usa para transmitir datos en redes. HTTP es un estándar técnico generalmente aceptado que establece cómo un cliente web se comunica con un servidor para que los datos solicitados por el cliente puedan ser cargados y mostrados. Información general Junto con el URL y el HTML, HTTP es uno de los conceptos más importantes de Internet (www). Fue desarrollado más pueden incluir el opcional Referer

encabezamiento, que indica el origen o la URLEl URL (Localizador Uniforme de Recursos), es una dirección definida que apunta a la posición de un archivo en un servidor y lo recupera. Las URL se introducen en un navegador web para ingresar a documentos en la web o se incrustan como hipervínculos dentro de un documento. Se puede usar un Permalink para que una URL esté disponible de forma permanente. Componentes de una URL • prefijo de protocolo más de la página web desde la que se realizó la solicitud. los Referrer-Policy

encabezamiento define qué datos están disponibles en el Referer encabezamiento.

En el siguiente ejemplo, el Referer El encabezado incluye la URL completa de la página en site-one desde donde se hizo la solicitud.

los Referer El encabezado puede estar presente en diferentes tipos de solicitudes:

• Solicitudes de navegación, cuando un usuario hace clic en un enlaceConcepto de Dominio¿Qué es un Enlace?En Internet, un link, además conocido como enlace o hipervínculo, es cualquier texto o imagen que se encuentra en una página web y en la que el usuario puede pulsar o clicar para ser dirigido a otro contenido distinto. Es el principal medio de “desplazamiento” en la red, puesto que se encuentra presente en prácticamente cualquier portal que visites a día de hoy, inclusive en más
• Solicitudes de subrecursos, cuando un navegadorUn navegador (además: browser) es una herramienta informática que te permite ver documentos y datos y navegar por la red. Los navegadores pueden mostrar distintos tipos de recursos de información; principalmente documentos HTML, a pesar de todo, además son posibles otros tipos de archivos y contenido multimedia, como PDF, JPEG, MPEG, GIF o el lenguaje de meta marcado. A través el uso de complementos especiales y la configuración respectivo, los más solicita imágenes, iframes, scriptsConcepto de Scripts¿Qué son los Scripts?Los Scripts son fragmentos de código que se usan para dar forma a herramientas tanto en Internet como en el sector de la informática en general. Son una parte crucial del software, puesto que se trata exactamente del código que conforma a una aplicación en su totalidad o a una de sus funciones, como además el que puedes hallar explorando cómo está hecha una web.Desde más y otros recursos que necesita una página.

Para navegaciones e iframes, también se puede acceder a estos datos a través de JavaScript utilizando
document.referrer.

los Referer El valor puede ser revelador. Por ejemplo, un servicio de análisis puede usar el valor para determinar que el 50% de los visitantes de site-two.example vino de social-network.example.

Pero cuando la URL completa, incluida la ruta y la cadena de consulta, se envía en el Referer a través de orígenes, esto puede ser obstaculizar la privacidad y posar riesgos de seguridad también. Eche un vistazo a estas URL:

Las URL del 1 al 5 contienen información privada, a veces incluso de identificación o confidencial. Filtrarlos silenciosamente a través de los orígenes puede comprometer la privacidad de los usuarios web.

La URL n. ° 6 es una URL de capacidad. No quiere que caiga en manos de nadie más que del usuario previsto. Si esto sucediera, un actor malintencionado podría secuestrar la cuenta de este usuario.

Para restringir qué datos de referencia están disponibles para las solicitudes de su sitio, puede establecer una política de referencia.

¿Qué políticas están disponibles y en qué se diferencian?

Puede seleccionar una de las ocho políticas. Según la política, los datos disponibles de la Referer
encabezado (y document.referrer) puede ser:

• Sin datos (no Referer el encabezado está presente)
• Solo el origen
• La URL completa: origen, ruta y cadena de consulta

Algunas pólizas están diseñadas para comportarse de manera diferente según el contexto: solicitud de origen cruzado o del mismo origen, seguridad (si el destino de la solicitud es tan seguro como el origen) o ambos. Esto es útil para limitar la cantidad de información compartida entre orígenes o para orígenes menos seguros, mientras se mantiene la riqueza del referente dentro de su propio sitio.

A continuación, se muestra una descripción general que muestra cómo las políticas de referencia restringen los datos de URL disponibles en el encabezado de referencia y document.referrer:

MDN proporciona una lista completa de políticas y ejemplos de comportamiento.

Cosas a tener en cuenta:

• Todas las políticas que tienen en cuenta el esquema (HTTPSHTTPS (protocolo de Transferencia de Hiper-Texto) es un protocolo que permite determinar una conexión segura entre el servidor y el cliente, que no puede ser interceptada por personas no autorizadas. En resumidas cuentas, es la versión segura de el http (Hyper Text Transfer Protocol) Cómo funciona Una conexión HTTP estándar en Internet puede ser fácilmente secuestrada por partes no autorizadas. El propósito de una conexión HTTPS es evitar esto: encriptar más frente a HTTP) (strict-origin,
  no-referrer-when-downgrade y strict-origin-when-cross-origin) tratan las solicitudes de un origen HTTP a otro origen HTTP de la misma manera que las solicitudes de un origen HTTPS a otro origen HTTPS, incluso si HTTP es menos seguro. Eso es porque para estas políticas, lo que importa es si una seguridad degradar tiene lugar, es decir, si la solicitud puede exponer datos de un origen cifrado a uno no cifrado. Una solicitud HTTP → HTTP no está encriptada todo el tiempo, por lo que no hay degradación. HTTPS → Las solicitudes HTTP, por el contrario, presentan una degradación.
• Si una solicitud es mismo origen, esto significa que el esquema (HTTPS o HTTP) es el mismo; por lo tanto, no hay degradación de seguridad.

Políticas de referencia predeterminadas en los navegadoresConcepto de Navegadores¿Qué son los Navegadores?Los Navegadores son herramientas informáticas que utilizamos para, normalmente, navegar por Internet y visitar cualquier página web, al mismo tiempo de para hacer otras tareas como ver documentos, observar vídeos o reproducir contenido multimedia de cualquier tipo. Son un tipo de software sencillamente usual y bastante utilizado hoy en día.Insistimos en que es algo que se utiliza con mucha frecuencia, puesto que moverse por Internet más

A julio de 2020

Si no se establece una política de referencia, se utilizará la política predeterminada del navegador.

Configuración de su política de referencias: mejores prácticas

Hay diferentes formas de establecer políticas de referencia para su sitio:

Puede establecer diferentes políticas para diferentes páginas, solicitudes o elementos.

El encabezado HTTP y el elemento meta están a nivel de página. El orden de precedencia al determinar la política efectiva de un elemento es:

1. Política a nivel de elemento
2. Política de nivel de página
3. Navegador predeterminado

Ejemplo:

indexUn index o índice es generalmente un directorio en un orden específico que se usa con fines de orientación. En términos de motores de búsqueda, un índice es la lista de páginas web que es emitido por el motor de búsqueda en respuesta a una solicitud de búsqueda del usuario. Información general La lista que se muestra posteriormente de introducir una solicitud de búsqueda específica se llama SERPs (Search Engine más.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

La imagen se solicitará con un no-referrer-when-downgrade política, mientras que todas las demás solicitudes de recursos secundarios de esta página seguirán la strict-origin-when-cross-origin política.

¿Cómo ver la política de referencias?

Al inspeccionar una solicitud HTTP:

• en Chrome, Edge y Firefox, puede ver el Referrer-Policy.
• en Chrome, Edge, Safari y Firefox, puede ver el Referer.

¿Qué política debería establecer para su sitio web?

Resumen: establezca explícitamente una política de mejora de la privacidad como strict-origin-when-cross-origin (o más estricto).

¿Por qué «explícitamente»?

Si no se establece una política de referencia, se utilizará la política predeterminada del navegador; de hecho, los sitios web suelen ceder a la predeterminada del navegador. Pero esto no es ideal, porque:

• Las políticas predeterminadas del navegador son no-referrer-when-downgrade,
  strict-origin-when-cross-origino más estricto, según el navegador y el modo (privado / incógnito). Por lo tanto, su sitio web no se comportará de manera predecible en todos los navegadores.
• Los navegadores están adoptando valores predeterminados más estrictos, como strict-origin-when-cross-origin y mecanismos como recorte de referencia para solicitudes de origen cruzado. Optar explícitamente por una política de mejora de la privacidad antes de que cambien los valores predeterminados del navegador le da control y le ayuda a ejecutar las pruebas como mejor le parezca.

Por qué strict-origin-when-cross-origin (o más estricto)?

Necesita una política que sea segura, que mejore la privacidad y que sea útil; lo que significa «útil» depende de lo que desee del remitente:

• Seguro: si su sitio web utiliza HTTPS (si no es así, conviértalo en una prioridad), no desea que las URL de su sitio web se filtren en solicitudes que no sean HTTPS. Dado que cualquier persona en la red puede verlos, esto expondría a sus usuarios a ataques de persona en el medio. Los policias no-referrer-when-downgrade,
  strict-origin-when-cross-origin, no-referrer y strict-origin resuelve este problema.
• Mejora de la privacidad: para una solicitud de origen cruzado, no-referrer-when-downgrade comparte la URL completa; esto no mejora la privacidad. strict-origin-when-cross-origin y strict-origin solo comparte el origen, y no-referrer no comparte nada en absoluto. Esto te deja con
  strict-origin-when-cross-origin, strict-originy no-referrer como opciones para mejorar la privacidad.
• Útil: no-referrer y strict-origin nunca comparta la URL completa, incluso para solicitudes del mismo origen, por lo que si necesita esto, strict-origin-when-cross-origin es una mejor opción.

Todo esto significa que strict-origin-when-cross-origin es generalmente una opción sensata.

Ejemplo: establecer un strict-origin-when-cross-origin política:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

O del lado del servidorLos servidores son ordenadores centrales y potentes dentro del campo de la tecnología de la información que procesan y proporcionan software y archivos en una red. Desde el punto de vista de un cliente, varios ordenadores en una red pueden ponerse en contacto con el servidor central para conseguir la información solicitada. En la arquitectura cliente-servidor, el servidor puede ser un software que proporciona un servicio y se ejecuta en más, por ejemplo en Express:

const helmet = require('helmet');
appConcepto de APP¿Qué es una APP?Una App es todo aquel programa que se ejecuta desde una interfaz teléfono celular, es decir, desde un móvil o una tablet. Consiste en la herramienta principal para cualquier usuario que tenga un teléfono teléfono celular, de todo el software que se mueve en tiendas digitales como Google Play Store o la App Store y que tanto se adentra en cualquier terminal moderno.Es un concepto más.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Y si strict-origin-when-cross-origin (o más estricto) no se adapta a todos sus casos de uso?

En este caso, no establezca una política insegura como unsafe-url. Lo que puede hacer en cambio es tomar un
enfoque progresivo: establezca una política de protección para su sitio web y, si es necesario, una política más permisiva para solicitudes o elementos específicos.

Ejemplo:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="…" referrerpolicy="no-referrer-when-downgrade" />

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

¿Qué más deberías considerar?

Su política debe depender de su sitio web y de los casos de uso; esto depende de usted, su equipo y su empresa. Si algunas URL contienen datos de identificación o confidenciales, establezca una política de protección.

Usar la referencia de solicitudes entrantes: mejores prácticas

Protección de falsificación de solicitudes entre sitios (CSRF)

El uso de la referencia de las solicitudes entrantes para la protección CSRF tiene algunas dificultades:

• Puede ocultarse con el no-referrer política, o falsificada por el emisor de la solicitud. Si no tiene control sobre la implementación del emisor de solicitudes, no puede hacer suposiciones sobre ningún encabezado que reciba.
• los Referer encabezado (y document.referrer) puede contener más datos de los que necesitas, por ejemplo, una URL completa cuando solo desea saber si la solicitud es de origen cruzado.

Utilizar Tokens CSRF
como su protección principal en su lugar. Para mayor protección, use SameSite, y en lugar de Referer, puede usar encabezados como
Origin (disponible en solicitudes POSTConcepto de Post¿Qué es un Post?Un Post es todo aquel contenido, sea post, opinión, noticia u otro género, que un autor publica en un blog. Este puede ser de carácter corporativo o meramente ocioso; pero siempre tiene como meta arrojar información o reflejar una idea, al mismo tiempo de facilitar que los usuarios encuentren la web donde se recoge por medio de de buscadores y demás plataformas online.Generalmente, se han más y CORS) y
Sec-Fetch-Site (si está disponible).

Inicio sesión

los Referer encabezado (y document.referrer) puede contener datos privados, personales o de identificación, por lo que debe tratarse como tal.

Y en lugar de Referer, considere usar otros encabezados que puedan abordar su caso de uso:
Origin y
Sec-Fetch-Site.

Pagos

Los proveedores de pago pueden confiar en Referer encabezado de las solicitudes entrantes de controles de seguridad.

Por ejemplo:

• El usuario hace clic en un Comprar botón encendido online-shop.example/cart/checkout.
• online-shop.example redirecciona a payment-provider.example para gestionar la transacción.
• payment-provider.example comprueba el Referer de esta solicitud contra una lista de permitidos
  Referer valores establecidos por los comerciantes. Si no coincide con ninguna entrada de la lista,
  payment-provider.example rechaza la solicitud. Si coincide, el usuario puede continuar con la transacción.

Mejores prácticas para controles de seguridad del flujo de pagos

Resumen: como proveedor de pagos, puede utilizar el Referer como un control básico contra ataques ingenuos, pero definitivamente debe tener otro método de verificación más confiable en su lugar.

los Referer El encabezado por sí solo no es una base confiable para una verificación: el sitio solicitante, ya sea un comerciante legítimo o no, puede establecer fácilmente un no-referrer política que hará que el Referer
información no disponible para el proveedor de pago. Sin embargo, como proveedor de pagos, mirando el
Referer puede ayudarlo a atrapar a atacantes ingenuos que no establecieron un no-referrer política. Entonces puede decidir usar el Referer como primer control básico. Si tu haces eso:

• No esperes el Referer estar siempre presente; y si está presente, solo verifique con la pieza de datos que incluirá como mínimo: el origen. Al configurar la lista de permitidos
  Referer valores, asegúrese de que no se incluya ninguna ruta, sino solo el origen. Ejemplo: el permitido
  Referer valores para online-shop.example debiera ser online-shop.exampleno
  online-shop.example/cart/checkout. ¿Por qué? Porque al esperar o no Referer en absoluto o un
  Referer valor que es el origen del sitio web solicitante, evita errores inesperados ya que está no hacer suposiciones sobre el Referrer-Policy su comerciante ha establecido o sobre el comportamiento del navegador si el comerciante no tiene una política establecida. Tanto el sitio como el navegador podrían quitar la Referer enviado en la solicitud entrante solo al origen o no enviar el Referer en absoluto.
• Si el Referer está ausente o si está presente y su Referer la verificación de origen fue exitosa: puede pasar a su otro método de verificación más confiable (ver más abajo).

¿Cuál es un método de verificación más confiable?

Un método de verificación confiable es permitir que el solicitante hash los parámetros de la solicitud junto con una clave única. Como proveedor de pagos, puede calcula el mismo hash de tu lado y solo acepte la solicitud si coincide con su cálculo.

¿Qué pasa con el Referer ¿Cuándo un sitio de comerciante HTTP sin política de referencia redirecciona a un proveedor de pago HTTPS?

No Referer será visible en la solicitud para el proveedor de pago HTTPS, porque la mayoría de los navegadores utilizan strict-origin-when-cross-origin o
no-referrer-when-downgrade de forma predeterminada cuando un sitio web no tiene una política establecida. También tenga en cuenta que Cambio de Chrome a una nueva política predeterminada no cambiará este comportamiento.

Conclusión

Una política de referencia protectora es una excelente manera de brindar a sus usuarios más privacidad.

Para obtener más información sobre las diferentes técnicas para proteger a sus usuarios, consulte la colección segura y protegida de web.dev.

Muchas gracias por las contribuciones y comentarios a todos los revisores, especialmente a Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck y Kayce Basques.

Recursos