¿Cuál es el propósito de @ (símbolo arroba) en la URL antes del dominio?
Recientemente me encontré con un nuevo ataque de phishing que usa un @símbolo para hacer que la URL parezca legítima. Dice así:
Tengo una cuenta en totally-legit-site.comy el atacante configura un sitio de phishing en su IP como 192.168.50.20. Luego, me envía un mensaje al sitio, que contiene un enlace que parece http://[email protected]/account. Esto se usa para engañar al usuario haciéndole creer que este es el enlace al sitio legítimo.
Sin embargo, al hacer clic en este enlace, se abre la página 192.168.50.20/accounten mi navegador (Google Chrome). Intenté agregar cosas al @azar con dominios aleatorios antes y mi navegador siempre resuelve la página correctamente, tirando esas cosas @. Entonces, si intento abrir http://[email protected], termino en la página de inicio de Google.
Esto realmente me interesa. No pude encontrar ninguna información sobre las @URL antes del dominio. ¿Cómo se llama esto? ¿Es esto algo obsoleto de las primeras etapas de Internet? ¿Hay algunos servidores web que puedan procesar esta parte de la URL (sería genial poder modificar mi instancia nginx para devolver diferentes sitios basados en este parámetro)?
Respuestas
Esta sintaxis se usa para especificar detalles de autenticación a nivel de protocolo (nombre de usuario, ocasionalmente también contraseña) para conectarse a la 'autoridad'. Consulte, por ejemplo, RFC 3986, sección 3.2.1 .
Cuando se utiliza con HTTP, las credenciales se envían en el HTTP de Autorización: cabecera ; el formato depende del mecanismo de autenticación solicitado por el servidor, pero la Basicautenticación más comúnmente se utiliza sin procesamiento adicional. Consulte RFC 7617 o MDN .
Muchos servidores web pueden verificar las credenciales con un archivo 'htpasswd', LDAP, SQL u otras bases de datos; por ejemplo, para Nginx, consulte auth_basic o Apache httpd AuthType Basic .
Alternativamente, las aplicaciones web pueden realizar la verificación, ya que se realiza a través de encabezados HTTP estándar y códigos de estado. Vea, por ejemplo, PHP (pero para que esto funcione en Apache, es posible que deba habilitar CGIPassAutho usar un truco de reescritura extraño, de lo contrario, no reenviará el encabezado de Autorización al tiempo de ejecución de la aplicación).
La autenticación HTTP incorporada se usa comúnmente para API y otras solicitudes automatizadas, ya que no necesita interacción del usuario, no requiere el almacenamiento de cookies u otro estado, y no requiere saber cómo formatear la solicitud POST de "inicio de sesión" (que usted necesitaría una autenticación basada en <form>).
Este también es exactamente el mismo método de autenticación que se usa en estas solicitudes:
La misma sintaxis también se aplica a FTP y muchos otros protocolos que utilizan una URL y admiten la autenticación; en todos los casos, se utiliza el mecanismo integrado de ese protocolo.
El ataque aquí funciona porque la autenticación HTTP es opcional y, en la mayoría de los casos, el servidor web y la aplicación web simplemente ignoran el encabezado HTTP adicional. Y viceversa, los navegadores no saben si el servidor solicitará autenticación hasta después de que se envíe una solicitud.
Sin embargo, el ataque no es nuevo en absoluto , ha existido desde al menos principios de la década de 2000. (De hecho, en algún momento, los navegadores comenzaron a verificar, primero haciendo una solicitud sin autenticación para ver si el servidor respondería con 401 o no. Si el servidor no solicita autenticación, Chrome ocultará el nombre de usuario de la barra de direcciones para hacer el dominio real es más obvio, y Firefox advertirá que "Esto puede ser un intento de engañarlo").