Domain hacks with unusual Unicode characters (2018)(shkspr.mobi)
shkspr.mobi
Domain hacks with unusual Unicode characters (2018)
https://shkspr.mobi/blog/2018/11/domain-hacks-with-unusual-unicode-characters/
24 comments
Could this be used in a XSS attack where there are very limited characters to use after the src= tag, where it would resolve to a valid domain with more characters?
Potentially, depending on how the character counting is done (if it counts grapheme clusters instead of bytes I guess?)
You might be interested in this — an example where the company logo is the domain name, and vice versa:
https://xn--bj8a.com (ꑮ.com)
(Safari on macOS and iOS displays the symbol in the address bar.)
https://xn--bj8a.com (ꑮ.com)
(Safari on macOS and iOS displays the symbol in the address bar.)
huh. that’s an attack other browsers have fixed by using punycode. i wonder does safari have blacklist for homoglyphs but renders others as the intended glyph.
The whitelist for Safari on macOS is kept in a text file entitled IDNScriptWhiteList.txt, located at /System/Library/Frameworks/WebKit.framework/Versions/Current/Resources
ꑮ is from Yi script, which is obviously whitelisted.
ꑮ is from Yi script, which is obviously whitelisted.
> Here are the single characters which can be normalised down to a valid TLD
only TLDs or anywhere in the name? i suspect this is special treatment for TLDs
only TLDs or anywhere in the name? i suspect this is special treatment for TLDs
A work buddy got an emoji domain (.ws) but couldn't find an email server that could work with emoji domain email addresses.
He was probably trying to type emojis into form fields instead of punycode.
Gmail does?
I'll admit this is pretty neat. Unclear if I will ever use this information, but I'll always know it now.
Why does Unicode have different code points for same letter rendered with different type faces?
Accidentary math symbols. Sometimes there is semantic difference between 𝒎, 𝐦, 𝕞, m which will be lost in plaintext rendition of a formula. Yeah, you'd better be off with TeX for this specific purpose, but that's a valid point for having those font variations.
And it's not a generic modifier because those code points predate the expanse of emoji and all surrounding normalization of modifiers. Language tags are considered a bad idea, for example, so it's not all clear that it's necessary for Unicode to convey semantics as well.
And it's not a generic modifier because those code points predate the expanse of emoji and all surrounding normalization of modifiers. Language tags are considered a bad idea, for example, so it's not all clear that it's necessary for Unicode to convey semantics as well.
Thank you. I should have figured this out myself. I've been postponing going down the Unicode rabbit hole.
Here's some relevant entries.
𝐦 217F SMALL ROMAN NUMERAL ONE THOUSAND http://unicode.org/cldr/utility/character.jsp?a=217F
https://en.wikipedia.org/wiki/Mathematical_operators_and_sym...
Whelp. That's a lot to ingest. I suppose if (when) I have to do Unicode for real, I'll need to find the 'ascii' command line tool equivalents for Unicode.
Here's some relevant entries.
𝐦 217F SMALL ROMAN NUMERAL ONE THOUSAND http://unicode.org/cldr/utility/character.jsp?a=217F
https://en.wikipedia.org/wiki/Mathematical_operators_and_sym...
Whelp. That's a lot to ingest. I suppose if (when) I have to do Unicode for real, I'll need to find the 'ascii' command line tool equivalents for Unicode.
I don't want to rain on this person's parade, but I think this is a horrible idea. This is great for phishing but a really bad choice for your actual domain, because it's basically impossible to type out the URL (or even convey: it's "foo.tel but the 'tel' is small for some reason?") and you're already seeing a bunch of tools break on it. (To really drive the point home, the final link the article had a box in it on my computer.)
Except, it's equivalent to normal .tel. This URL points to the article above, with all the unhacking done client-side:
https://xn--69f31l4t57c0mag4b613h.xn--7uh4898msjaso/🆆🆃🅵/
(that's https;//🅂𝖍𝐤ₛᵖ𝒓.ⓜ𝕠𝒃𝓲/🆆🆃🅵/)
https://xn--69f31l4t57c0mag4b613h.xn--7uh4898msjaso/🆆🆃🅵/
(that's https;//🅂𝖍𝐤ₛᵖ𝒓.ⓜ𝕠𝒃𝓲/🆆🆃🅵/)
Cool, it has the exact same issue here as well. (It shows up as boxes.)
As I say in the blog post, this is only useful when you want / need to save a couple of characters in a message. Or if you're desperate for the URl to look "interesting".
It's also handy if you want to hide a URl from automated detection tools.
But, you are right, not all characters will render on all systems.
It's also handy if you want to hide a URl from automated detection tools.
But, you are right, not all characters will render on all systems.
Fair enough, I do agree that it's certainly interesting from a technical perspective. But in general, I would stand by my claim that you don't really want to use these because they just don't work in a lot of places–either they won't render, or URL detection won't work and you can't click on the link, or they'll annoy people who use screenreaders…
> (or even convey: it's "foo.tel but the 'tel' is small for some reason?")
I think you misunderstand.
The small, single character tel, and the large, 3 character tel are interpreted the same by the browser when sending a request to look up the domain. So you don't need to tell people that they have to type the single tel character.
I also don't think the author is super serious about recommending doing it:
> Is this useful?
> Obviously yes. This may be the most important discovery of the decade. You get cool looking URls and get to save a couple of characters on specific domains, at the minor expense of working inconsistently.
I think you misunderstand.
The small, single character tel, and the large, 3 character tel are interpreted the same by the browser when sending a request to look up the domain. So you don't need to tell people that they have to type the single tel character.
I also don't think the author is super serious about recommending doing it:
> Is this useful?
> Obviously yes. This may be the most important discovery of the decade. You get cool looking URls and get to save a couple of characters on specific domains, at the minor expense of working inconsistently.
Also the last thing we want is making users accustomed to weird characters in URLs, after years of trying to preach: "anything out of ordinary - be suspicious!"
That doesn't work anyways. Define "out of ordinary".
If it were possible to detect things "out of ordinary" "just like that", we'd have computers protect users from all of those things.
If it were possible to detect things "out of ordinary" "just like that", we'd have computers protect users from all of those things.
Not implementing the feature described in TFA sounds rather trivial. I'd dream for other problems to be as trivially-solvable as "not doing something".
I think if i was to implement this it'd be purely for marketing/styling purposes, and making sure to register the plaintext equivalent aswell and setup redirects for everything.
That way i could for example display the canonical domain in blackletter but also keep it accessible to users, which would make for a pretty neat effect if it suits the brand in question.
That way i could for example display the canonical domain in blackletter but also keep it accessible to users, which would make for a pretty neat effect if it suits the brand in question.
If the filter is a whitelist then it can't. If it's a blacklist then there are so many ways round filters already (e.g. redirect the link) so this won't help much.