stringtranslate.com

Redirección de URL

La redirección de URL , también llamada reenvío de URL , es una técnica de la World Wide Web que permite que una página web esté disponible en más de una dirección URL . Cuando un navegador web intenta abrir una URL que ha sido redirigida, se abre una página con una URL diferente. De manera similar, la redirección de dominio o reenvío de dominio es cuando todas las páginas de un dominio URL se redirigen a un dominio diferente, como cuando wikipedia.com y wikipedia.net se redirigen automáticamente a wikipedia.org.

La redirección de URL se realiza por varios motivos:

Propósitos

Existen varias razones para utilizar la redirección de URL:

Forzar HTTPS

Es posible que un sitio web sea accesible tanto a través de un esquema de URI HTTPS seguro como de HTTP simple (un URI inseguro que comienza con "http://").

Si un usuario escribe una URI o hace clic en un enlace que hace referencia a la variante insegura, el navegador lo redireccionará automáticamente a la versión segura en caso de que el sitio web esté incluido en la lista de precarga HSTS enviada con la aplicación o si el usuario ya haya visitado el origen en el pasado.

De lo contrario, se contactará con el sitio web a través de HTTP. El operador de un sitio web puede decidir atender dichas solicitudes redirigiendo el navegador a la variante HTTPS y, con suerte, preparando también HSTS para futuros accesos.

Nombres de dominio similares

Un usuario puede escribir mal una URL. Las organizaciones suelen registrar estos dominios mal escritos y redirigirlos a la ubicación deseada. Esta técnica se suele utilizar para "reservar" otros dominios de nivel superior (TLD) con el mismo nombre o para facilitar que un sitio ".edu" o ".net" pueda alojar a los usuarios que escriben ".com".

Mover páginas a un nuevo dominio

Las páginas web pueden redirigirse a un nuevo dominio por tres motivos:

Con las redirecciones de URL, los enlaces entrantes a una URL obsoleta se pueden enviar a la ubicación correcta. Estos enlaces pueden provenir de otros sitios que no se han dado cuenta de que hay un cambio o de marcadores/favoritos que los usuarios han guardado en sus navegadores. Lo mismo se aplica a los motores de búsqueda . A menudo, tienen los nombres de dominio y enlaces más antiguos/obsoletos en su base de datos y enviarán a los usuarios de búsqueda a estas URL antiguas. Al utilizar una redirección "movida permanentemente" a la nueva URL, los visitantes terminarán en la página correcta. Además, en la siguiente pasada del motor de búsqueda, el motor de búsqueda debería detectar y utilizar la URL más nueva.

Registro de enlaces salientes

Los registros de acceso de la mayoría de los servidores web guardan información detallada sobre el origen de los visitantes y cómo navegaron por el sitio alojado. Sin embargo, no registran los enlaces que dejaron los visitantes. Esto se debe a que el navegador del visitante no tiene necesidad de comunicarse con el servidor original cuando hace clic en un enlace saliente. Esta información se puede capturar de varias formas. Una de ellas implica la redirección de URL. En lugar de enviar al visitante directamente al otro sitio, los enlaces del sitio pueden dirigir a una URL en el dominio del sitio web original que redirige automáticamente al destino real. Esta técnica tiene la desventaja de la demora causada por la solicitud adicional al servidor del sitio web original. Como esta solicitud adicional dejará un rastro en el registro del servidor, que revelará exactamente qué enlace se siguió, también puede ser un problema de privacidad. [1] Algunos sitios web corporativos también utilizan la misma técnica para implementar una declaración de que el contenido posterior se encuentra en otro sitio y, por lo tanto, no necesariamente afiliado a la corporación. En tales escenarios, mostrar la advertencia causa una demora adicional.

Alias ​​cortos para URL largas

Las aplicaciones web suelen incluir en sus URL atributos descriptivos extensos que representan jerarquías de datos, estructuras de comandos, rutas de transacciones e información de sesión. Esta práctica da como resultado una URL que es estéticamente desagradable y difícil de recordar, y que puede no ajustarse a las limitaciones de tamaño de los sitios de microblogging . Los servicios de acortamiento de URL brindan una solución a este problema al redirigir al usuario a una URL más larga desde una más corta. [1]

Alias ​​significativos y persistentes para URL largas o cambiantes

A veces, la URL de una página cambia aunque el contenido siga siendo el mismo. Por lo tanto, la redirección de URL puede ayudar a los usuarios que tienen marcadores. Esto se hace de manera rutinaria en Wikipedia cada vez que se cambia el nombre de una página.

Publicar/Redirigir/Obtener

Post/Redirect/Get (PRG) es un patrón de diseño de desarrollo web que evita algunos envíos de formularios duplicados si el usuario hace clic en el botón actualizar después de enviar el formulario, creando una interfaz más intuitiva para los agentes de usuario (usuarios).

Segmentación por dispositivo y geosegmentación

Las redirecciones se pueden utilizar de forma eficaz para fines de segmentación, como la segmentación geográfica . La segmentación por dispositivo se ha vuelto cada vez más importante con el aumento de los clientes móviles. Hay dos enfoques para atender a los usuarios móviles: hacer que el sitio web responda o redirigir a una versión de sitio web móvil. Si se ofrece una versión de sitio web móvil, los usuarios con clientes móviles serán redirigidos automáticamente al contenido móvil correspondiente. Para la segmentación por dispositivo, se utilizan redirecciones del lado del cliente o redirecciones del lado del servidor no almacenables en caché. La segmentación geográfica es el enfoque para ofrecer contenido localizado y redireccionar automáticamente al usuario a una versión localizada de la URL solicitada. Esto es útil para sitios web que se dirigen a una audiencia en más de una ubicación y/o idioma. Por lo general, se utilizan redirecciones del lado del servidor para la segmentación geográfica, pero las redirecciones del lado del cliente también pueden ser una opción, según los requisitos. [2]

Manipulación de motores de búsqueda

Las redirecciones se han utilizado para manipular los motores de búsqueda con intenciones poco éticas, por ejemplo, el secuestro de URL . El objetivo de las redirecciones engañosas es dirigir el tráfico de búsqueda a páginas de destino, que no tienen suficiente poder de clasificación por sí mismas o que solo están relacionadas de manera remota o nada con el objetivo de búsqueda. El enfoque requiere una clasificación para una variedad de términos de búsqueda con una serie de URL que utilizarían redirecciones furtivas para enviar al buscador a la página de destino. Este método tuvo un resurgimiento con el auge de los dispositivos móviles y la segmentación por dispositivo. El secuestro de URL es una técnica de redireccionamiento fuera del dominio [3] que explotó la naturaleza del manejo del motor de búsqueda para redirecciones temporales. Si se encuentra una redirección temporal, los motores de búsqueda tienen que decidir si asignan el valor de clasificación a la URL que inicializa la redirección o a la URL de destino de la redirección. La URL que inicia la redirección puede mantenerse para que aparezca en los resultados de búsqueda, ya que la redirección indica una naturaleza temporal. En determinadas circunstancias, era posible explotar este comportamiento aplicando redirecciones temporales a URLs bien posicionadas, lo que provocaba que la URL original en los resultados de búsqueda fuera reemplazada por la URL que había iniciado la redirección, y por lo tanto, "robando" la posición en la clasificación. Este método se combinaba habitualmente con redirecciones furtivas para redirigir el flujo de usuarios desde los resultados de búsqueda a una página de destino. Los motores de búsqueda han desarrollado tecnologías eficientes para detectar este tipo de enfoques manipuladores. Los principales motores de búsqueda suelen aplicar duras penalizaciones de clasificación a los sitios que son descubiertos aplicando técnicas como estas. [4]

Manipulando a los visitantes

La redirección de URL se utiliza a veces como parte de ataques de phishing que confunden a los visitantes sobre el sitio web que están visitando. [5] Debido a que los navegadores modernos siempre muestran la URL real en la barra de direcciones, la amenaza se reduce. Sin embargo, las redirecciones también pueden llevarte a sitios que, de lo contrario, intentarían atacarte de otras formas. Por ejemplo, una redirección podría llevar a un usuario a un sitio que intentaría engañarlo para que descargue un software antivirus e instale un troyano de algún tipo en su lugar.

Eliminando referrerinformación

Cuando se hace clic en un enlace, el navegador envía junto con la solicitud HTTP un campo llamado referer que indica la fuente del enlace. Este campo se rellena con la URL de la página web actual y terminará en los registros del servidor que proporciona el enlace externo. Dado que las páginas confidenciales pueden tener URL confidenciales (por ejemplo, https://company.com/plans-for-the-next-release-of-our-product), no es deseable que la referrerURL salga de la organización. Una página de redireccionamiento que oculte el referente podría estar incrustada en todas las URL externas, transformándose, por ejemplo, https://externalsite.com/pageen https://redirect.company.com/https://externalsite.com/page. Esta técnica también elimina otra información potencialmente confidencial de la URL de referencia, como el ID de sesión , y puede reducir la posibilidad de suplantación de identidad al indicar al usuario final que pasó por una puerta de enlace clara a otro sitio.

Implementación

Existen varios tipos de respuestas diferentes al navegador que darán como resultado una redirección. Estas varían en función de si afectan a los encabezados HTTP o al contenido HTML. Las técnicas utilizadas normalmente dependen del rol de la persona que las implementa y de su acceso a diferentes partes del sistema. Por ejemplo, un autor web sin control sobre los encabezados puede utilizar una etiqueta meta Refresh , mientras que un administrador de servidor web que redirija todas las páginas de un sitio es más probable que utilice la configuración del servidor.

Redirección manual

La técnica más sencilla es pedirle al visitante que siga un enlace a la nueva página, generalmente utilizando un ancla HTML como:

Por favor, siga < a  href = "https://www.example.com/" > este enlace </ a > .

Este método se utiliza a menudo como alternativa: si el navegador no admite la redirección automática, el visitante aún puede llegar al documento de destino siguiendo el enlace.

Códigos de estado HTTP 3xx

En el protocolo HTTP utilizado por la World Wide Web , una redirección es una respuesta con un código de estado que comienza con 3 y que hace que el navegador muestre una página diferente. Si un cliente encuentra una redirección, debe tomar una serie de decisiones sobre cómo manejarla. Los clientes utilizan distintos códigos de estado para comprender el propósito de la redirección, cómo manejar el almacenamiento en caché y qué método de solicitud utilizar para la solicitud posterior.

HTTP/1.1 define varios códigos de estado para la redirección (RFC 7231):

Los códigos de estado 304 no modificado y 305 usar proxy no son redirecciones.

Todos estos códigos de estado requieren que la URL del destino de la redirección se proporcione en el encabezado Ubicación: de la respuesta HTTP. Las 300 opciones múltiples generalmente enumerarán todas las opciones en el cuerpo del mensaje y mostrarán la opción predeterminada en el encabezado Ubicación:.

Ejemplo de respuesta HTTP para una redirección 301

Una respuesta HTTP con la redirección 301 "movido permanentemente" se ve así:

HTTP / 1.1  301  Movido permanentemente Ubicación :  https://www.example.org/ Tipo de contenido :  text/html Longitud del contenido :  174< html > < head > < title > Movido </ title > </ head > < body >=Movido=< p > Esta página se ha movido a < a  href = "https://www.example.org/" > https://www.example.org/ </ a > . </ p > </ body > </ html >

Uso de scripts del lado del servidor para redirección

Los autores de páginas web que producen contenido HTML normalmente no pueden crear redirecciones utilizando encabezados HTTP, ya que estos son generados automáticamente por el programa del servidor web cuando sirve un archivo HTML. Lo mismo suele suceder incluso con los programadores que escriben scripts CGI, aunque algunos servidores permiten que los scripts agreguen encabezados personalizados (por ejemplo, habilitando "encabezados no analizados"). Muchos servidores web generarán un código de estado 3xx si un script genera una línea de encabezado "Ubicación:". Por ejemplo, en PHP , se puede utilizar la función "encabezado":

encabezado ( 'HTTP/1.1 301 Movido permanentemente' ); encabezado ( 'Ubicación: https://www.example.com/' ); salida ();

Es posible que se requieran más encabezados para evitar el almacenamiento en caché. [7] El programador debe asegurarse de que los encabezados se muestren antes del cuerpo. Esto puede no encajar fácilmente con el flujo natural de control a través del código. Para ayudar con esto, algunos marcos para la generación de contenido del lado del servidor pueden almacenar en búfer los datos del cuerpo. En el lenguaje de scripting ASP , esto también se puede lograr utilizando response.buffer=truey response.redirect "https://www.example.com/"HTTP/1.1 permite una referencia URI relativa o una referencia URI absoluta. [8] Si la referencia URI es relativa, el cliente calcula la referencia URI absoluta requerida de acuerdo con las reglas definidas en RFC 3986. [9]

Mod_rewrite del servidor HTTP Apache

La extensión mod_alias del servidor HTTP Apache se puede utilizar para redirigir determinadas solicitudes. Las directivas de configuración típicas son las siguientes:

Redirección  permanente /oldpage.html https://www.example.com/newpage.html Redirección 301 /oldpage.html https://www.example.com/newpage.html     

Para una reescritura y redirección de URL más flexible , se puede utilizar Apache mod_rewrite. Por ejemplo, para redirigir una solicitud a un nombre de dominio canónico:

RewriteEngine en RewriteCond %{HTTP_HOST} ^([^.:]+\.)*sitioantiguo\.ejemplo\.com\.?(:[0-9]*)?$ [NC] RewriteRule ^(.*)$ https://sitionuevo.ejemplo.net/$1 [R=301,L]       

Esta configuración se puede aplicar a uno o todos los sitios del servidor a través de los archivos de configuración del servidor o a un solo directorio de contenido a través de un .htaccessarchivo.

reescritura de nginx

Nginx tiene un módulo de reescritura de http integrado, [10] que se puede utilizar para realizar un procesamiento avanzado de URL e incluso la generación de páginas web (con la returndirectiva ). Un ejemplo de este uso avanzado del módulo de reescritura es mdoc.su, que implementa un servicio de acortamiento de URL determinista completamente con la ayuda del lenguaje de configuración de nginx únicamente. [11] [12]

Por ejemplo, si /DragonFlyBSD/HAMMER.5viniera una solicitud de, primero se redirigiría internamente a /d/HAMMER.5con la primera directiva de reescritura a continuación (solo afecta el estado interno, sin ninguna respuesta HTTP emitida al cliente todavía), y luego, con la segunda directiva de reescritura, se emitiría una respuesta HTTP con un código de estado 302 Found al cliente para redirigir al script cgi externo de web- man : [13]

 ubicación /DragonFly { reescribir ^/DragonFly(BSD)?([,/].*)? $ /d $2 último ; } ubicación /d { establecer $db "https://leaf.dragonflybsd.org/cgi/web-man?command=" ; establecer $ds "§ion=" ; reescribir ^/./([^/]+)\.([1-9]) $ $db$1$ds$2 redirigir ; }                     

Actualizar la etiqueta meta y el encabezado de actualización HTTP

Netscape introdujo la función de actualización de metadatos , que actualiza una página después de un tiempo determinado. Esta función permite especificar una nueva URL para reemplazar una página por otra. La mayoría de los navegadores web admiten esta función. [14] [15] Un tiempo de espera de cero segundos produce una redirección inmediata. Google la trata como una redirección permanente 301, lo que permite transferir PageRank a la página de destino. [16]

Este es un ejemplo de un documento HTML simple que utiliza esta técnica:

< html > < head >  < meta  http-equiv = "Refresh"  content = "0; url=https://www.example.com/"  /> </ head > < body >  < p > Por favor, siga < a  href = "https://www.example.com/" > este enlace </ a > . </ p > </ body > </ html >

Los autores de páginas web pueden utilizar esta técnica porque la etiqueta meta está contenida dentro del propio documento. La etiqueta meta debe colocarse en la sección "head" del archivo HTML. El número "0" en este ejemplo puede reemplazarse por otro número para lograr un retraso de esa cantidad de segundos. El ancla en la sección "body" es para los usuarios cuyos navegadores no admiten esta función.

El mismo efecto se puede lograr con un refreshencabezado HTTP:

HTTP / 1.1  200  OK Actualizar :  0; url=https://www.example.com/ Tipo de contenido :  texto/html Longitud del contenido :  78Por favor, siga < a  href = "https://www.example.com/" > este enlace </ a > .

Esta respuesta es más fácil de generar mediante programas CGI porque no es necesario cambiar el código de estado predeterminado.

Aquí hay un programa CGI simple que efectúa esta redirección:

# !/usr/bin/perl print "Actualizar: 0; url=https://www.example.com/\r\n" ; print "Tipo-de-contenido: texto/html\r\n" ; print "\r\n" ; print "¡Por favor, siga <a href=\"https://www.example.com/\">este enlace</a>!"    

Nota: normalmente, el servidor HTTP agrega la línea de estado y el encabezado Content-Length automáticamente.

El W3C desaconseja el uso de la actualización meta, ya que no comunica ninguna información sobre el recurso original o nuevo al navegador (o motor de búsqueda ). Las Pautas de Accesibilidad al Contenido Web del W3C (7.4) [17] desaconsejan la creación de páginas que se actualicen automáticamente, ya que la mayoría de los navegadores web no permiten al usuario desactivar o controlar la frecuencia de actualización. Algunos artículos que han escrito sobre el tema incluyen Pautas de Accesibilidad al Contenido Web del W3C (1.0): Garantizar el control del usuario de los cambios de contenido sensibles al tiempo, Usar redirecciones estándar: ¡no rompa el botón de retroceso! [18] y Técnicas básicas para las Pautas de Accesibilidad al Contenido Web 1.0 sección 7. [19]

Redirecciones de JavaScript

JavaScript puede provocar una redirección configurando el window.locationatributo, por ejemplo:

ventana . ubicación = 'https://www.ejemplo.com/'

Normalmente, JavaScript envía la URL del sitio redireccionador al historial del navegador. Esto puede provocar bucles de redireccionamiento cuando los usuarios presionan el botón Atrás. Con el siguiente comando puedes evitar este tipo de comportamiento. [20]

ventana . ubicación . reemplazar ( 'https://www.example.com/' )

Sin embargo, los encabezados HTTP o la metaetiqueta de actualización pueden ser preferibles por razones de seguridad y porque algunos navegadores y muchos rastreadores web no ejecutarán JavaScript .

Redirecciones de marco

Se puede lograr un efecto ligeramente diferente creando un marco en línea :

< iframe  height = "100%"  width = "100%"  src = " https://www.example.com/ " >
Siga el enlace < a  href = "https://www.example.com/" > . </ iframe >

Una diferencia importante con los métodos de redirección anteriores es que, en el caso de una redirección de marco, el navegador muestra la URL del documento de marco y no la URL de la página de destino en la barra de URL. Esta técnica de encubrimiento se puede utilizar para que el lector vea una URL más fácil de recordar o para ocultar fraudulentamente un sitio de phishing como parte de una suplantación de identidad de un sitio web . [21]

Antes de HTML5, [22] se podía lograr el mismo efecto con un marco HTML que contenía la página de destino:

< frameset  rows = "100%" >  < frame  src = "https://www.example.com/" >  < noframes >  < body > Por favor, siga el enlace < a  href = "https://www.example.com/" > </ a > . </ body >  </ noframes > </ frameset >

Cadenas de redireccionamiento

Una redirección puede llevar a otra en una cadena de redireccionamiento. Si una redirección lleva a otra redirección, esto también puede conocerse como una redirección doble. [23] Por ejemplo, la URL "https://wikipedia.com" (con "*.com" como dominio) se redirige primero a https://www.wikipedia.org/ (con nombre de dominio en .org ), donde puede navegar al sitio específico del idioma. Esto es inevitable si los diferentes enlaces en la cadena son servidos por diferentes servidores, aunque debe minimizarse reescribiendo la URL tanto como sea posible en el servidor antes de devolverla al navegador como una redirección.

Bucles de redireccionamiento

A veces, un error puede provocar que una página acabe redirigiéndose a sí misma, posiblemente a través de otras páginas, lo que da lugar a una secuencia infinita de redirecciones. Los navegadores deberían dejar de redirigir después de una determinada cantidad de saltos y mostrar un mensaje de error.

El estándar HTTP/1.1 establece: [24]

Un cliente DEBE detectar e intervenir en redirecciones cíclicas (es decir, bucles de redirección "infinitos").

Nota: Una versión anterior de esta especificación recomendaba un máximo de cinco redirecciones ([RFC 2068], Sección 10.3). Los desarrolladores de contenido deben tener en cuenta que algunos clientes podrían implementar una limitación fija de este tipo.

Servicios

Existen servicios que pueden realizar redireccionamientos de URL a pedido, sin necesidad de trabajo técnico ni acceso al servidor web en el que está alojado su sitio.

Servicios de redirección de URL

Un servicio de redireccionamiento es un sistema de gestión de información que proporciona un enlace de Internet que redirige a los usuarios al contenido deseado. El beneficio típico para el usuario es el uso de un nombre de dominio fácil de recordar y una reducción en la longitud de la URL o dirección web. Un enlace de redireccionamiento también se puede utilizar como una dirección permanente para contenido que cambia de host con frecuencia, de manera similar al Sistema de nombres de dominio . Los hipervínculos que involucran servicios de redireccionamiento de URL se utilizan con frecuencia en mensajes de spam dirigidos a blogs y wikis. Por lo tanto, una forma de reducir el spam es rechazar todas las ediciones y comentarios que contengan hipervínculos a servicios de redireccionamiento de URL conocidos; sin embargo, esto también eliminará ediciones y comentarios legítimos y puede no ser un método eficaz para reducir el spam. Recientemente, los servicios de redireccionamiento de URL han comenzado a utilizar AJAX como un método eficiente y fácil de usar para crear URL acortadas. Una desventaja importante de algunos servicios de redireccionamiento de URL es el uso de páginas de retraso o publicidad basada en marcos para generar ingresos.

Historia

Los primeros servicios de redireccionamiento aprovecharon los dominios de nivel superior (TLD) como " .to " (Tonga), " .at " (Austria) y " .is " (Islandia). Su objetivo era crear URL memorables. El primer servicio de redireccionamiento generalizado fue V3.com, que contaba con 4 millones de usuarios en su apogeo en 2000. El éxito de V3.com se atribuyó a tener una amplia variedad de dominios cortos memorables, incluidos "r.im", "go.to", "i.am", "come.to" y "start.at". V3.com fue adquirida por FortuneCity.com, una gran empresa de alojamiento web gratuito, a principios de 1999. [25] A medida que el precio de venta de los dominios de nivel superior comenzó a caer de $ 50,00 por año a menos de $ 10,00 , el uso de servicios de redireccionamiento disminuyó. Con el lanzamiento de TinyURL en 2002 nació un nuevo tipo de servicio de redireccionamiento, llamado acortamiento de URL . Su objetivo era acortar las URL largas para poder publicarlas en foros de Internet. Desde 2006, con el límite de 140 caracteres en el popular servicio Twitter , estos servicios de URL cortas se han utilizado mucho.

Enmascaramiento de referentes

Los servicios de redirección pueden ocultar el referente colocando una página intermedia entre la página en la que se encuentra el enlace y su destino. Aunque conceptualmente son similares a otros servicios de redirección de URL, tienen un propósito diferente y rara vez intentan acortar u ofuscar la URL de destino (ya que su único efecto secundario previsto es ocultar la información del referente y proporcionar una puerta de enlace clara entre otros sitios web). Este tipo de redirección se utiliza a menudo para evitar que los enlaces potencialmente maliciosos obtengan información utilizando el referente, por ejemplo, un ID de sesión en la cadena de consulta. Muchos sitios web comunitarios importantes utilizan la redirección de enlaces en enlaces externos para reducir la posibilidad de un exploit que podría usarse para robar información de la cuenta, así como para dejar en claro cuándo un usuario abandona un servicio, para reducir la posibilidad de un phishing efectivo .

A continuación se muestra un ejemplo simplista de dicho servicio, escrito en PHP .

<?php $url  =  htmlspecialchars ( $_GET [ 'url' ]); header ( 'Actualizar: 0; url=https://'  .  $url ); ?> <!-- Revertir usando la actualización meta. --> < html >  < head >  < title > Redireccionando... </ title >  < meta  http-equiv = "refresh"  content = "0;url=https:// <? =  $url ;  ?> " >  </ head >  < body > Intentando redirigir a < a  href = "https:// <? =  $url ;  ?> " > https:// <? =  $url ;  ?> </ a > . </ body > </ html >

El ejemplo anterior no comprueba quién lo ha llamado (por ejemplo, mediante el referente, aunque podría ser falso). Tampoco comprueba la URL proporcionada. Esto significa que una persona malintencionada podría acceder a la página de redireccionamiento utilizando un parámetro de URL de su propia elección, desde cualquier página que utilice los recursos del servidor web.

Problemas de seguridad

Los atacantes pueden abusar de la redirección de URL para realizar ataques de phishing . Si una aplicación web no valida suficientemente el objetivo de la redirección, un atacante puede hacer que una aplicación web redirija a un sitio web arbitrario. Esta vulnerabilidad se conoce como vulnerabilidad de redirección abierta. [26] [27] En ciertos casos, cuando se produce una redirección abierta como parte de un flujo de autenticación , la vulnerabilidad se conoce como redirección encubierta. [28] [29] Cuando se produce una redirección encubierta, el sitio web del atacante puede robar información de autenticación del sitio web de la víctima. [26] Las vulnerabilidades de redirección abierta son bastante comunes en la web. En junio de 2022, TechRadar encontró más de 25 ejemplos activos de vulnerabilidades de redirección abierta en la web, incluidos sitios como Google e Instagram . [30] Las redirecciones abiertas tienen su propio identificador CWE, CWE-601. [31]

La redirección de URL también proporciona un mecanismo para realizar ataques de fuga de datos entre sitios . Al cronometrar el tiempo que tarda un sitio web en devolver una página en particular o al diferenciar una página de destino de otra, un atacante puede obtener información importante sobre el estado de otro sitio web. En 2021, Knittel et al. descubrieron una vulnerabilidad en la implementación de la API de rendimiento de Chrome que les permitió detectar de manera confiable las redirecciones de origen cruzado. [32]

Véase también

Referencias

  1. ^ ab "Google revive el espionaje de las redirecciones". Blog.anta.net . 29 de enero de 2009. ISSN  1797-1993. Archivado desde el original el 17 de agosto de 2011.
  2. ^ "Redirecciones y SEO: la guía total". Audisto . Consultado el 29 de noviembre de 2015 .
  3. ^ "Consejos de SEO: discusión sobre redirecciones 302". Matt Cutts, exdirector del equipo de spam web de Google. 4 de enero de 2006.
  4. ^ "Redirecciones furtivas". Google Inc. 3 de diciembre de 2015.
  5. ^ "Hoja de referencia sobre redireccionamientos y reenvíos no validados". Proyecto de seguridad de aplicaciones web abiertas (OWASP). 21 de agosto de 2014.
  6. ^ "Redirecciones y SEO: la guía completa". Audisto . Consultado el 29 de noviembre de 2015 .
  7. ^ "Redirecciones PHP: solución sólida y robusta para errores 302 a 301". WebSiteFactors.co.uk. Archivado desde el original el 12 de octubre de 2012.
  8. ^ Roy T. Fielding; Julian F. Reschke, eds. (2014). "Ubicación". Protocolo de transferencia de hipertexto (HTTP/1.1): semántica y contenido. IETF . pág. 68. sec. 7.1.2. doi : 10.17487/RFC7231 . RFC 7231.
  9. ^ Berners-Lee, Tim ; Fielding, Roy T. ; Masinter, Larry (2005). "Resolución de referencia". Identificador uniforme de recursos (URI): sintaxis genérica. IETF . pág. 28. sec. 5. doi : 10.17487/RFC3986 . RFC 3986.
  10. ^ "Módulo ngx_http_rewrite_module - reescritura". nginx.org . Consultado el 24 de diciembre de 2014 .
  11. ^ Murenin, Constantine A. (18 de febrero de 2013). "¿Un sitio web dinámico escrito completamente en nginx.conf? ¡Presentamos mdoc.su!". [email protected] (Lista de correo) . Consultado el 24 de diciembre de 2014 .
  12. ^ Murenin, Constantine A. (23 de febrero de 2013). «mdoc.su – Short manual page URLs for FreeBSD, OpenBSD, NetBSD and DragonFly BSD» (URL de páginas de manual cortas de FreeBSD, OpenBSD, NetBSD y DragonFly BSD) . Consultado el 25 de diciembre de 2014 .
  13. ^ Murenin, Constantine A. (23 de febrero de 2013). «mdoc.su.nginx.conf» . Consultado el 25 de diciembre de 2014 .
  14. ^ "Etiqueta meta HTML". www.w3schools.com .
  15. ^ "Una exploración de documentos dinámicos". 2 de agosto de 2002. Archivado desde el original el 2 de agosto de 2002.{{cite web}}: CS1 maint: bot: estado de URL original desconocido ( enlace )
  16. ^ "Google y Yahoo aceptan actualizaciones de metadatos sin demora como redirecciones 301". Sebastian's Pamphlets. 3 de septiembre de 2007.
  17. ^ "Pautas de Accesibilidad al Contenido Web 1.0". www.w3.org .
  18. ^ Equipo de control de calidad. "Utilice redirecciones estándar". www.w3.org .
  19. ^ "Técnicas básicas para las pautas de accesibilidad al contenido web 1.0". www.w3.org .
  20. ^ "Generador de redireccionamiento de URL del lado del cliente entre navegadores". Insider Zone. Archivado desde el original el 26 de julio de 2020. Consultado el 27 de agosto de 2015 .
  21. ^ Aaron Emigh (19 de enero de 2005). "Tecnología antiphishing" Archivado el 27 de septiembre de 2007 en Wayback Machine (PDF). Radix Labs.
  22. ^ "HTML 5.2: 11. Características obsoletas". www.w3.org .
  23. ^ Schwartz, Barry (18 de diciembre de 2007). "Google podría tardar más en detectar las redirecciones dobles". Search Engine Roundtable . Consultado el 28 de enero de 2024 .
  24. ^ Roy T. Fielding ; Julian F. Reschke, eds. (2014). "Redirección 3xx". Protocolo de transferencia de hipertexto (HTTP/1.1): semántica y contenido. IETF . pág. 54. sec. 6.4. doi : 10.17487/RFC7231 . RFC 7231.
  25. ^ "Ganancias netas para una pequeña nación del Pacífico". BBC News . 14 de septiembre de 2007. Archivado desde el original el 12 de mayo de 2014 . Consultado el 27 de mayo de 2010 .
  26. ^ ab Innocenti, Tommaso; Golinelli, Matteo; Onarlioglu, Kaan; Mirheidari, Ali; Crispo, Bruno; Kirda, Engin (4 de diciembre de 2023). "OAuth 2.0 Redirect URI Validation Falls Short, Literally" (La validación de URL de redireccionamiento de OAuth 2.0 se queda corta, literalmente). Conferencia anual sobre aplicaciones de seguridad informática . ACSAC '23. Nueva York, NY, EE. UU.: Association for Computing Machinery. págs. 256–267. doi :10.1145/3627106.3627140. hdl : 11572/399070 . ISBN . 979-8-4007-0886-2.
  27. ^ "Redireccionamiento abierto". OWASP. 16 de marzo de 2014. Consultado el 21 de diciembre de 2014 .
  28. ^ "Redireccionamiento encubierto". Tetraph. 1 de mayo de 2014. Consultado el 21 de diciembre de 2014 .
  29. ^ "Se descubre una falla de seguridad grave en OAuth y OpenID". CNET. 2 de mayo de 2014. Consultado el 21 de diciembre de 2014 .
  30. ^ Mike Williams (5 de junio de 2022). "¿Qué es una vulnerabilidad de redirección abierta, por qué es peligrosa y cómo puede mantenerse a salvo?". TechRadar . Consultado el 8 de abril de 2024 .
  31. ^ "CWE - CWE-601: Redirección de URL a un sitio no confiable ("Redirección abierta") (4.14)". cwe.mitre.org . Consultado el 8 de abril de 2024 .
  32. ^ Knittel, Lukas; Mainka, Christian; Niemietz, Marcus; Noß, Dominik Trevor; Schwenk, Jörg (13 de noviembre de 2021). "XSinator.com: de un modelo formal a la evaluación automática de fugas entre sitios en navegadores web". Actas de la Conferencia ACM SIGSAC de 2021 sobre seguridad informática y de las comunicaciones . CCS '21. Nueva York, NY, EE. UU.: Association for Computing Machinery. págs. 1771–1788. doi :10.1145/3460120.3484739. ISBN 978-1-4503-8454-4.

Enlaces externos