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 para hacer 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 el reenvío de dominio es cuando todas las páginas de un dominio URL se redireccionan a un dominio diferente, como cuando wikipedia.com y wikipedia.net se redireccionan automáticamente a wikipedia.org.

La redirección de URL se realiza por varias razones:

Por Acortador de URL;
Para evitar enlaces rotos cuando se mueven páginas web;
Permitir que varios nombres de dominio pertenecientes al mismo propietario hagan referencia a un único sitio web;
Para guiar la navegación dentro y fuera de un sitio web;
Para la protección de la privacidad; y
Con fines hostiles, como ataques de phishing o distribución de malware.

Propósitos

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

Nombres de dominio similares

Un usuario puede escribir mal una URL, por ejemplo, "ejemplo.com" y "ejemplo.com". Las organizaciones a menudo registran estos dominios "mal escritos" y los redirigen a la ubicación "correcta": ejemplo.com. Las direcciones ejemplo.com y ejemplo.net podrían redirigir a un solo dominio o página web, como ejemplo.org. Esta técnica se utiliza a menudo para "reservar" otros dominios de nivel superior (DNS) con el mismo nombre, o facilitar que un verdadero ".edu" o ".net" redirija a un dominio ".com" más reconocible.

Mover páginas a un nuevo dominio

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

Un sitio puede desear, o necesitar, cambiar su nombre de dominio;
Un autor puede mover sus páginas individuales a un nuevo dominio;
Dos sitios web pueden fusionarse.

Con las redirecciones de URL, los enlaces entrantes a una URL obsoleta se pueden enviar a la ubicación correcta. Estos enlaces pueden ser 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 un redireccionamiento "movido permanentemente" a la nueva URL, los visitantes seguirán llegando a 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 de dónde vinieron los visitantes y cómo navegaron por el sitio alojado. Sin embargo, no registran qué enlaces dejaron los visitantes. Esto se debe a que el navegador del visitante no necesita comunicarse con el servidor original cuando el visitante hace clic en un enlace saliente. Esta información se puede capturar de varias formas. Una forma implica la redirección de URL. En lugar de enviar al visitante directamente al otro sitio, los enlaces en el sitio pueden dirigir a una URL en el dominio del sitio web original que redirige automáticamente al objetivo real. Esta técnica tiene la desventaja del retraso causado por la solicitud adicional al servidor del sitio web original. Como esta solicitud adicional dejará un rastro en el registro del servidor, revelando 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 está afiliado a la corporación. En tales escenarios, mostrar la advertencia provoca un retraso adicional.

Alias cortos para URL largas

Artículo principal: Acortador de URL

Las aplicaciones web a menudo incluyen atributos descriptivos extensos en sus URL que representan jerarquías de datos, estructuras de comando, 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 a un usuario a una URL más larga desde una más corta.

Alias significativos y persistentes para URL largas o cambiantes

Véanse también: Enlace permanente, Localizador persistente uniforme para recursos y Enlace roto.

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

Publicar/Redirigir/Obtener

Publicar/Redirigir/Obtener (PRO) 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 de actualización después de enviar el formulario, creando una interfaz más intuitiva para los agentes de usuario (usuarios).

Orientación por dispositivo y orientación geográfica

Los redireccionamientos se pueden utilizar de forma eficaz con 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 de dispositivos móviles: hacer que el sitio web sea receptivo o redirigir a una versión de sitio web para dispositivos móviles. Si se ofrece una versión del sitio web móvil, los usuarios con clientes móviles serán automáticamente redirigidos al contenido móvil correspondiente. Para la segmentación por dispositivo, se utilizan redireccionamientos del lado del cliente o redireccionamientos del lado del servidor que no se pueden almacenar en caché. La segmentación geográfica es el enfoque para ofrecer contenido localizado y reenviar automáticamente al usuario a una versión localizada de la URL solicitada. Esto es útil para los sitios web que se dirigen al público en más de una ubicación y/o idioma. Por lo general, los redireccionamientos del lado del servidor se utilizan para la segmentación geográfica, pero los redireccionamientos del lado del cliente también pueden ser una opción, según los requisitos.^[2]

Manipular motores de búsqueda

Los redireccionamientos se han utilizado para manipular motores de búsqueda con intenciones poco éticas, por ejemplo, secuestro de URL. El objetivo de las redirecciones engañosas es dirigir el tráfico de búsqueda a las páginas de destino, que no tienen suficiente poder de clasificación por sí mismas o que solo están relacionadas de forma remota o no están relacionadas con el objetivo de búsqueda. El enfoque requiere una clasificación para un rango de términos de búsqueda con una serie de URL que utilizarían redireccionamientos furtivos para reenviar al buscador a la página de destino. Este método tuvo un renacimiento con el auge de los dispositivos móviles y la orientación por dispositivo. El secuestro de URL es una técnica de redireccionamiento fuera del dominio^[3] que explota la naturaleza del manejo del motor de búsqueda para redireccionamientos temporales. Si se encuentra un redireccionamiento temporal, los motores de búsqueda tienen que decidir si asignan el valor de clasificación a la URL que inicializa el redireccionamiento oa la URL de destino del redireccionamiento. La URL que inicia el redireccionamiento puede mantenerse para mostrarse en los resultados de búsqueda, ya que el redireccionamiento indica una naturaleza temporal. En determinadas circunstancias, fue posible explotar este comportamiento aplicando redireccionamientos temporales a URL bien posicionadas, lo que llevó a un reemplazo de la URL original en los resultados de búsqueda por la URL que inicializó la redirección, "robando" la clasificación. Este método generalmente se combinaba con redireccionamientos furtivos para redirigir el flujo de usuarios de 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 severas sanciones de clasificación en los sitios que son atrapados aplicando técnicas como estas.^[4]

Manipular visitantes

La redirección de URL se utiliza a veces como parte de los ataques de phishing que confunden a los visitantes sobre qué sitio web 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, los redireccionamientos también pueden llevarlo a sitios que de otra manera intentarán atacar 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 software antivirus e instale un troyano de algún tipo.

Eliminar información del Referer

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 completa con la URL de la página web actual y terminará en los registros del servidor que sirve el enlace externo. Dado que las páginas sensibles pueden tener URL sensibles (por ejemplo, http://company.com/plans-for-the-next-release-of-our-product), no es conveniente que la URL de referer abandone la organización. Una página de redirección que realiza la ocultación de referer podría estar incrustada en todas las URL externas, transformando, por ejemplo http://externalsite.com/page dentro http://redirect.company.com/http://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 phishing al indicar al usuario final que pasó una puerta de enlace clara a otro sitio.

Implementación

Varios tipos diferentes de respuesta al navegador resultarán en una redirección. Estos varían en cuanto a si afectan a las cabeceras HTTP o al contenido HTML. Las técnicas utilizadas normalmente dependen del rol de la persona que las implementa y su acceso a diferentes partes del sistema. Por ejemplo, un autor web sin control sobre los encabezados puede usar una metaetiqueta Actualizar, mientras que un administrador del servidor web que redirige todas las páginas de un sitio es más probable que use la configuración del servidor.

Redireccionamiento manual

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

Please follow <a href="http://www.example.com/">this link</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 un navegador muestre una página diferente. Si un cliente encuentra un redireccionamiento, debe tomar una serie de decisiones sobre cómo manejar el redireccionamiento. Los clientes utilizan diferentes 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 usar para la solicitud posterior.

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

300 opciones múltiples (por ejemplo, ofrecer diferentes idiomas)
301 movido permanentemente (redirige permanentemente de una URL a otra pasando la equidad del enlace a la página redirigida)
302 encontrado (originalmente "redireccionamiento temporal" en HTTP/1.0 y popularmente usado para scripts CGI; reemplazado por 303 y 307 en HTTP/1.1 pero preservado para compatibilidad con versiones anteriores)
303 ver otro (fuerza una solicitud GET a la nueva URL incluso si la solicitud original fue POST)
307 redireccionamiento temporal (proporciona una nueva URL para que el navegador vuelva a enviar una solicitud GET o POST)
308 redirección permanente (proporciona una nueva URL para que el navegador vuelva a enviar una solicitud GET o POST)

Redirigir códigos de estado y características

Código de Estado HTTP	Versión HTTP	Temporalmente / Permanentemente	Caché	Método de Solicitud Solicitud Posterior
301	HTTP/1.0	Permanentemente	Sí	GET/POST puede cambiar
302	HTTP/1.0	Temporalmente	No	GET/POST puede cambiar
303	HTTP/1.1	Temporalmente	No	Siempre GET
307	HTTP/1.1	Temporalmente	No	Puede que no cambie
308	HTTP/1.1	Permanentemente	Sí	Puede que no cambie

^[6]

Todos estos códigos de estado requieren que se proporcione la URL del destino de la redirección 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 la Ubicación: encabezado.

(Los códigos de estado 304 no modificados y 305 usan proxy no son redireccionamientos).

Ejemplo de respuesta HTTP para un redireccionamiento 301

Una respuesta HTTP con el redireccionamiento 301 "movido permanentemente" se ve así:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/
Content-Type: text/html
Content-Length: 174

<html>
<head>
<title>Moved</title>
</head>
<body>
<h1>Moved</h1>
<p>This page has moved to <a href="http://www.example.org/">http://www.example.org/</a>.</p>
</body>
</html>

Usar secuencias de comandos del lado del servidor para la redirección

Los autores web que producen contenido HTML generalmente no pueden crear redireccionamientos utilizando encabezados HTTP, ya que estos son generados automáticamente por el programa del servidor web cuando se entrega un archivo HTML. Lo mismo suele ser cierto incluso para 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 usar la función "encabezado":

header('HTTP/1.1 301 Moved Permanently');
header('Location: http://www.example.com/');
exit();

Es posible que se requieran más encabezados para evitar el almacenamiento en caché.^[7] El programador debe asegurarse de que los encabezados se emitan antes que el cuerpo. Es posible que esto no encaje 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 los datos del cuerpo. En el lenguaje de secuencias de comandos ASP, esto también se puede lograr utilizando response.buffer=true y response.redirect "http://www.example.com/" HTTP / 1.1 permite una referencia URI relativa o una referencia URI absoluta.^[8] Si la referencia de URI es relativa, el cliente calcula la referencia de URI absoluta requerida de acuerdo con las reglas definidas en RFC 3986.^[9]

Servidor HTTP Apache mod_rewrite

La extensión mod_alias del Servidor HTTP Apache se puede utilizar para redirigir determinadas solicitudes. Las directivas de configuración típicas se ven así:

Redirect permanent /oldpage.html http://www.example.com/newpage.html
Redirect 301 /oldpage.html http://www.example.com/newpage.html

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

RewriteEngine on
RewriteCond %{HTTP_HOST} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC]
RewriteRule ^(.*)$ http://newsite.example.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 oa un único directorio de contenido a través de un archivo .htaccess.

Nginx reescrito

Nginx tiene un módulo de reescritura 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 directiva de retorno). Un ejemplo que muestra el uso tan 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 nginx solamente.^[11]^[12]

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

	location /DragonFly {
		rewrite	^/DragonFly(BSD)?([,/].*)?$	/d$2	last;
	}
	location /d {
		set	$db	"http://leaf.dragonflybsd.org/cgi/web-man?command=";
		set	$ds	"&section=";
		rewrite	^/./([^/]+)\.([1-9])$		$db$1$ds$2	redirect;
	}

Actualizar metaetiqueta y encabezado de actualización HTTP

Netscape introdujo la función de actualización de meta que actualiza una página después de un cierto período de tiempo. Esto puede especificar una nueva URL para reemplazar una página por otra. Esto es compatible con la mayoría de los navegadores web.^[14]^[15] Un tiempo de espera de cero segundos produce una redirección inmediata. Google lo trata como un redireccionamiento permanente 301, lo que permite la transferencia de 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=http://www.example.com/" />
</head>
<body>
  <p>Please follow <a href="http://www.example.com/">this link</a>.</p>
</body>
</html>

Los autores web pueden utilizar esta técnica porque la metaetiqueta se encuentra dentro del propio documento. La metaetiqueta debe colocarse en la sección "encabezado" 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 "cuerpo" es para usuarios cuyos navegadores no admiten esta función.

El mismo efecto se puede lograr con un encabezado de refresh HTTP:

HTTP/1.1 200 OK
Refresh: 0; url=http://www.example.com/
Content-Type: text/html
Content-Length: 78

Please follow <a href="http://www.example.com/">this link</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 "Refresh: 0; url=http://www.example.com/\r\n";
print "Content-Type: text/html\r\n";
print "\r\n";
print "Please follow <a href=\"http://www.example.com/\">this link</a>!"

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

El W3C desaconseja el uso de la meta actualización, 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] desalientan la creación de páginas que se actualizan automáticamente, ya que la mayoría de los navegadores web no permiten que el usuario deshabilite o controle la frecuencia de actualización. Algunos de los artículos que han escrito sobre el tema incluyen las Pautas de Accesibilidad al Contenido Web del W3C (1.0): Garantice el Control del Usuario de los Cambios de Contenido Urgentes, Usar redireccionamientos estándar: ¡no rompa el botón de retroceso!^[18] y Técnicas Básicas para las Directrices de Accesibilidad al Contenido Web 1.0 Sección 7.^[19]

Redireccionamientos JavaScript

JavaScript puede causar una redirección configurando el atributo window.location, por ejemplo:

window.location='http://www.example.com/'

Normalmente, JavaScript inserta la URL del sitio redirector en el historial del navegador. Puede causar bucles de redirección cuando los usuarios presionan el botón Atrás. Con el siguiente comando puedes prevenir este tipo de comportamiento.^[20]

window.location.replace('http://www.example.com/')

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

Redirecciones de marcos

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

<iframe height="100%" width="100%" src="http://www.example.com/">
Please follow <a href="http://www.example.com/">link</a>.
</iframe>

Una diferencia principal con los métodos de redireccionamiento anteriores es que para un redireccionamiento de marco, el navegador muestra la URL del documento del marco y no la URL de la página de destino en la barra de URL. Esta técnica de encubrimiento puede usarse para que el lector vea una URL más memorable o para ocultar de manera fraudulenta un sitio de phishing como parte de la suplantación de sitios web.^[21]

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

<frameset rows="100%">
  <frame src="http://www.example.com/">
  <noframes>
    <body>Please follow <a href="http://www.example.com/">link</a>.</body>
  </noframes>
</frameset>

Cadenas de redireccionamiento

Un redireccionamiento puede llevar a otro. Por ejemplo, la URL "http://wikipedia.com" (con "* .com" como dominio) se redirige primero a https://www.wikipedia.org/ (con el nombre de dominio en .org), donde puede navegue hasta el sitio específico del idioma. Esto es inevitable si los diferentes enlaces de la cadena son atendidos 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.

Wikipedia ha redirigido sus páginas a HTTPS de forma predeterminada desde 2015.^[23]

Redirigir bucles

A veces, un error puede hacer que una página termine redirigiéndose a sí misma, posiblemente a través de otras páginas, dando lugar a una secuencia infinita de redireccionamientos. Los navegadores deberían dejar de redireccionar después de una cierta 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 ser conscientes de que algunos clientes pueden implementar una limitación tan fija.

Servicios

Existen servicios que pueden realizar la redirección de URL bajo demanda, sin necesidad de trabajo técnico o acceso al servidor web en el que está alojado su sitio.

Servicios de redireccionamiento 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 memorable y una reducción en la longitud de la URL o dirección web. Un enlace de redireccionamiento también se puede utilizar como dirección permanente para el contenido que cambia de host con frecuencia, de manera similar al sistema de nombres de dominio. Los hipervínculos que incluyen 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 redirección de URL conocidos; sin embargo, esto también eliminará las ediciones y los comentarios legítimos y puede que no sea un método eficaz para reducir el spam. Recientemente, los servicios de redirección de URL han adoptado AJAX como un método eficaz y fácil de usar para crear URL abreviadas. Un gran inconveniente 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 (DNS) como ".to" (Tonga), ".at" (Austria) y ".is" (Islandia). Su objetivo era crear URL memorables. El primer servicio de redireccionamiento convencional fue V3.com, que contaba con 4 millones de usuarios en su punto máximo en 2000. El éxito de V3.com se atribuyó a tener una amplia variedad de dominios breves y 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 $70.00 por año a menos de $10.00, el uso de los servicios de redireccionamiento disminuyó. Con el lanzamiento de TinyURL en 2002, nació un nuevo tipo de servicio de redireccionamiento, el 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 extremadamente popular servicio de Twitter, estos servicios de URL cortos se han utilizado mucho.

Enmascaramiento de referente

Los servicios de redirección pueden ocultar la referencia colocando una página intermedia entre la página en la que se encuentra el enlace y su destino. Aunque estos son conceptualmente similares a otros servicios de redireccionamiento 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 de referencia y proporcionar una puerta de enlace clara entre otros sitios web. ) Este tipo de redireccionamiento se utiliza a menudo para evitar que los enlaces potencialmente maliciosos obtengan información utilizando la referencia, por ejemplo, un ID de sesión en la cadena de consulta. Muchos sitios web de grandes comunidades utilizan la redirección de enlaces en enlaces externos para disminuir 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 disminuir la posibilidad de un phishing efectivo.

Aquí hay un ejemplo simplista de dicho servicio, escrito en PHP.

<?php
$url = htmlspecialchars($_GET['url']);
header('Refresh: 0; url=https://' . $url);
?>
<!-- Fallback using meta refresh. -->
<html>
 <head>
  <title>Redirecting...</title>
  <meta http-equiv="refresh" content="0;url=https://<?= $url; ?>">
 </head>
 <body>
 Attempting to redirect to <a href="https://<?= $url; ?>">https://<?= $url; ?></a>.
 </body>
</html>

El ejemplo anterior no verifica quién lo llamó (por ejemplo, por referencia, aunque eso podría ser falsificado). Además, no comprueba la URL proporcionada. Esto significa que una persona malintencionada podría enlazar a la página de redireccionamiento utilizando un parámetro de URL de su propia selección, desde cualquier página, que utilice los recursos del servidor web.

Temas de seguridad

Los atacantes pueden abusar de la redirección de URL para ataques de phishing, como la redirección abierta y la redirección encubierta. "Una redirección abierta es una aplicación que toma un parámetro y redirige a un usuario al valor del parámetro sin ninguna validación".^[26] "La redirección encubierta es una aplicación que toma un parámetro y redirige a un usuario al valor del parámetro SIN SUFICIENTE validación".^[27] Fue revelado en mayo de 2014 por un estudiante de doctorado en matemáticas Wang Jing de la Universidad Tecnológica de Nanyang, Singapur.^[28]

Véase también

Referencias

↑ «Google revives redirect snoopery». Blog.anta.net. 29 de enero de 2009. ISSN 1797-1993. Archivado desde el original el 17 de agosto de 2011.
↑ «Redirects & SEO - The Total Guide». Audisto. Consultado el 29 de noviembre de 2015.
↑ «SEO advice: discussing 302 redirects». Matt Cutts, former Head of Google Webspam Team. 4 de enero de 2006.
↑ «Sneaky Redirects». Google Webmaster Guidelines. 3 de diciembre de 2015.
↑ «Unvalidated Redirects and Forwards Cheat Sheet». Open Web Application Security Project (OWASP). 21 de agosto de 2014.
↑ «Redirects & SEO - The Complete Guide». Audisto. Consultado el 29 de noviembre de 2015.
↑ «PHP Redirects: 302 to 301 Rock Solid Robust Solution». WebSiteFactors.co.uk. Archivado desde el original el 12 de octubre de 2012.
↑ «Location», Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, p. 68. sec. 7.1.2, doi:10.17487/RFC7231, RFC 7231 .
↑ «Reference Resolution», Uniform Resource Identifier (URI): Generic Syntax, p. 28. sec. 5, doi:10.17487/RFC3986, RFC 3986 .
↑ «Module ngx_http_rewrite_module - rewrite». nginx.org. Consultado el 24 de diciembre de 2014.
↑ Murenin, Constantine A. (2013-02-18), «A dynamic web-site written wholly in nginx.conf? Introducing mdoc.su!», lista de correo nginx@nginx.org, http://mailman.nginx.org/pipermail/nginx/2013-February/037592.html, consultado el 2014-12-24.
↑ Murenin, Constantine A. (23 de febrero de 2013). «mdoc.su – Short manual page URLs for FreeBSD, OpenBSD, NetBSD and DragonFly BSD». Consultado el 25 de diciembre de 2014.
↑ Murenin, Constantine A. (23 de febrero de 2013). «mdoc.su.nginx.conf». Consultado el 25 de diciembre de 2014.
↑ «HTML meta tag». www.w3schools.com.
↑ «An Exploration of Dynamic Documents». 2 de agosto de 2002. Archivado desde el original el 2 de agosto de 2002.
↑ "Google and Yahoo accept undelayed meta refreshs as 301 redirects". Sebastian's Pamphlets. 3 September 2007.
↑ «Web Content Accessibility Guidelines 1.0». www.w3.org.
↑ Team, the QA. «Use standard redirects». www.w3.org.
↑ «Core Techniques for Web Content Accessibility Guidelines 1.0». www.w3.org.
↑ «Cross-browser client side URL redirect generator». Insider Zone. Archivado desde el original el 26 de julio de 2020. Consultado el 8 de noviembre de 2020.
↑ Aaron Emigh (19 January 2005). "Anti-Phishing Technology" Archivado el 27 de septiembre de 2007 en Wayback Machine. (PDF). Radix Labs.
↑ «HTML 5.2: 11. Obsolete features». www.w3.org.
↑ Wikipedia to start using secure HTTPS by default for all users VentureBeat article, 12 June 2015
↑ «Redirection 3xx», Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, p. 54. sec. 6.4, doi:10.17487/RFC7231, RFC 7231 .
↑ «Net gains for tiny Pacific nation». BBC News. 14 de septiembre de 2007. Archivado desde el original el 12 de mayo de 2014. Consultado el 27 de mayo de 2010.
↑ «Open Redirect». OWASP. 16 de marzo de 2014. Consultado el 21 de diciembre de 2014.
↑ «Covert Redirect». Tetraph. 1 de mayo de 2014. Archivado desde el original el 10 de marzo de 2016. Consultado el 21 de diciembre de 2014.
↑ «Serious security flaw in OAuth, OpenID discovered». CNET. 2 de mayo de 2014. Consultado el 21 de diciembre de 2014.

Enlaces externos

Asignación de URL a Ubicaciones del Sistema de Archivos Archivado el 5 de agosto de 2020 en Wayback Machine.
Taxonomía del Spam de Redireccionamiento de JavaScript (Microsoft Live Labs)
Vulnerabilidades de Seguridad en Redirectores de URL Clasificación de Amenazas del Consorcio de Seguridad de Aplicaciones Web

Datos: Q1236807

[:0-1] «Google revives redirect snoopery». Blog.anta.net. 29 de enero de 2009. ISSN 1797-1993. Archivado desde el original el 17 de agosto de 2011.

[2] «Redirects & SEO - The Total Guide». Audisto. Consultado el 29 de noviembre de 2015.

[3] «SEO advice: discussing 302 redirects». Matt Cutts, former Head of Google Webspam Team. 4 de enero de 2006.

[4] «Sneaky Redirects». Google Webmaster Guidelines. 3 de diciembre de 2015.

[5] «Unvalidated Redirects and Forwards Cheat Sheet». Open Web Application Security Project (OWASP). 21 de agosto de 2014.

[6] «Redirects & SEO - The Complete Guide». Audisto. Consultado el 29 de noviembre de 2015.

[php-301-robust-solution-7] «PHP Redirects: 302 to 301 Rock Solid Robust Solution». WebSiteFactors.co.uk. Archivado desde el original el 12 de octubre de 2012.

[8] «Location», Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, p. 68. sec. 7.1.2, doi:10.17487/RFC7231, RFC 7231 .

[9] «Reference Resolution», Uniform Resource Identifier (URI): Generic Syntax, p. 28. sec. 5, doi:10.17487/RFC3986, RFC 3986 .

[10] «Module ngx_http_rewrite_module - rewrite». nginx.org. Consultado el 24 de diciembre de 2014.

[11] Murenin, Constantine A. (2013-02-18), «A dynamic web-site written wholly in nginx.conf? Introducing mdoc.su!», lista de correo nginx@nginx.org, http://mailman.nginx.org/pipermail/nginx/2013-February/037592.html, consultado el 2014-12-24.

[12] Murenin, Constantine A. (23 de febrero de 2013). «mdoc.su – Short manual page URLs for FreeBSD, OpenBSD, NetBSD and 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] «HTML meta tag». www.w3schools.com.

[15] «An Exploration of Dynamic Documents». 2 de agosto de 2002. Archivado desde el original el 2 de agosto de 2002.

[16] "Google and Yahoo accept undelayed meta refreshs as 301 redirects". Sebastian's Pamphlets. 3 September 2007.

[17] «Web Content Accessibility Guidelines 1.0». www.w3.org.

[18] Team, the QA. «Use standard redirects». www.w3.org.

[19] «Core Techniques for Web Content Accessibility Guidelines 1.0». www.w3.org.

[20] «Cross-browser client side URL redirect generator». Insider Zone. Archivado desde el original el 26 de julio de 2020. Consultado el 8 de noviembre de 2020.

[21] Aaron Emigh (19 January 2005). "Anti-Phishing Technology" Archivado el 27 de septiembre de 2007 en Wayback Machine. (PDF). Radix Labs.

[22] «HTML 5.2: 11. Obsolete features». www.w3.org.

[23] Wikipedia to start using secure HTTPS by default for all users VentureBeat article, 12 June 2015

[rfc7231sec6.4-24] «Redirection 3xx», Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, p. 54. sec. 6.4, doi:10.17487/RFC7231, RFC 7231 .

[25] «Net gains for tiny Pacific nation». BBC News. 14 de septiembre de 2007. Archivado desde el original el 12 de mayo de 2014. Consultado el 27 de mayo de 2010.

[Open_Redirect-26] «Open Redirect». OWASP. 16 de marzo de 2014. Consultado el 21 de diciembre de 2014.

[Covert_Redirect-27] «Covert Redirect». Tetraph. 1 de mayo de 2014. Archivado desde el original el 10 de marzo de 2016. Consultado el 21 de diciembre de 2014.

[CNET-28] «Serious security flaw in OAuth, OpenID discovered». CNET. 2 de mayo de 2014. Consultado el 21 de diciembre de 2014.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]