Defender el sitio contra el abuso de phishing

Una forma en que podría abordar esto sería cifrar el parámetro a medida que se pasa al usuario con una clave almacenada en el servidor (también para una mejor protección, considere agregar un HMAC ). Luego, cuando el usuario envíe el formulario, descifre el parámetro (y verifique el HMAC si se usa) y utilícelo para redirigir al usuario.

He visto casos en los que la URL solo está oculta (codificación base64, etc.). Eso podría disuadir a los atacantes casuales, pero no me atrevería a hacerlo, ya que es probable que un atacante determinado resuelva el esquema utilizado.

Puedes agregar el prefijo de tu sitio web en la url para que vayan a:

example.com/login.php?returnurl=profiles/home.php

Y en la página, debería volver a enlace y agregar la URL de retorno. (http://example.com/RETURNURLHERE)

Hay muchas formas de atacar a un usuario / navegador u ofuscar URL / redirecciones. ¡De manera loca eso hará que te duela el cerebro y te hará preguntar por qué funciona eso! (consulte: enlace ) En general, al validar la entrada, no intente arreglar los datos, si no es qué Usted esperaba o no en el formato que requería, deséchelo. Recuerda negar por defecto, este es solo otro ejemplo de eso.

Como cualquier cosa, la forma en que implementes esto depende de tus requisitos. También debe tener en cuenta las fallas en la implementación al manejar redirecciones que también pueden abrir otras vulnerabilidades como la división de respuestas HTTP, la inyección de encabezado, etc.

Generalmente recomiendo una combinación de listas blancas de destino y firma de solicitud (usando HMAC, similar a la sugerencia de Rory). Al preformar la firma de solicitud, me gusta hacer que el destino sea visible en el URI. Por ejemplo:

enlace

Eso le permite al usuario tener una pequeña viabilidad hacia donde debería ir la solicitud, y también permite que los usuarios más experimentados posiblemente noten un phishing u otro ataque por su cuenta.

Cuando se va a producir una redirección:

1. Verifique el 'returnurl' contra el hash
2. Verifique que el 'returnurl' esté en la lista blanca
3. Luego realice la redirección.

Si falla algún paso del proceso de validación, redirija a una página de inicio / predeterminada o rechace la solicitud.

Aquí hay algunos recursos más:

• enlace
• enlace
• enlace

1. Eliminar toda la información innecesaria de la URL (por ejemplo, http:// , el nombre del sitio, etc.). Si tiene varias opciones (por ejemplo, cinco sitios), use su índice.
2. Calcule un hash de lo que queda usando un sal secreto del lado del servidor y prepárelo (o una parte de él: cuanto más corto es, mayor es el peligro de un ataque de colisión exitoso) a returnUrl
3. Al recibir returnUrl , verifique que el hash sea válido. Si no, rechazar.
4. Vuelva a agregar toda la información faltante y redirija.

Además, algunas redirecciones pueden seguir un patrón común en el que solo necesitas conectar algunos parámetros. En este caso, es posible que ni siquiera necesites el hash.

Por ejemplo: en lugar de

returnUrl=http://www.myfifthsite.com/common/webpage/profile?user=lserni

puedes hervir el

returnUrl=5-5-lserni

significa quinto sitio, quinto patrón de redireccionamiento permitido, este patrón solo tiene un parámetro y su valor es el nombre de usuario:

sitios:     ...     5 = > ' enlace '     ...

patrones para el sitio # 5 (por supuesto, la autenticación no se invalida):         5 = > '/ common / webpage / profile? usuario = $ 1'         6 = > '/ common / webpage / messages? user = $ 1'

Un atacante podría enumerar todos los números de sitio y patrón permitidos, pero solo obtendría URL válidas de los sitios que usted permita.

Así que, en cierto sentido, de esta manera no necesitas verificar nada en absoluto. Las URL siempre serán válidas automáticamente (incluso si algunas aún requieren cookies de autenticación).