OWASP TOP10 - # 10 redirigencias y reenvíos

Question

Leí muchos de los artículos de este tema, incluido el Owasp Page y el Artículo de Google Blog Acerca de las redirecciones abiertas ...
También encontré esta pregunta en redirecciones abiertas aquí en el desbordamiento de la pila pero es diferente a uno

Sé por qué no debería redirigir ... Esto hace que lo sea total.

Pero lo que realmente no entiendo: ¿Dónde está exactamente la diferencia entre redirigir y poner esto en un enlace normal de <a href? Tal vez algunos de los usuarios están buscando en la barra de estado, pero creo que la mayoría de ellos no están buscando realmente la barra de estado, cuando klick a un enlace.
¿Es esta realmente la única razón? Me gusta en este artículo que escribieron:

<a href="http://bank.example.com/redirect?url=http://attacker.example.net">Click here to log in</a>

El usuario puede asumir que el enlace es seguro ya que la URL comienza con su banco confiable, Bank.example.com. Sin embargo, el usuario será redirigido al sitio web del atacante (atacante.example.net) que el atacante puede haber hecho que parezca muy similar a Bank.example.com. Luego, el usuario puede ingresar sin saberlo las credenciales en la página web del atacante y comprometer su cuenta bancaria. Un servlet Java nunca debe redirigir a un usuario a una URL sin verificar que la dirección de redireccionamiento sea un sitio de confianza.

Entonces, si tiene algo como un libro de visitas, donde el usuario puede poner el enlace a su página de inicio, la única diferencia es que el enlace no se redirige, pero aún va a la página web del mal.

¿Estoy viendo este problema?

Answer 1

De mi comprensión, no es que la redirecta sea el problema.El problema principal aquí está permitiendo una redirección (donde el objetivo es potencialmente controlable por el usuario) que contiene una URL absoluta.

El hecho de que la URL es absoluta (lo que significa que comienza http://host/etc), significa que no está intencionalmente permitiendo redirecciones cruzadas.Esto es muy similar a las vulnerabilidades clásicas XSS, por lo que se puede reflejar a JavaScript para que las llamadas de dominio cruzado (y fugan la información de su dominio).

Entonces, como entiendo, la forma de solucionar la mayor parte de este tipo de problemas es asegurarse de que cualquier redirección (en el servidor) esté realizada con respecto a la raíz.Luego no hay forma de que el valor de la cadena de consulta controlada por el usuario vaya a otro lugar.

¿Eso responde a tu pregunta o simplemente crea más?

Answer 2

El principal problema es que es posible que un atacante haga que la URL parece ser confiable, ya que en realidad es una URL para el sitio web, la víctima confía, yo.mi. bank.example.com .

El objetivo de redireccionamiento no necesita ser tan obvio como en el ejemplo.En realidad, el atacante probablemente usará otras técnicas para engañar tanto al usuario como posiblemente incluso la aplicación web si es necesario con codificaciones especiales, contaminante de parámetros y otras técnicas para falsificar una URL legítima.

Incluso si una víctima es tan consciente de la seguridad de verificar una URL antes de hacer clic en un enlace o solicitar su recurso de lo contrario, todo lo que pueden verificar es que la URL apunta al sitio web confiable Bank.example.com .Y eso solo es suficiente.