Timeline for Are Cyrillic characters a real threat?
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 6 at 23:38 | vote | accept | Gatonito | ||
| Mar 28 at 22:30 | comment | added | Joshua | @R..GitHubSTOPHELPINGICE: Hmmm; it's almost like it wants to be compare equal by glyph rather than by codepoint, but it's a little hard to define because similar glyphs isn't quite defined. | |
| Mar 15 at 11:43 | comment | added | IMSoP | @Nelson Nitpick: there is no such thing as "a two-byte character" in this context, or a single hex representation. In the context of the URL, it will be encoded using "punycode", which encodes the position as well as the character, so you can't say "Cyrillic а will always be these bytes". In the context of the browser's UI, it's likely it will be translated to UTF-8, or maybe UTF-16, but could be any representation that will pick the right letter from the font. That's why it's more useful in these cases to refer to the Unicode code point numbers, as the edited answer does. | |
| Mar 15 at 0:15 | comment | added | prosfilaes | @EvilSnack Part of the problem is no one agrees on which Cyrillic letters look like Latin characters. It depends on fonts used and how sensitive the user is. Letters к and ш are major examples. Also, I and l look quite similar in this font, and 0 and O are frequently confusables, without even leaving Latin. | |
| Mar 14 at 16:02 | comment | added | phuclv | @ReverentLapwing Greek Α, Β, Ε are far more similar to A, B, E than their lowercase counterparts, so an attack in Greek should be in uppercase | |
| Mar 14 at 15:39 | comment | added | supercat | @EvilSnack: Security certificates are domain-specific, and a browser would need to do a fair amount of work to securely determine whether the certificates for homoglyph domains are issued by the same entity. | |
| Mar 14 at 14:14 | comment | added | R.. GitHub STOP HELPING ICE | @EvilSnack: "People with some languages have to register the wrong characters in their domain because my language is more important" is not a defensible policy. It's a non-starter. | |
| Mar 14 at 13:17 | history | edited | Steffen Ullrich | CC BY-SA 4.0 |
added 18 characters in body
|
| S Mar 14 at 10:43 | history | edited | Steffen Ullrich | CC BY-SA 4.0 |
add that they can look identical depending on the font
|
| S Mar 14 at 10:43 | history | suggested | ratchet freak | CC BY-SA 4.0 |
add that they can look identical depending on the font
|
| Mar 14 at 10:34 | review | Suggested edits | |||
| S Mar 14 at 10:43 | |||||
| Mar 13 at 23:19 | comment | added | EvilSnack | @MilesBudnek Not if the URLs created by the mapping are pointed to the same DNS as the legit URL. | |
| Mar 13 at 22:05 | comment | added | Miles Budnek |
@EvilSnack That could then create a homograph attack in the other direction. Now Ukrainian users will get sent to the wrong place when they try to visit приклад.com because the Cyrillic а got mapped to an ASCII a. You can't just say it applies in all cases, because domain names containing Cyrillic characters have already been registered; it's too late to implement a rule that all homoglyphs have to be normalized to ASCII in domain names.
|
|
| Mar 13 at 20:12 | comment | added | Reverent Lapwing | The same is true of Greek alphabet, 'α' is very similar to 'a'. | |
| Mar 13 at 17:00 | comment | added | EvilSnack | @R..GitHubSTOPHELPINGICE Leaving out intent, then, it's clear that some Cyrillic letters look exactly like a Latin character. Mapping the Cyrillic characters that resemble Latin characters would prevent links that look like www.adobe.com from going anywhere but www.adobe.com . I admit that there would be a lot of complexities (legitimate Russian sites would need DNS entries for the mapped versions of their URLs), and also it's not a panacea, but it would help. | |
| Mar 13 at 16:30 | comment | added | Joshua | It's kind of uniquely problematic with cyrillic and domain names due to enough homographs existing to make one of all cyrillic characters for quite a few important US company names and thus not trip the homeograph attack detector. | |
| Mar 13 at 15:57 | comment | added | Steffen Ullrich | @EvilSnack: how to protect depends on the context where the attack is used. For homographs used to hide words in mails against spam detection such mapping might be used - or one might simply consider the mail as more spam-like if homographs are detected. As for homographs in links (IDN) see How to defend against homograph attacks. | |
| Mar 13 at 15:56 | comment | added | R.. GitHub STOP HELPING ICE | The real best-practices way to guard against homograph attacks is to accentuate any discrepancy between scripts (alphabets/writing systems) within a single word in displaying fields where they are a risk. For example a process displaying the above "exаmple" could highlight the "а", show it as "ex<U+0430>mple", or in the case of DNS labels, leave it in punycode rather than decoding it when there are labels with mixed scripts present. | |
| Mar 13 at 15:52 | comment | added | R.. GitHub STOP HELPING ICE | @EvilSnack: I'm not sure exactly what you mean but it sounds like you haven't thought that through. You can't remap anything based on "intent" because intent is not an input parameter you have access to. | |
| Mar 13 at 14:46 | comment | added | EvilSnack | Could attacks of this nature be defeated by mapping homographs to the character they are intended to resemble before resolving the DNS address? | |
| Mar 13 at 13:39 | comment | added | Nelson |
In case people cannot see the difference, the first a is just standard a, ascii character 61, but the second one is actually a two-byte character that literally looks exactly the same, but has hex code of 0xd0 0xb0
|
|
| Mar 13 at 5:01 | history | edited | Steffen Ullrich | CC BY-SA 4.0 |
added 89 characters in body
|
| Mar 13 at 4:54 | history | answered | Steffen Ullrich | CC BY-SA 4.0 |