Vulnerabilidad de acortador de URL

Bien, simple respuesta.

NO INCLUYA NUNCA NINGÚN TIPO DE INFORMACIÓN PERSONAL EN LA URL.

La URL es extremadamente fácil de obtener desde el exterior (por ejemplo, javascript, captura de pantalla, etc.) y nunca debe incluir información personal. Es como usar un Número de Seguro Social como su número de placa.

Técnicamente, puede bloquear los escáneres de fuerza bruta agregando controles como si el usuario estuviera en la sesión actual y rechazara la conexión si alguien está tratando de acceder a la URL sin información de la sesión, pero aún así no es un gran enfoque porque aún le dará algo tipo de respuesta del servidor. (por ejemplo, si solo verifica sesión y hace eco de que no tiene permiso, le dará un código de respuesta 200 y el atacante podrá notar que hay ALGO)

Encuentre otras formas de proporcionar su servicio sin usar información personal en la URL.

Como se sugiere a continuación, si decide hacer un hash de la información personal, use más tiempo & más conjunto de caracteres.

Si solo usas 6 caracteres del alfabeto, tomará aproximadamente ~ 9 horas con ataque de fuerza bruta de Clase A, y la Clase F puede resolverlo instantáneamente.

Lea este sitio web y asegúrese de que lo hash correctamente. Pero, de nuevo, el hash no debería ser la solución definitiva.

EDITAR:

Si no está mostrando información personal en la URL, podría estar bien. Simplemente puede generar un enlace personal y enviarlo a su usuario por SMS o correo electrónico con autenticación .

Eso significa que, una vez que el usuario haga clic en el enlace, llevará al usuario a la pantalla de inicio de sesión. La URL no debe significar nada en este caso, por supuesto.

La guía OWASP recomienda dos métodos ( Cómo proteger datos confidenciales en URL's ):

1. Hashing the senstive data

2. Encriptar los datos confidenciales mediante el cifrado simétrico

Si la información personal se encuentra en la página a la que apunta la URL, podría implementar las siguientes medidas:

• Agregue algún tipo de secreto compartido o autenticación antes de que el usuario pueda acceder a los datos. (Según tengo entendido, esto no es lo que quiere hacer, ya que con la autenticación completa no necesitaría ninguna URL reducida)
• Si la autenticación es inapropiada, agregue un CAPTACHA seguro antes de que el usuario pueda acceder a los datos.
• Supervise las direcciones IP de acceso y los agentes de usuario y aplique los bloqueos o la regulación después de una pocos intentos de conexión.
• Agregue un tiempo de expiración y / o un umbral para que la página con los datos obtenga eliminado después de un corto tiempo y / o una cierta cantidad de visitas. (No olvide incluir en la lista negra los ID utilizados para evitar colisiones)
• Aumente la entropía de la identificación aumentando el número de caracteres utilizados (letras, mayúsculas, barras diagonales, otros caracteres especiales)