Re:How can you be fooled by the U+202E trick? (2013)
by klabb3 on Wednesday February 16, 2022 @01:00AM
(#30356828)
I think you're right about paths but aside from that we have website urls, usernames or similar identifiers.. People look at those and assume that they can compare them. If I see `google.com` I assume it consists of certain characters that represent a specific institution. Are we doomed to live with ascii for the forseeable future or is there some form of reduced set of unicode that we can use without these types of impersonation attacks?
Re:How can you be fooled by the U+202E trick? (2013)
by BoorishBears on Wednesday February 16, 2022 @04:42AM
(#30357992)
you shouldn't get away with an IDN Homograph attack in any modern browser
They just turn your url into punycode, and more recently display that instead of the raw url: https://en.m.wikipedia.org/wiki/Punycode
Re:How can you be fooled by the U+202E trick? (2013)
by account42 on Wednesday February 16, 2022 @09:47AM
(#30360605)
> and more recently display that instead of the raw url
Technically, punicode is the raw URL and old enough browsers will display all non-ASCII domains as punycode. It was only for a short while that browsers naively decoded punicode without restrictions.
Re:How can you be fooled by the U+202E trick? (2013)
by staticassertion on Wednesday February 16, 2022 @01:10AM
(#30356866)
That's basically why Google wants to get rid of urls. They're terrible at conveying trust.
Re:How can you be fooled by the U+202E trick? (2013)
by toomanydoubts on Wednesday February 16, 2022 @01:26AM
(#30356926)
>That's basically why Google wants to get rid of urls.
Wink-wink ;)
Re:How can you be fooled by the U+202E trick? (2013)
by rightbyte on Wednesday February 16, 2022 @02:09AM
(#30357151)
Google want you to search on Google to see ads and be spied upon, not use a direct url.
Re:How can you be fooled by the U+202E trick? (2013)
by cryptonector on Wednesday February 16, 2022 @01:30AM
(#30356952)
There are certainly things that can be done. UTR #36 covers some of the things that can be done.
Besides refusing to render U+202E when it is between characters of scripts that aren't bi-directional and flow in the same direction, the UI could display the string in ways that make it clear (e.g., different color, maybe add a warning tooltip, maybe add a dialog around an operation that could be dangerous, or maybe refuse to perform dangerous operations).
Re:How can you be fooled by the U+202E trick? (2013)
by account42 on Wednesday February 16, 2022 @09:50AM
(#30360651)
Another option for filenames would be to recognize that the basename and extensions are distinct parts and the extension should always be displayed after the basename no matter what is in the basename. Of course, this adds lots of complexity so ¯\_(ツ)_/¯
Re:How can you be fooled by the U+202E trick? (2013)
by cryptonector on Wednesday February 16, 2022 @10:21AM
(#30361076)
Problem is that there's cases like foo.tar.gz. What's the extension there?
The problem is honestly just that unicode is used to convey things like "this is a PDF" or "this is going to execute code" and it's attacker controlled. It's a terrible UX that's been abused for as long as paths have existed.
So I guess hope that operating systems will find a better UX for "this executes" and that they'll stop "a process executed" from being a game over situation for users.