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 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 reenvío de dominio ocurre 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

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

Forzar HTTPS

Es posible que se pueda acceder a un sitio web a través de un esquema URI HTTPS seguro y HTTP simple (un URI inseguro que comienza con "http://").

Si un usuario escribe un URI o hace clic en un enlace que hace referencia a la variante insegura, el navegador redirigirá automáticamente a la versión segura en caso de que el sitio web esté contenido en la lista de precarga HSTS enviada con la aplicación o si el usuario ya lo había 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, también preparando HSTS para futuros accesos.

Nombres de dominio similares

Un usuario podría escribir mal una URL. Las organizaciones suelen registrar estos dominios mal escritos y los redirigen a la ubicación deseada. Esta técnica se utiliza a menudo para "reservar" otros dominios de nivel superior (TLD) con el mismo nombre, o para facilitar que un sitio ".edu" o ".net" admita usuarios que escriben ".com".

Mover páginas a un nuevo dominio

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

Con los redireccionamientos de URL, los enlaces entrantes a una URL desactualizada 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 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 seguirán llegando a la página correcta. Además, en el próximo paso del motor de búsqueda, el motor de búsqueda debería detectar y utilizar la URL más nueva.

Registrar enlaces salientes

Los registros de acceso de la mayoría de los servidores web mantienen información detallada sobre el origen de 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 maneras. Una forma 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 objetivo real. Esta técnica tiene la desventaja del retraso causado por la solicitud adicional al servidor del sitio web original. Como esta solicitud agregada 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 está 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

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, 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 tanto, la redirección de URL puede ayudar a los usuarios que tienen marcadores. Esto se hace de forma rutinaria en Wikipedia cada vez que se cambia el nombre de una página.

Publicar/Redirigir/Obtener

Publicar/Redireccionar/Obtener (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).

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

Los redireccionamientos se pueden utilizar eficazmente con fines de orientación, como la orientación geográfica . La segmentación por dispositivo se ha vuelto cada vez más importante con el aumento de clientes móviles. Hay dos enfoques para atender a los usuarios de dispositivos móviles: hacer que el sitio web sea responsivo o redirigir a una versión del 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 orientación por dispositivo, se utilizan redirecciones del lado del cliente o redirecciones del lado del servidor que no se pueden almacenar en caché. La orientació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 sitios web que se dirigen a audiencias en más de una ubicación y/o idioma. Por lo general, las redirecciones del lado del servidor se utilizan para la orientació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

Los redireccionamientos se han utilizado para manipular los motores de búsqueda con intenciones poco éticas, por ejemplo, secuestro de URL . El objetivo de los redireccionamientos engañosos es dirigir el tráfico de búsqueda a páginas de destino que por sí solas no tienen suficiente poder de clasificación o que sólo están remotamente o no tienen ninguna relación con el objetivo de búsqueda. El enfoque requiere una clasificación para una variedad de términos de búsqueda con una cantidad de URL que utilizarían redireccionamientos furtivos para reenviar al buscador 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 redireccionamiento fuera del dominio [3] que explota la naturaleza del manejo del motor de búsqueda para redireccionamientos temporales. Si se encuentra una redirección temporal, los motores de búsqueda deben 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 conservarse para que aparezca en los resultados de búsqueda, ya que la redirección indica una naturaleza temporal. En determinadas circunstancias, era posible aprovechar este comportamiento aplicando redireccionamientos temporales a URL con buena clasificación, lo que provocaba la sustitución de la URL original en los resultados de búsqueda por la URL que inicializó la redirección y, por lo tanto, "robaba" la clasificación. Este método generalmente se combinaba 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 sanciones de clasificación a los sitios que quedan atrapados aplicando técnicas como estas. [4]

Manipular a los visitantes

La redirección de URL a veces se utiliza como parte de ataques de phishing que confunden a los visitantes acerca del 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 disminuye. Sin embargo, las redirecciones también pueden llevarle a sitios que, de otro modo, intentarían 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 algún tipo de troyano .

Eliminando referrerinformación

Cuando se hace clic en un enlace, el navegador envía en la solicitud HTTP un campo llamado referente que indica el origen del enlace. Este campo se completa 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 abandone la organización. Una página de redireccionamiento que oculta las referencias podría incrustarse 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 phishing al indicarle al usuario final que pasó por una puerta de enlace clara a otro sitio.

Implementación

Varios tipos diferentes de respuesta al navegador darán como resultado una redirección. Estos varían según si afectan los encabezados HTTP o el contenido HTML. Las técnicas utilizadas suelen depender de la función de la persona que las implementa y de su acceso a las diferentes partes del sistema. Por ejemplo, un autor web sin control sobre los encabezados podría usar una metaetiqueta Actualizar , mientras que es más probable que un administrador de servidor web que redirige todas las páginas de un sitio use 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, normalmente utilizando un ancla HTML como:

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 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 hace que un navegador muestre una página diferente. Si un cliente encuentra una redirección, debe tomar una serie de decisiones sobre cómo manejar la redirección. 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 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 modificados y 305 usan proxy no son redireccionamientos.

Todos estos códigos de estado requieren que la URL del destino de redireccionamiento 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 "movida permanentemente" se ve así:

HTTP / 1.1  301  Movido permanentemente Ubicación :  https://www.example.org/ Tipo de contenido :  texto/html Longitud del contenido :  174< html > < cabeza > < título > Movido </ título > </ cabeza > < cuerpo >=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 secuencias de comandos del lado del servidor para la redirección

Los autores web que producen contenido HTML normalmente no pueden crear redireccionamientos utilizando encabezados HTTP, ya que el programa del servidor web los genera automáticamente cuando sirve 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 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 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 en búfer los datos del cuerpo. En el lenguaje de secuencias de comandos ASP , esto también se puede lograr usando response.buffer=trueHTTP response.redirect "https://www.example.com/"/1.1 que permite una referencia de URI relativa o una referencia de 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 Apache HTTP se puede utilizar para redirigir determinadas solicitudes. Las directivas de configuración típicas se ven así:

Redireccionamiento  permanente /oldpage.html https://www.example.com/newpage.html Redireccionamiento 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://nuevositio.ejemplo.net/$1 [R=301,L]       

Dicha 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 único directorio de contenido a través de un .htaccessarchivo.

reescritura de nginx

Nginx tiene un módulo de reescritura http integrado, [10] que puede usarse para realizar procesamiento avanzado de URL e incluso generación de páginas web (con la returndirectiva). Un ejemplo que muestra un uso tan avanzado del módulo de reescritura es mdoc.su Archivado el 3 de abril de 2022 en Wayback Machine , que implementa un servicio de acortamiento de URL determinista completamente con la ayuda del lenguaje de configuración nginx. [11] [12]

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

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

Actualizar metaetiqueta y encabezado de actualización HTTP

Netscape introdujo la función de metaactualización 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 trata esto como una redirección permanente 301, lo que permite la transferencia de PageRank a la página de destino. [dieciséis]

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

< html > < head >  < meta  http-equiv = "Actualizar"  content = "0; url=https://www.example.com/"  /> </ head > < body >  < p > Siga < a  href = "https://www.example.com/" > este enlace </ a > . </p> </body> </html> _ _ _ _ _ _

Los autores web pueden utilizar esta técnica porque la metaetiqueta está contenida dentro del propio documento. La metaetiqueta debe colocarse en la sección "encabezado" del archivo HTML. El número "0" en este ejemplo se puede reemplazar 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.

Se puede lograr el mismo efecto con un refreshencabezado HTTP:

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

Esta respuesta es más fácil de generar con 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" ; imprimir "\r\n" ; print "¡Sigue <a href=\"https://www.example.com/\">este enlace</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 metaactualizació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] desaconsejan la creación de páginas que se actualizan 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 urgentes. Utilizar redireccionamientos estándar: ¡no rompas el botón Atrás! [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 estableciendo el window.locationatributo, por ejemplo:

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

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

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

Sin embargo, es posible que se prefieran los encabezados HTTP o la metaetiqueta de actualización 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 < a  href = "https://www.example.com/" > enlace < / 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 fácil de recordar o para ocultar de manera fraudulenta un sitio de phishing como parte de una suplantación de sitio web . [21]

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

< filas de conjunto de marcos  = "100%" > < frame src = "https://www.example.com/" > < noframes > < cuerpo > Siga < a href = "https://www.example.com/" > enlace </ a > . </body> </noframes> </frameset> _ _ _ _ _ _      

Cadenas de redireccionamiento

Un redireccionamiento puede llevar a otro en una cadena de redireccionamiento. Si una redirección conduce a otra redirección, esto también puede denominarse 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 puede navegar al sitio específico del idioma. Esto es inevitable si los diferentes enlaces de la cadena son servidos por servidores diferentes, aunque se debe minimizar 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 hacer que una página acabe redireccionándose a sí misma, posiblemente a través de otras páginas, lo que lleva 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 fija de este tipo.

Servicios

Existen servicios que pueden realizar la redirección de URL a pedido, sin necesidad de trabajo técnico ni 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 contenido que cambia de host con frecuencia, de manera similar al Sistema de nombres de dominio . Los hipervínculos que implican servicios de redireccionamiento de URL se utilizan con frecuencia en mensajes de spam dirigidos a blogs y wikis. Por 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á las ediciones y comentarios legítimos y puede que no sea un método eficaz para reducir el spam. Recientemente, los servicios de redireccionamiento de URL han adoptado AJAX como un método eficiente y fácil de usar para crear URL acortadas. Un inconveniente 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 dominios de nivel superior (TLD) como " .to " (Tonga), " .at " (Austria) y " .is " (Islandia). Su objetivo era crear URL memorables. El primer servicio de redireccionamiento convencional fue V3.com, que contó 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 50,00 dólares al año a menos de 10,00 dólares , 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 Twitter , estos servicios de URL cortas se han utilizado mucho.

Enmascaramiento de referencia

Los servicios de redireccionamiento pueden ocultar el referente colocando una página intermedia entre la página en la que se encuentra el enlace y su destino. Aunque 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 es ocultar la información de referencia y proporcionar una puerta de enlace clara entre otros sitios web). ) Este tipo de redirección se utiliza a menudo para evitar que 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 comunidades grandes utilizan la redirección de enlaces en enlaces externos para disminuir la posibilidad de que se produzca un exploit que pueda 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 .

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

<?php $url  =  htmlspecialchars ( $_GET [ 'url' ]); encabezado ( 'Actualizar: 0; url=https://'  .  $url ); ?> <!-- Respaldo mediante metaactualización. --> < html >  < head >  < title > Redirigiendo... </ title >  < meta  http-equiv = "refresh"  content = "0;url=https:// <? =  $url ;  ?> " >  </ head >  < body > Intentando redirigir a < a  href = "https:// <? =  $url ;  ?> " > https:// <? =  $URL ;  ? > </a> . _ </cuerpo> </html> _ _ _ _

El ejemplo anterior no comprueba quién lo llamó (por ejemplo, por referente, aunque podría ser falso). 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 URL de su propia selección, desde cualquier página que utilice los recursos del servidor web.

Temas de seguridad

Los atacantes pueden abusar del redireccionamiento de URL para realizar ataques de phishing , como el redireccionamiento abierto y el redireccionamiento encubierto . "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 validación SUFICIENTE". [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]

Ver también

Referencias

  1. ^ ab "Google revive el espionaje de redireccionamiento". 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: análisis de redireccionamientos 302". Matt Cutts, exjefe 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 de redirecciones y reenvíos no validados". Proyecto abierto de seguridad de aplicaciones web (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: 302 a 301 solución robusta y sólida como una roca". WebSiteFactors.co.uk. Archivado desde el original el 12 de octubre de 2012.
  8. ^ Roy T. Fielding; Julián F. Reschke, eds. (2014). "Ubicación". Protocolo de Transferencia de Hipertexto (HTTP/1.1): Semántica y Contenido. IETF . pag. 68. seg. 7.1.2. doi : 10.17487/RFC7231 . RFC 7231.
  9. ^ Berners-Lee, Tim ; Fielding, Roy T .; Master, Larry (2005). "Resolución de referencia". Identificador uniforme de recursos (URI): sintaxis genérica. IETF . pag. 28. seg. 5.doi : 10.17487 /RFC3986 . RFC 3986.
  10. ^ "Módulo ngx_http_rewrite_module - reescribir". nginx.org . Consultado el 24 de diciembre de 2014 .
  11. ^ Murenin, Constantine A. (18 de febrero de 2013). "¿Un sitio web dinámico escrito íntegramente 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: URL breves de páginas de manual para 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. ^ "Metaetiqueta 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}}: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace )
  16. ^ "Google y Yahoo aceptan metaactualizaciones inmediatas como redireccionamientos 301". Folletos de Sebastián. 3 de septiembre de 2007.
  17. ^ "Pautas de accesibilidad al contenido web 1.0". www.w3.org .
  18. ^ Equipo, el control de calidad. "Utilice redireccionamientos 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 en varios navegadores". Zona interior. 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). Laboratorios Radix.
  22. ^ "HTML 5.2: 11. Funciones obsoletas". www.w3.org .
  23. ^ Schwartz, Barry (18 de diciembre de 2007). "Las redirecciones dobles pueden tardar más tiempo en que Google se dé cuenta". Mesa redonda sobre motores de búsqueda . Consultado el 28 de enero de 2024 .
  24. ^ Roy T. Fielding ; Julián F. Reschke, eds. (2014). "Redireccionamiento 3xx". Protocolo de Transferencia de Hipertexto (HTTP/1.1): Semántica y Contenido. IETF . pag. 54. seg. 6.4. doi : 10.17487/RFC7231 . RFC 7231.
  25. ^ "Ganancias netas para la pequeña nación del Pacífico". Noticias de la BBC . 14 de septiembre de 2007. Archivado desde el original el 12 de mayo de 2014 . Consultado el 27 de mayo de 2010 .
  26. ^ "Abrir redireccionamiento". OWASP. 16 de marzo de 2014 . Consultado el 21 de diciembre de 2014 .
  27. ^ "Redireccionamiento encubierto". Tetrafio. 1 de mayo de 2014 . Consultado el 21 de diciembre de 2014 .
  28. ^ "Grave falla de seguridad en OAuth, descubierta en OpenID". CNET. 2 de mayo de 2014 . Consultado el 21 de diciembre de 2014 .

enlaces externos