4 ms·

so.... in theory you should be able to create several visually identical links that give access to different resources? I've always assumed links without any t

by nzach 2y ago

so.... in theory you should be able to create several visually identical links that give access to different resources? I've always assumed links without any tracking information (unique hash, query params, etc) were safe to click(with regards to my privacy). but if this works for links I may need to revise my strategy regarding how to approach links sent to me.

dmbche 2y ago
You need to decode the text after copy pasting it, I believe clicking on text will not interact with the obfuscated data since your computer will just find the unicode and ignore the obfuscated data. This is just so that you can hide data and send it to someone to be decoded (or watermarking as mentionned)
- nzach 2y ago
  yes, I understand this is not a security risk. but my fear is precisely that I my be sending data to a remote host while I'm completely unaware of this fact. I tried to create a POC with some popular url shortner services, but doesn't seems to work. what I wanted to create was a link like <host.tld>/innoc󠅥󠅣󠅕󠅢󠄝󠅙󠅔󠄪󠅑󠅒󠅓ent that redirects to google.com. in this case the "c" contains some hidden data that will be sent to the server while the user is not aware. this seems possible with the correct piece of software.
cess11 2y ago
HTML entity encoding will show the hidden content, try with https://mothereff.in/html-entities https://mothereff.in/html-entities.
cscheid 2y ago
My understanding is that "weird" unicode code points become https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode. I used the 󠅘󠅕󠅜󠅜󠅟 (copy-pasted from the post, presumably with the payload in it) to type a fake domain into Chrome, and the Punycode I got appeared to not have any of the encoding bits. However, I then pasted the emoji into the _query_ part of a URL. I pointed it to my own website, and sure enough, I can definitely see the payload in the nginx logs. Yikes. Edit: I pasted the very same Emoji that 'paulgb used in their post before the parenthetical in the first paragraph, but it seems HN scrubs those from comments.
- bmicraft 2y ago
  domains get "punycode" encoded, urls get "url encoded"[1], which should make unicode characters stand out. That being said, browsers do accept some non-ascii characters in urls and convert them automatially, so theoretically you could put "invalid" characters into a link and have the browser convert it only after clicking. That might be a viable strategy. [1] https://www.w3schools.com/tags//ref_urlencode.asp https://www.w3schools.com/tags//ref_urlencode.asp
- echeese 2y ago
  The emoji is gone but the content is still there.
riquito 2y ago
> I've always assumed links without any tracking information (unique hash, query params, etc) were safe to click(with regards to my privacy). but if this works for links I may need to revise my strategy regarding how to approach links sent to me. Well, it was never safe, what you see and where the link are pointing at are different things, that's why the actual link is displayed at the bottom left of your browser when you move your mouse over it (or focus it via keyboard)
layer8 2y ago
URIs with non-ASCII characters are technically invalid. Browsers and the like should (but likely don’t all do) percent-encode any invalid characters for display if they accept such invalid URIs.
password4321 2y ago
This tool and idea sketchy AF: https://github.com/zws-im/zws https://github.com/zws-im/zws ("Shorten URLs using invisible spaces")
kccqzy 2y ago
"Visually identical" is never good enough. Have you heard of attacks confusing Latin letters and Cyrillic letters? For example C versus С. (The latter is known as CYRILLIC CAPITAL LETTER ES.) Have you heard of NFC forms versus NFD forms? For example é versus é (LATIN SMALL LETTER E + COMBINING ACUTE ACCENT versus LATIN SMALL LETTER E WITH ACUTE.) Nothing that's important when it comes to security and privacy should rely on a "visually identical" check. Fortunately browsers these days are already good at this; their address bars use puny code for the domain and percent encoding for the rest of the URL.
- komboozcha 2y ago
  Erm, DNS uses Punycode because it comes from a time when Unicode didn't exist, and bind assumes a grapheme has no more than one byte.
  - ale42 2y ago
    Yes but I guess that the message was meaning that browsers now detect homographs and display the punycode instead. See also https://news.ycombinator.com/item?id=14130241 https://news.ycombinator.com/item?id=14130241; at that time Firefox wasn't fixed, but in the meantime it fixed the issue too (there's a network.idn.punycode_cyrillic_confusables preference, which is enabled by default).
- moody__ 2y ago
  As the sibling comment has mentioned Unicode in DNS uses a punycode encoding but even further then that the standard specifies that the Unicode data must be normalized to NFC[0] before being converted to punycode. This means that your second example (decomposed e with combining acute accent vs the composed variant) is not a valid concern. The Cyrillic one is however. [0] https://www.rfc-editor.org/rfc/rfc5891 https://www.rfc-editor.org/rfc/rfc5891 § 4.1 "By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C"
  - kccqzy 2y ago
    The OP said link. The NFC/NFD issue remains if these are part of a path name or query parameter.

by nzach 2y ago

dmbche 2y ago

You need to decode the text after copy pasting it, I believe clicking on text will not interact with the obfuscated data since your computer will just find the unicode and ignore the obfuscated data. This is just so that you can hide data and send it to someone to be decoded (or watermarking as mentionned)

nzach 2y ago
yes, I understand this is not a security risk. but my fear is precisely that I my be sending data to a remote host while I'm completely unaware of this fact. I tried to create a POC with some popular url shortner services, but doesn't seems to work. what I wanted to create was a link like <host.tld>/innoc󠅥󠅣󠅕󠅢󠄝󠅙󠅔󠄪󠅑󠅒󠅓ent that redirects to google.com. in this case the "c" contains some hidden data that will be sent to the server while the user is not aware. this seems possible with the correct piece of software.

cess11 2y ago

HTML entity encoding will show the hidden content, try with https://mothereff.in/html-entities https://mothereff.in/html-entities.

cscheid 2y ago

My understanding is that "weird" unicode code points become https://en.wikipedia.org/wiki/Punycode https://en.wikipedia.org/wiki/Punycode. I used the 󠅘󠅕󠅜󠅜󠅟 (copy-pasted from the post, presumably with the payload in it) to type a fake domain into Chrome, and the Punycode I got appeared to not have any of the encoding bits. However, I then pasted the emoji into the _query_ part of a URL. I pointed it to my own website, and sure enough, I can definitely see the payload in the nginx logs. Yikes. Edit: I pasted the very same Emoji that 'paulgb used in their post before the parenthetical in the first paragraph, but it seems HN scrubs those from comments.

bmicraft 2y ago
domains get "punycode" encoded, urls get "url encoded"[1], which should make unicode characters stand out. That being said, browsers do accept some non-ascii characters in urls and convert them automatially, so theoretically you could put "invalid" characters into a link and have the browser convert it only after clicking. That might be a viable strategy. [1] https://www.w3schools.com/tags//ref_urlencode.asp https://www.w3schools.com/tags//ref_urlencode.asp
echeese 2y ago
The emoji is gone but the content is still there.

riquito 2y ago

> I've always assumed links without any tracking information (unique hash, query params, etc) were safe to click(with regards to my privacy). but if this works for links I may need to revise my strategy regarding how to approach links sent to me. Well, it was never safe, what you see and where the link are pointing at are different things, that's why the actual link is displayed at the bottom left of your browser when you move your mouse over it (or focus it via keyboard)

layer8 2y ago

URIs with non-ASCII characters are technically invalid. Browsers and the like should (but likely don’t all do) percent-encode any invalid characters for display if they accept such invalid URIs.

password4321 2y ago

This tool and idea sketchy AF: https://github.com/zws-im/zws https://github.com/zws-im/zws ("Shorten URLs using invisible spaces")

kccqzy 2y ago

"Visually identical" is never good enough. Have you heard of attacks confusing Latin letters and Cyrillic letters? For example C versus С. (The latter is known as CYRILLIC CAPITAL LETTER ES.) Have you heard of NFC forms versus NFD forms? For example é versus é (LATIN SMALL LETTER E + COMBINING ACUTE ACCENT versus LATIN SMALL LETTER E WITH ACUTE.) Nothing that's important when it comes to security and privacy should rely on a "visually identical" check. Fortunately browsers these days are already good at this; their address bars use puny code for the domain and percent encoding for the rest of the URL.

komboozcha 2y ago
Erm, DNS uses Punycode because it comes from a time when Unicode didn't exist, and bind assumes a grapheme has no more than one byte.
- ale42 2y ago
  Yes but I guess that the message was meaning that browsers now detect homographs and display the punycode instead. See also https://news.ycombinator.com/item?id=14130241 https://news.ycombinator.com/item?id=14130241; at that time Firefox wasn't fixed, but in the meantime it fixed the issue too (there's a network.idn.punycode_cyrillic_confusables preference, which is enabled by default).
moody__ 2y ago
As the sibling comment has mentioned Unicode in DNS uses a punycode encoding but even further then that the standard specifies that the Unicode data must be normalized to NFC[0] before being converted to punycode. This means that your second example (decomposed e with combining acute accent vs the composed variant) is not a valid concern. The Cyrillic one is however. [0] https://www.rfc-editor.org/rfc/rfc5891 https://www.rfc-editor.org/rfc/rfc5891 § 4.1 "By the time a string enters the IDNA registration process as described in this specification, it MUST be in Unicode and in Normalization Form C"
- kccqzy 2y ago
  The OP said link. The NFC/NFD issue remains if these are part of a path name or query parameter.