Respectfully I think this is a minimal attack vector in this case due to the limited character set of urls. But thanks for the callout, I didn’t know there was a name for this sort of attack.
Modern browsers happily show you the actual characters, while sending their encoded entities to the server. So, from a user perspective there is no ASCII limitation. Case in point: söhne.at (just some random website, I have no idea what they are or if they are legitimate)
They’d still resolve via DNS to an address in ASCII though, right? Wouldn’t that only be an issue if ICANN didn’t have a monopoly on DNS registration? i.e what we already depend on for a semblance of convenience without totally compromising opsec
Respectfully I think this is a minimal attack vector in this case due to the limited character set of urls. But thanks for the callout, I didn’t know there was a name for this sort of attack.
Modern browsers happily show you the actual characters, while sending their encoded entities to the server. So, from a user perspective there is no ASCII limitation. Case in point: söhne.at (just some random website, I have no idea what they are or if they are legitimate)
They’d still resolve via DNS to an address in ASCII though, right? Wouldn’t that only be an issue if ICANN didn’t have a monopoly on DNS registration? i.e what we already depend on for a semblance of convenience without totally compromising opsec
It utilizes punycode under the hood. The actual DNS entries still use ASCII.
Punycode enables you to encode any Unicode character as ASCII. Almost all browsers support this.