The Dangers of Google’s .zip TLD
medium.comThe fact that browsers will silently strip out everything before @, including "fake" slashes is surely the real problem here. That .zip is now a valid TLD doesn't strike me as making the situation vastly worse - something like https://github.com/kurbernetes/@latest.dev/package.zip seems just as likely to fool a recipient not being 100% vigilant. (To be fair, that used real slashes - all the substitute slash characters do actually look noticeably different to a regular slash - perhaps surprisingly there's no "non-breaking slash". Actually the big solidus ⧸ is pretty close but HN seems to block me using it in a URL!)
github.com∕not-suspicious@package.zip
add https:// and your browser will take you right to https://package.zip
Sure, and the fact that .zip is both a common file extension for downloading AND now a TLD is not a good thing (I don't know who though having .zip as a TLD was a good idea), but I still don't think it's the main risk here. Maybe it'll finally prompt Google (and other browser distributors) to stop automatically stripping stuff from URLs, and to check/warn on Unicode homographs (hell, it doesn't even warn on www․google.com - and that's NOT a regular period/full stop after the first www - I doubt anyone would be able to register www․google.com as a domain but who knows).
> Can you quickly tell which of the URLs below is legitimate and which one is a malicious phish that drops evil.exe?
Yes? When you hover the first link the browser says "v1271.zip", and when you hover the second link it says "https://github.com/kubernetes/kubernetes/archive/refs/tags/v..."
You don't even need a .zip domain to do this, just assign a misleading link i.e. [google.com](badsite.com). If the argument is going to be no one looks at the on hover link preview, then why bother even paying for a .zip domain in the first place? Going further, you can also just buy a similar domain to confuse people, which might even work better than buying the .zip since then you _might_ even catch careful people that glance at the on hover preview.
If I copy and paste the malicious URL into the terminal, or the browser’s location field, there’s no indication that it’s anything but what it appears to be.
Of course, there’s nothing unique about `.zip` other than that it’s a common file extension. Any TLD that makes for a convincing file extension could be used this way.
Maybe we should have the .exe TLD to make every URL using it look immediately suspicious.
Sorta like https://verylegit.link but built into the whole TLD.
Hovering the link to preview its location in the status bar reveals the trick because the browser doesn't see any real slashes. The anchor's href (when inspected) actually does have the full bogus URL, but when hovered we're shown the browser-evaluated URL—which is a TIL.
> In an email client, we could make it even more convincing, and change the size of the @ operator to a size 1 font
Doesn't change the underlying issue, but plain text email would have stopped that part of it!
Of course, that's banned at work because then the signature wouldn't have the approved font and picture in it, and therefore it's not Corporate (TM) enough.
While I get it... there are plenty of risks just with high characters in domain names. I would simply suggest the "hover" view for links don't show the translated punycode character encoding for domains.
I think it would be far more of an issue if .lan or .local were ever able to make it past icann for a registrar. What's funny to me, is the number of web forms that haven't been updated to allow anything other than .com/net/org for signup.
You can block all .zip with the following uBlock Origin filter:
||zip^
Blue Coat Systems warned about the .zip domain quite some time ago.
https://www.cio.com/article/220242/the-webs-10-most-shady-ne...
What is the argument in favor of these TLDs existing other than corruption/extortion?
I blackholed .zip and .mov in my DNS servers.