What's the purpose of @ (at symbol) in URL before domain?

Question

I've recently came across new phishing attack which is using @ symbol to make the URL look legit. It goes like this:

I have an account at totally-legit-site.com and the attacker sets up a phishing site at his IP like 192.168.50.20. Then, he sends me a message at the site, containing link which looks like http://totally-legit-site.com@192.168.50.20/account. This is used to trick the user into thinking this is the link to the legit site.

Clicking this link, however, opens page 192.168.50.20/account in my browser (Google Chrome). I tried adding random stuff with @ before random domains and my browser always resolves the page correctly, throwing that stuff with @ away. So if I try to open http://test@google.com, I end up at Google's homepage.

This really interests me. I wasn't able to find any information about @ in URLs before domain. How is this called? Is this some obsolete stuff from the early stages of the internet? Are there some webservers that can process this part of URL (being able to modify my nginx instance to return different sites based on this parameter would be cool)?

Answer 1

This syntax is used to specify protocol-level authentication details (username, occassionally also password) for connecting to the 'authority'. See for example RFC 3986 section 3.2.1.

When used with HTTP, the credentials are sent in the HTTP Authorization: header; the format depends on the authentication mechanism requested by the server, but most commonly Basic authentication is used with no additional processing. See RFC 7617 or MDN.

Many webservers can verify the credentials against a 'htpasswd' file, LDAP, SQL or other data­bases – e.g. for Nginx see auth_basic or Apache httpd AuthType Basic.

Alternatively, the verification can be done by webapps themselves since it's done through standard HTTP headers and status codes. See for example PHP (But to make this work in Apache you might need to enable CGIPassAuth or use a weird rewrite trick, otherwise it won't forward the Authorization header to the app runtime.)

Built-in HTTP authentication is commonly used for APIs and other automated requests, since it needs no user interaction, doesn't require storing cookies or other state, and doesn't require knowing how to format the "login" POST request (which you'd need for <form>-based auth).

This is also exactly the same authentication method as used by these prompts:

The same syntax also applies to FTP and many other protocols which use a URL and support authentication – in all cases, that protocol's built-in mechanism is used.

---

The attack here works because HTTP authentication is optional and in most cases the extra HTTP header is simply ignored by the webserver and the webapp. And vice versa, browsers don't know whether the server will ask for authentication until after a request is sent.

However, the attack isn't new at all – it's been around since at least early 2000s. (In fact, at some point browsers did start checking, by first making a request without auth to see whether the server will reply with 401 or not. If the server does not request authentication, Chrome will hide the username from the address bar to make the real domain more obvious, and Firefox will actually warn that "This may be an attempt to trick you.")