Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
What does this suspicious URL structure do?
I (well, my spam trap) received email that I know is a scam, but I'm trying to understand how it works. The message contains a URL of the following form:
https:/example.com:2096/?goto_app=SomethingWithoutAnExtension
The single / after the protocol is suspicious, and I assume the key to a redirect that would be unfortunate. But how does this work? What's going on here?
I wondered if everything between the first two slashes would be ignored (I've heard of an exploit that works that way), but if so, I'm not sure how the rest of this string could do anything. There's not another layer of path that could be a URL,[1] and the thing after goto_app doesn't end in .exe or the like. I don't know if port 2096 is special.
I'm not going to try it to find out, but I did try going to https:/mydomain.example (a domain I control, not literally "mydomain"), using one slash instead of two, and Brave took me to my site. I tried looking it up in the IETF URL spec (is that the right place?) but I didn't find the details I was looking for (or maybe I'm looking in the wrong place).
How should this URL be parsed? How does this presumed scam work?
-
If the URL were instead
https:/example.com:2096/something.example?goto...then I would assume that everything up to the second slash is a decoy and it would take me tohtttps://something.example?.... But there aren't enough slashes in the suspicious URL I received. ↩︎
2 answers
I think to some extent, you actually answered your own question, possibly without realizing it.
A URL is a specialization of a URI. (Or more technically accurate, a URI is a generalization of a URL.) URIs are required to specify a scheme (https, mailto, gopher, tel, ...) but they aren't necessarily required to separate the two using ://; many URI schemes use a simple :.
However, a URI will always separate the scheme and the remainder by either : or ://.
A https scheme URI (which is one type of "URL", if by URL we mean a string which specifies the location of a web resource) will always use :// to separate the scheme from the rest of the URL. (In a web context it's also valid to omit the scheme and the :, such as in //example.com/page.html, which is a protocol-relative URL instructing the client to access the named resource through the same scheme as that which was used to access the page on which the reference exists.)
However, people are imperfect and make mistakes. Since browsers try to be user-friendly, they will often provide various forms of autocompletion or correction of URL syntax where the intention of the user can reasonably be determined even though the exact syntax is incorrect. (An early form of this likely was not requiring the user to type http:// all the time. A later form was adding prefixes and suffixes such as www. and .com to non-fully-qualified host names, so that if you typed codidact into the address field the browser would take you to http://www.codidact.com/.)
Substituting :// for :/ immediately following a recognized scheme seems a low-impact such fix to make, and is almost certainly what you saw the effect of.
So whoever is behind the email likely took advantage of that something won't recognize such a string as a valid URL and therefore not subject it to in-depth scrutiny, whereas the email client will likely see the https scheme and pass it to whatever program is configured for handling https scheme URIs, likely a web browser, and the browser in turn will happily correct the syntax such that the effect is the same as if it had contained :// instead of :/.
In other words: in this particular case, there is likely no particular shenanigans involved; just someone taking advantage of different software handling slightly invalid input differently.
Which is not to say that there aren't Unicode domain name shenanigans out there, such as for example using ∕ (U+2215) instead of / (U+002F) to give the appearance of the domain name being different from what it technically is. But if your example is representative, that does not appear to be what's going on here.
0 comment threads
It's not as complex as a clever URL trick: your would-be scammer is incompetent. Technically, this is a malformed URL and shouldn't parse at all. The relevant spec is RFC 3986 §3 — for this purpose, there must be a literal :// between the scheme and authority (domain).
However, entering this into a browser will actually take you to the URL as if there was a double slash there. This is a browser feature, intended to correct for user error in typing URLs into the address bar.
Likewise, the port number isn't relevant to the scam here: it just happens to be the port that the scammer is hosting this website on.
The query string is probably relevant to the scam, but only in that it sounds like it directs you to the "right" place. My best guess here is that following the link would take you to a phishing scam intended to get you to provide your credentials for some popular service or other.
1 comment thread
0 comment threads