El ejemplo de OWASP para Redirecciones y reenvíos no validados dice que:
La aplicación tiene una página llamada "redirect.jsp" que toma un solo parámetro llamado "url". El atacante crea una URL maliciosa que redirige a los usuarios a un sitio malicioso que realiza phishing e instala malware.
¿Cómo hace un atacante para crear una URL maliciosa y obliga a la víctima? Si uno va a foo.bar , llena un formulario y lo envía, ¿cómo se puede redirigir a un sitio de Amalicious?
Digamos que hay una url llamada www.example.com/redirect.jsp?url=www.example.com/login que se usa para redirigir a la página de inicio de sesión. Elaboré un enlace a www.example.com/redirect.jsp?url=www.myphishingsite.com/login que redirige a mi sitio de phishing. La gente mira el nombre de dominio y piensa que es legítimo. También se puede utilizar para DOS algo y ocultar su identidad del objetivo.
No hay forma involucrada.
@joe tiene razón acerca de la naturaleza del ataque (+1), pero hay algo más que eso. A saber, de quién es el problema y por qué ocurre.
Usando el mismo ejemplo, digamos que example.com usa un script de redireccionamiento, por ejemplo, example.com/redirect.php que recibe el parámetro url y luego realiza un HTTP 302 (o 301) a la URL que se encuentra en la URL. Parámetro url . Ahora, digamos también que example.com contiene contenido generado por el usuario , incluida la URL a la que se vinculan los usuarios.
Cuando un usuario publica una URL en example.com , por ejemplo, http://mywebsite.com/myarticle/ , entonces example.com muestra esta URL como:
href="http://example.com/redirect.php?url=http://mywesite.com/myarticle"
Pero, ¿por qué example.com muestra la URL de esa manera en lugar de la URL simple? Debido a que redirect.php recopila estadísticas sobre los enlaces en los que hacen clic los usuarios.
Entonces, ¿cuál es el problema? El problema es que puedo agregar una URL en otro sitio web que también aloja contenido de usuario , sin relación alguna con example.com , por ejemplo, en facebook.com que dice:
http://example.com/redirect.php?url=http://myphishingwebsite.com/script.php
Y el usuario hará clic en eso pensando que es un enlace que conduce a example.com .
Los navegadores a menudo acortan las URL largas pero dejan el dominio completo, y algunos foros incluso hacen que un dominio se destaque de un enlace; todo eso para evitar el phishing a través de enlaces a sitios dudosos. Pero en el ejemplo anterior, example.com ha destruido estas salvaguardas y permitirá que cualquier sitio web sea redirigido, mientras que el dominio que se ve cuando se desplaza sobre el enlace siempre es example.com .
Lo anterior es un problema de example.com y, por lo tanto, este doiman debe clasificarse como no seguro para navegar, incluso porque no contiene ningún contenido malicioso.
En lugar de usar un redireccionamiento sin marcar, example.com debería hacer una lista blanca de dominios en los que se puede usar redirect.php , o hacer que los dominios en el parámetro url se destaquen (por ejemplo, anteponer el dominio en un color de alto contraste ) antes del enlace en sí y requiere un encabezado Referer: adecuado durante la redirección (por lo tanto, las redirecciones solo pueden ocurrir desde el mismo example.com ). Preferiblemente, debería realizar ambas correcciones.
Hay dos problemas con estas redirecciones:
1) Fuga de origen
Digamos que usted escribió un servidor web (inseguro) que en un momento dado pone el nombre de usuario & la contraseña de un usuario en una URL (es decir, una solicitud GET). Una redirección le diría a un malicioso de dónde proviene un usuario, lo que les permite extraer sus credenciales de la URL.
2) Falso sentido de confianza
Los usuarios pueden redirigirse a un sitio de phishing sin saberlo. Un usuario cauteloso podría estar usando el sitio legítimo y, de repente, ser redirigido a un sitio malicioso sin que ellos lo sepan. Este usuario continuaría utilizando el sitio como de costumbre, posiblemente ya haya revisado la URL, etc. No sé sobre usted, pero no reviso la URL cada vez que me muevo por un sitio web.
Lea otras preguntas en las etiquetas url-redirection