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 bajo más de una dirección URL . Cuando un navegador intenta abrir una URL que ha sido redirigida, se abre una página con una URL diferente. De manera similar, la redirección o reenvío de dominio se produce 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 diversas razones:
- para acortar URL ;
- para evitar enlaces rotos cuando se mueven las páginas web;
- para 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 (como redirigir los enlaces de YouTube y Twitter a Invidious y Nitter respectivamente o convertir los enlaces AMP en enlaces normales); y
- con fines hostiles, como ataques de phishing o distribución de malware.
Propósitos
Existen varias razones para utilizar la redirección de URL:
Forzar HTTPS
Un sitio web puede ser potencialmente accesible tanto a través de un esquema URI HTTPS seguro como mediante HTTP simple (un URI no seguro que comienza con "http://").
Si un usuario introduce una URI o hace clic en un enlace que hace referencia a la variante no segura, el navegador lo redirigirá automáticamente a la versión segura si el sitio web está incluido en la lista de precarga HSTS que se incluye con la aplicación o si el usuario ya ha visitado el origen anteriormente.
De lo contrario, se contactará con el sitio web mediante HTTP. El operador del sitio web puede optar por atender dichas solicitudes redirigiendo el navegador a la variante HTTPS y, con suerte, preparando así HSTS para futuros accesos.
Nombres de dominio similares
Un usuario podría escribir mal una URL. Las organizaciones suelen registrar estos dominios con errores ortográficos y redirigirlos a la ubicación correcta. Esta técnica se usa a menudo para "reservar" otros dominios de nivel superior (TLD) con el mismo nombre, o para facilitar que un sitio ".edu" o ".net" sea accesible para usuarios que escriben ".com".
Trasladar páginas a un nuevo dominio.
Las páginas web pueden ser redirigidas a un nuevo dominio por tres razones:
- Un sitio web podría desear o necesitar cambiar su nombre de dominio;
- Un autor podría trasladar sus páginas individuales a un nuevo dominio;
- Dos sitios web podrían fusionarse.
Con las redirecciones de URL, los enlaces entrantes a una URL obsoleta se pueden redirigir a la ubicación correcta. Estos enlaces pueden provenir de otros sitios que no se han percatado del cambio o de marcadores/favoritos que los usuarios han guardado en sus navegadores. Lo mismo ocurre con los motores de búsqueda . A menudo, almacenan los nombres de dominio y enlaces antiguos en su base de datos y redirigen a los usuarios a estas URL antiguas. Al usar una redirección permanente a la nueva URL, los visitantes seguirán llegando a la página correcta. Además, en la siguiente búsqueda, el motor de búsqueda debería detectar y utilizar la URL más reciente.
Registrando los enlaces salientes
Los registros de acceso de la mayoría de los servidores web guardan información detallada sobre la procedencia de los visitantes y cómo navegaron por el sitio alojado. Sin embargo, no registran los enlaces que los visitantes dejaron. 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 maneras. 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 del retraso causado por la solicitud adicional al servidor del sitio web original. Dado que esta solicitud adicional deja 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 subsiguiente se encuentra en otro sitio y, por lo tanto, no necesariamente está afiliado a la corporación. En tales casos, mostrar la advertencia causa un retraso adicional.
Alias cortos para URL largas
Las aplicaciones web suelen incluir atributos descriptivos extensos en sus URL, 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 estéticamente desagradable y difícil de recordar, que puede no ajustarse a las limitaciones de tamaño de los sitios de microblogging . Los servicios de acortamiento de URL ofrecen una solución a este problema redirigiendo 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 permanezca igual. Por lo tanto, la redirección de URL puede ser útil para los usuarios que tienen marcadores. Esto se hace habitualmente en Wikipedia cada vez que se cambia el nombre de una página.
Post/Redirigir/Obtener
El patrón de diseño de desarrollo web Post/Redirect/Get (PRG) evita el envío duplicado de formularios si el usuario hace clic en el botón de actualizar después de enviar el formulario, creando una interfaz más intuitiva para los agentes de usuario (usuarios).
Segmentación de dispositivos y geolocalización
Las redirecciones pueden utilizarse eficazmente para fines de segmentación, como la geolocalización . La segmentación por dispositivo se ha vuelto cada vez más importante con el auge de los clientes móviles. Existen dos enfoques para atender a los usuarios móviles: hacer que el sitio web sea adaptable o redirigir a una versión móvil del sitio web. Si se ofrece una versión móvil del sitio web, 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 geolocalización es el enfoque para ofrecer contenido localizado y redirigir automáticamente al usuario a una versión localizada de la URL solicitada. Esto es útil para sitios web que se dirigen a audiencias en más de una ubicación y/o idioma. Por lo general, se utilizan redirecciones del lado del servidor para la geolocalización, 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 posicionamiento por sí solas o que solo están remotamente relacionadas o no tienen ninguna relación con el objetivo de búsqueda. El enfoque requiere un posicionamiento para un rango de términos de búsqueda con varias URL que utilizarían redirecciones engañosas para dirigir al usuario a la página de destino. Este método resurgió con el auge de los dispositivos móviles y la segmentación por dispositivo. El secuestro de URL es una técnica de redirección fuera del dominio [ 3 ] que explota la naturaleza del manejo de las redirecciones temporales por parte del motor de búsqueda. Si se encuentra una redirección temporal, los motores de búsqueda deben decidir si asignan el valor de posicionamiento a la URL que inicia la redirección o a la URL de destino de la redirección. La URL que inicia la redirección puede mantenerse para aparecer en los resultados de búsqueda, ya que la redirección indica un carácter temporal. En determinadas circunstancias, era posible explotar este comportamiento aplicando redirecciones temporales a URL con buen posicionamiento, lo que provocaba que la URL original en los resultados de búsqueda fuera reemplazada por la URL que inició la redirección, "robando" así el posicionamiento. Este método solía combinarse con redirecciones engañosas 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 eficaces para detectar este tipo de prácticas manipuladoras. Los principales motores de búsqueda suelen aplicar severas penalizaciones de posicionamiento a los sitios que son descubiertos utilizando técnicas como estas. [ 4 ]
Manipular 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 ] Dado 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 intentarán atacarte de otras maneras. 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 algún tipo de troyano .
Eliminar referrerinformación
Cuando se hace clic en un enlace, el navegador envía en la solicitud HTTP un campo llamado referer que indica el origen del enlace. Este campo se rellena con la URL de la página web actual y se registra en los archivos de registro del servidor que sirve el enlace externo. Dado que las páginas sensibles pueden tener URL sensibles (por ejemplo, https://company.com/plans-for-the-next-release-of-our-product), no es conveniente que la referrerURL salga de la organización. Se podría insertar una página de redirección que oculte el refererhttps://externalsite.com/page en todas las URL externas, transformándola, por ejemplo, en https://redirect.company.com/https://externalsite.com/page. Esta técnica también elimina otra información potencialmente sensible de la URL referer, como el ID de sesión , y puede reducir la probabilidad de phishing al indicar al usuario final que ha accedido a otro sitio web sin problemas.
Implementación
Diversas respuestas al navegador pueden provocar una redirección. Estas varían en cuanto a si afectan a las cabeceras HTTP o al contenido HTML. Las técnicas utilizadas suelen depender del rol de la persona que las implementa y de su acceso a las distintas partes del sistema. Por ejemplo, un autor web sin control sobre las cabeceras podría usar la etiqueta meta Refresh, mientras que un administrador de servidor web que redirige todas las páginas de un sitio probablemente utilice la configuración del servidor.
Redireccionamiento manual
La técnica más sencilla consiste en pedir al visitante que siga un enlace a la nueva página, normalmente utilizando un ancla HTML como esta:
Por favor , siga este enlace : <a href="https://www.uba8d1406.com/"> . Este método se suele utilizar como alternativa : si el navegador no admite la redirección automática, el visitante aún puede acceder 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 provoca que el navegador muestre una página diferente. Si un cliente encuentra una redirección, debe tomar varias decisiones sobre cómo gestionarla. Los clientes utilizan diferentes códigos de estado para comprender el propósito de la redirección, cómo gestionar el almacenamiento en caché y qué método de solicitud utilizar para la siguiente solicitud.
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, transfiriendo el valor del enlace a la página redirigida).
- 302 encontrado (originalmente "redirección temporal" en HTTP/1.0 y popularmente utilizado para scripts CGI; reemplazado por 303 y 307 en HTTP/1.1 pero conservado por compatibilidad con versiones anteriores)
- 303 ver otros (fuerza una solicitud GET a la nueva URL incluso si la solicitud original fue POST)
- 305 use proxy (indica que el recurso solicitado por el cliente solo está disponible a través de un proxy)
- Redirección temporal 307 (proporciona una nueva URL para que el navegador vuelva a enviar una solicitud GET o POST).
- Redirección permanente 308 (proporciona una nueva URL para que el navegador vuelva a enviar una solicitud GET o POST).
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 especifique en el encabezado "Location:" de la respuesta HTTP. Las opciones múltiples 300 generalmente muestran todas las opciones en el cuerpo del mensaje y la opción predeterminada en el encabezado "Location:".
Ejemplo de respuesta HTTP para una redirección 301
Una respuesta HTTP con la redirección 301 "movido permanentemente" tiene este aspecto:
HTTP / 1.1 301 Moved Permanently Ubicación : https://www.example.org/ Tipo de contenido : texto/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 la redirección
Los autores web que generan contenido HTML generalmente no pueden crear redirecciones usando encabezados HTTP, ya que estos son generados automáticamente por el programa del servidor web al servir un archivo HTML. Lo mismo suele ocurrir con los programadores que escriben scripts CGI, aunque algunos servidores permiten que los scripts agreguen encabezados personalizados (por ejemplo, habilitando "non-parsed-headers"). Muchos servidores web generarán un código de estado 3xx si un script genera una línea de encabezado "Location:". Por ejemplo, en PHP , se puede usar la función "header":
encabezado ( 'HTTP/1.1 301 Moved Permanently' ); encabezado ( 'Location: https://www.example.com/' ); salir ();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 de control natural 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 usando response.buffer=truey 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 ]response.redirect "https://www.example.com/"
Apache HTTP Server mod_rewrite
La extensión mod_alias del servidor HTTP Apache se puede utilizar para redirigir ciertas 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} ^([^.:]+\.)*oldsite\.example\.com\.?(:[0-9]*)?$ [NC] RewriteRule ^(.*)$ https://newsite.example.net/$1 [R=301,L] Dicha configuración se puede aplicar a uno o a todos los sitios del servidor a través de los archivos de configuración del servidor o a un único directorio de contenido a través de un .htaccessarchivo.
reescritura de nginx
Nginx cuenta con un módulo de reescritura HTTP integrado, [ 10 ] que permite realizar un procesamiento avanzado de URL e incluso generar 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 utilizando únicamente el lenguaje de configuración de Nginx. [ 11 ] [ 12 ]
/DragonFlyBSD/HAMMER.5Por ejemplo, si llegara una solicitud , primero se redirigiría internamente a /d/HAMMER.5con la primera directiva de reescritura a continuación (solo afecta al estado interno, sin emitir aún ninguna respuesta HTTP al cliente), 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 redirigirlo realmente al script cgi externo de web- man : [ 13 ]
location /DragonFly { rewrite ^/DragonFly(BSD)?([,/].*)? $ /d $2 last ; } location /d { set $db "https://leaf.dragonflybsd.org/cgi/web-man?command=" ; set $ds "§ion=" ; rewrite ^/./([^/]+)\.([1-9]) $ $db$1$ds$2 redirect ; }Actualizar la etiqueta Meta y el encabezado de actualización HTTP
Netscape introdujo la función de meta actualización , que actualiza una página después de un cierto tiempo. Esto permite especificar una nueva URL para reemplazar una página con otra. La mayoría de los navegadores web lo admiten. [ 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 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 = https : //www.example.com/ " / > </head> <body> <p> Por favor , siga <a href="https://www.example.com/"> este enlace </a> . </p> </body> </html>Esta técnica puede ser utilizada por los desarrolladores web, ya que la etiqueta meta se encuentra 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 sustituirse por otro número para lograr un retardo de esa cantidad de segundos. El enlace en la sección "body" está destinado a usuarios cuyos navegadores no admiten esta función.
El mismo efecto se puede lograr con una refreshcabecera HTTP:
HTTP / 1.1 200 OK Actualizar : 0; url=https://www.example.com/ Content-Type : text/html Content-Length : 78Por favor , siga este enlace : <a href="https://www.example.com/"> . </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í tienes un sencillo programa CGI que realiza esta redirección:
# !/usr/bin/env perl print "Refresh: 0; url=https://www.example.com/\r\n" ; print "Content-Type: text/html\r\n" ; print "\r\n" ; print "Please follow <a href=\"https://www.example.com/\">this link</a>!"Nota: Normalmente, el servidor HTTP añade automáticamente la línea de estado y el encabezado Content-Length.
El W3C desaconseja el uso de meta refresh, ya que no comunica ninguna información sobre el recurso original o el nuevo al navegador (o al motor de búsqueda ). Las Pautas de Accesibilidad al Contenido Web (7.4) del W3C [ 17 ] desaconsejan la creación de páginas con actualización automática, puesto 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 publicado sobre el tema incluyen: Pautas de Accesibilidad al Contenido Web (1.0) del W3C: Garantizar el control del usuario sobre los cambios de contenido sensibles al tiempo , Usar redirecciones estándar: ¡no estropear 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 al establecer el window.locationatributo, por ejemplo:
ventana.ubicación = ' https://www.example.com/ 'Normalmente, JavaScript añade la URL del sitio de redireccionamiento al historial del navegador. Esto puede provocar bucles de redireccionamiento cuando los usuarios pulsan el botón de retroceso. Con el siguiente comando se puede evitar este comportamiento. [ 20 ]
ventana.ubicación.reemplazar ( ' https://www.example.com/ ' )Sin embargo, por razones de seguridad y porque algunos navegadores y muchos rastreadores web no ejecutan JavaScript , se pueden preferir las cabeceras HTTP o la etiqueta meta refresh.
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/ " > Por favor , siga el <a href="https://www.example.com/"> enlace </a> . </iframe>Una diferencia principal con respecto a 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 del marco y no la URL de la página de destino en la barra de direcciones. Esta técnica de enmascaramiento puede utilizarse 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 web . [ 21 ]
Antes de HTML5, [ 22 ] se podía lograr el mismo efecto con un marco HTML que contuviera la página de destino:
< frameset rows = " 100 % " > < frame src = " https://www.example.com/ " > <noframes> <body> Por favor , siga el <a href="https://www.example.com/"> enlace </a> . </body> </noframes> </frameset>Cadenas de redireccionamiento
Una redirección puede llevar a otra en una cadena de redirecciones. Si una redirección lleva a otra, también se conoce como redirección doble. [ 23 ] Por ejemplo, la URL " https://wikipedia.com " (con "*.com" como dominio) se redirige primero a https://www.wikipedia.org/ (con el nombre de dominio en .org ), donde se puede navegar al sitio específico del idioma. Esto es inevitable si los diferentes enlaces de la cadena son servidos por diferentes servidores, aunque debería minimizarse reescribiendo la URL lo máximo posible en el servidor antes de devolverla al navegador como una redirección.
Bucles de redirección
En ocasiones, un error puede provocar que una página se redirija a sí misma, posiblemente a través de otras páginas, lo que genera una secuencia infinita de redirecciones. Los navegadores deberían dejar de redireccionar tras un cierto número de saltos y mostrar un mensaje de error.
El estándar HTTP/1.1 establece: [ 24 ]
Un cliente DEBERÍA detectar e intervenir en las 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 esta limitación fija.
Servicios
Existen servicios que permiten realizar redirecciones de URL bajo demanda, sin necesidad de conocimientos técnicos ni acceso al servidor web donde 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 la reducción de la longitud de la URL o dirección web. Un enlace de redireccionamiento también puede usarse como una dirección permanente para contenido que cambia de servidor con frecuencia, de forma similar al Sistema de Nombres de Dominio (DNS) . Los hipervínculos que involucran servicios de redireccionamiento de URL se usan frecuentemente 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 usar 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 retardo 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 masivo fue V3.com, que llegó a tener 4 millones de usuarios en su apogeo en 2000. El éxito de V3.com se atribuyó a tener una amplia variedad de dominios cortos y memorables, incluidos "r.im", "go.to", "i.am", "come.to" y "start.at". V3.com fue adquirido 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 los servicios de redireccionamiento disminuyó. Con el lanzamiento de TinyURL en 2002 nació un nuevo tipo de servicio de redireccionamiento, a saber, 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 del popularísimo servicio Twitter , estos servicios de URL cortas se han utilizado ampliamente.
Enmascaramiento del remitente
Los servicios de redirección pueden ocultar el referente colocando una página intermedia entre la página donde se encuentra el enlace y su destino. Aunque conceptualmente son similares a otros servicios de redirección de URL, cumplen una función 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 usa a menudo para evitar que 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 grandes usan la redirección de enlaces en enlaces externos para disminuir la posibilidad de una vulnerabilidad que podría usarse para robar información de cuentas, así como para dejar claro cuándo un usuario está abandonando un servicio, para disminuir la posibilidad de phishing efectivo .
Aquí tenéis un ejemplo sencillo de dicho servicio, escrito en PHP .
<?php $url = htmlspecialchars ( $_GET [ 'url' ]); header ( 'Refresh: 0; url=https://' . $url ); ?> <!-- Fallback using meta refresh. --> < 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 verifica quién realizó la llamada (por ejemplo, mediante el referente, aunque esto podría falsificarse). Tampoco verifica la URL proporcionada. Esto significa que una persona malintencionada podría enlazar a la página de redirección utilizando un parámetro de URL de su elección, desde cualquier página que utilice los recursos del servidor web.
Problemas de seguridad
La redirección de URL puede ser aprovechada por atacantes para realizar ataques de phishing . Si una aplicación web no valida suficientemente el destino de la redirección, un atacante puede hacer que la aplicación redirija a un sitio web arbitrario. Esta vulnerabilidad se conoce como vulnerabilidad de redirección abierta. [ 26 ] [ 27 ] En ciertos casos, cuando una redirección abierta ocurre como parte de un flujo de autenticación , la vulnerabilidad se conoce como redirección encubierta. [ 28 ] [ 29 ] Cuando ocurre 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, incluyendo 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 información entre sitios . Al medir el tiempo que tarda un sitio web en devolver una página específica o al diferenciar una página de destino de otra, un atacante puede obtener información significativa 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 forma fiable las redirecciones entre orígenes. [ 32 ]
Véase también
Referencias
- 1 2 "Google revive el espionaje de redirecciones" . Blog.anta.net . 29 de enero de 2009. ISSN 1797-1993 . Archivado del original el 17 de agosto de 2011.
- ^ "Redirecciones y SEO: la guía total" . Audisto . Consultado el 29 de noviembre de 2015 .
- ↑ "Consejos de SEO: análisis de las redirecciones 302" . Matt Cutts, exjefe del equipo de lucha contra el spam web de Google. 4 de enero de 2006.
- ↑ "Redirecciones engañosas" . Google Inc. 3 de diciembre de 2015.
- ↑ "Guía rápida sobre redirecciones y reenvíos no validados" . Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP). 21 de agosto de 2014.
- ↑ "Redirecciones y SEO: la guía completa" . Audisto . Consultado el 29 de noviembre de 2015 .
- ↑ "Redirecciones PHP: Solución sólida y fiable de 302 a 301" . WebSiteFactors.co.uk. Archivado del original el 12 de octubre de 2012.
- ↑ Roy T. Fielding; Julian F. Reschke, eds. (2014). "Location" . Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content . IETF . p. 68. sec. 7.1.2. doi : 10.17487/RFC7231 . RFC 7231 .
- ↑ Berners-Lee, Tim ; Fielding, Roy T .; Masinter, Larry (2005). "Resolución de referencias" . Identificador uniforme de recursos (URI): sintaxis genérica . IETF . pág. 28. sec. 5. doi : 10.17487/RFC3986 . RFC 3986 .
- ↑ "Módulo ngx_http_rewrite_module - reescritura" . nginx.org . Consultado el 24 de diciembre de 2014 .
- ↑ Murenin, Constantine A. (18 de febrero de 2013). "¿Un sitio web dinámico escrito completamente en nginx.conf? ¡Presentamos mdoc.su!" . nginx@nginx.org (Lista de correo) . Recuperado el 24 de diciembre de 2014 .
- ↑ Murenin, Constantine A. (23 de febrero de 2013). "mdoc.su – URLs cortas de páginas de manual para FreeBSD, OpenBSD, NetBSD y DragonFly BSD" . Recuperado el 25 de diciembre de 2014 .
- ↑ Murenin, Constantine A. (23 de febrero de 2013). "mdoc.su.nginx.conf" . Recuperado el 25 de diciembre de 2014 .
- ↑ "Etiqueta meta HTML" . www.w3schools.com .
- ↑ "Una exploración de los documentos dinámicos" . 2 de agosto de 2002. Archivado del original el 2 de agosto de 2002.
{{cite web}}: CS1 maint: bot: estado de la URL original desconocido ( enlace ) - ↑ "Google y Yahoo aceptan las actualizaciones meta sin demora como redirecciones 301" . Folletos de Sebastián. 3 de septiembre de 2007.
- ↑ "Directrices de accesibilidad al contenido web 1.0" . www.w3.org .
- ↑ Equipo de control de calidad. "Utilice redirecciones estándar" . www.w3.org .
- ↑ "Técnicas básicas para las Pautas de Accesibilidad al Contenido Web 1.0" . www.w3.org .
- ↑ "Generador de redireccionamiento de URL del lado del cliente compatible con varios navegadores" . Insider Zone. Archivado del original el 26 de julio de 2020. Consultado el 27 de agosto de 2015 .
- ↑ Aaron Emigh (19 de enero de 2005). "Tecnología antiphishing". Archivado el 27 de septiembre de 2007 en Wayback Machine (PDF). Radix Labs.
- ↑ "HTML 5.2: 11. Características obsoletas" . www.w3.org .
- ↑ 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 .
- ↑ Roy T. Fielding ; Julian F. Reschke, eds. (2014). "Redirection 3xx" . Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content . IETF . p. 54. sec. 6.4. doi : 10.17487/RFC7231 . RFC 7231 .
- ↑ "Ganancias netas para una pequeña nación del Pacífico" . BBC News . 14 de septiembre de 2007. Archivado del original el 12 de mayo de 2014. Consultado el 27 de mayo de 2010 .
- 1 2 Innocenti, Tommaso; Golinelli, Matteo; Onarlioglu, Kaan; Mirheidari, Ali; Crispo, Bruno; Kirda, Engin (4 de diciembre de 2023). "La validación de URI de redirección 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.
- ↑ "Redirección abierta" . OWASP. 16 de marzo de 2014. Archivado del original el 7 de diciembre de 2014. Consultado el 21 de diciembre de 2014 .
- ↑ "Redirección encubierta" . Tetraph. 1 de mayo de 2014. Archivado del original el 10 de marzo de 2016. Consultado el 21 de diciembre de 2014 .
- ↑ "Se descubre una grave falla de seguridad en OAuth y OpenID" . CNET. 2 de mayo de 2014. Consultado el 21 de diciembre de 2014 .
- ↑ Mike Williams (5 de junio de 2022). "¿Qué es una vulnerabilidad de redirección abierta, por qué es peligrosa y cómo puedes protegerte?" . TechRadar . Consultado el 8 de abril de 2024 .
- ↑ "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 .
- ↑ 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 de información entre sitios en navegadores web" . Actas de la Conferencia ACM SIGSAC 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
- Asignación de URL a ubicaciones del sistema de archivos - Servidor HTTP Apache versión 2.4
- Taxonomía del spam de redireccionamiento JavaScript (Microsoft Live Labs)
- Vulnerabilidades de seguridad en los redireccionadores de URL. Clasificación de amenazas del Consorcio de Seguridad de Aplicaciones Web.
- Spam
- URL
- Optimización de motores de búsqueda de sombrero negro
- Búsqueda en Internet
- Terminología de Internet