Qual è lo scopo di @ (al simbolo) nell'URL prima del dominio?
Recentemente mi sono imbattuto in un nuovo attacco di phishing che utilizza il @simbolo per rendere l'URL legittimo. Funziona così:
Ho un account su totally-legit-site.come l'aggressore imposta un sito di phishing al suo IP come 192.168.50.20. Quindi, mi invia un messaggio al sito, contenente il collegamento che assomiglia http://[email protected]/account. Viene utilizzato per indurre l'utente a pensare che questo sia il collegamento al sito legittimo.
Facendo clic su questo collegamento, tuttavia, si apre la pagina 192.168.50.20/accountnel mio browser (Google Chrome). Ho provato ad aggiungere cose casuali con @prima di domini casuali e il mio browser risolve sempre la pagina correttamente, buttando via quella roba @. Quindi se provo ad aprire http://[email protected], finisco sulla home page di Google.
Questo mi interessa davvero. Non sono riuscito a trovare alcuna informazione sugli @URL prima del dominio. Come si chiama? È qualcosa di obsoleto dalle prime fasi di Internet? Esistono server Web in grado di elaborare questa parte dell'URL (sarebbe interessante poter modificare la mia istanza nginx per restituire siti diversi in base a questo parametro)?
Risposte
Questa sintassi viene utilizzata per specificare i dettagli di autenticazione a livello di protocollo (nome utente, occasionalmente anche password) per la connessione all '"autorità". Vedere ad esempio RFC 3986 sezione 3.2.1 .
Quando viene utilizzato con HTTP, le credenziali vengono inviate nel HTTP di autorizzazione: intestazione ; il formato dipende dal meccanismo di autenticazione richiesto dal server, ma più comunemente l' Basicautenticazione viene utilizzata senza ulteriori elaborazioni. Vedi RFC 7617 o MDN .
Molti server web possono verificare le credenziali rispetto a un file 'htpasswd', LDAP, SQL o altri database - ad es. Per Nginx vedere auth_basic o Apache httpd AuthType Basic .
In alternativa, la verifica può essere eseguita dalle webapp stesse poiché viene eseguita tramite intestazioni HTTP standard e codici di stato. Vedi ad esempio PHP (ma per farlo funzionare in Apache potresti dover abilitare CGIPassAutho utilizzare uno strano trucco di riscrittura, altrimenti non inoltrerà l'intestazione di autorizzazione al runtime dell'app.)
L'autenticazione HTTP incorporata viene comunemente utilizzata per le API e altre richieste automatiche, poiché non richiede l'interazione dell'utente, non richiede la memorizzazione di cookie o altri stati e non richiede di sapere come formattare la richiesta POST di "accesso" (che tu necessario per l'autenticazione basata su <form>).
Anche questo è esattamente lo stesso metodo di autenticazione utilizzato da questi prompt:
La stessa sintassi si applica anche all'FTP e a molti altri protocolli che utilizzano un URL e supportano l'autenticazione: in tutti i casi, viene utilizzato il meccanismo integrato di quel protocollo.
L'attacco qui funziona perché l'autenticazione HTTP è opzionale e nella maggior parte dei casi l'intestazione HTTP aggiuntiva viene semplicemente ignorata dal server web e dall'app web. E viceversa, i browser non sanno se il server chiederà l'autenticazione fino a dopo l' invio di una richiesta.
Tuttavia, l'attacco non è nuovo a tutti - è stato intorno almeno dal primi anni 2000. (In effetti, a un certo punto i browser hanno iniziato a controllare, facendo prima una richiesta senza autenticazione per vedere se il server risponderà con 401 o meno. Se il server non richiede l'autenticazione, Chrome nasconderà il nome utente dalla barra degli indirizzi per fare il dominio reale è più ovvio e Firefox effettivamente avviserà che "Questo potrebbe essere un tentativo di ingannarti.")