Insufficient Visual Distinction of Homoglyphs Presented to User
The software displays information or identifiers to a user, but the display mechanism does not make it easy for the user to distinguish between visually similar or identical glyphs (homoglyphs), which may cause the user to misinterpret a glyph and perform an unintended, insecure action.
Some glyphs, pictures, or icons can be semantically distinct to a program, while appearing very similar or identical to a human user. These are referred to as homoglyphs. For example, the lowercase "l" (ell) and uppercase "I" (eye) have different character codes, but these characters can be displayed in exactly the same way to a user, depending on the font. This can also occur between different character sets. For example, the Latin capital letter "A" and the Greek capital letter "Α" (Alpha) are treated as distinct by programs, but may be displayed in exactly the same way to a user. Accent marks may also cause letters to appear very similar, such as the Latin capital letter grave mark "À" and its equivalent "À" with the acute accent.
Adversaries can exploit this visual similarity for attacks such as phishing, e.g. by providing a link to an attacker-controlled hostname that looks like a hostname that the victim trusts. In a different use of homoglyphs, an adversary may create a back door username that is visually similar to the username of a regular user, which then makes it more difficult for a system administrator to detect the malicious username while reviewing logs.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
The following looks like a simple, trusted URL that a user may frequently access.
However, the URL above is comprised of Cyrillic characters that look identical to the expected ASCII characters. This results in most users not being able to distinguish between the two and assuming that the above URL is trusted and safe. The "e" is actually the "CYRILLIC SMALL LETTER IE" which is represented in HTML as the character е, while the "a" is actually the "CYRILLIC SMALL LETTER A" which is represented in HTML as the character а. The "p", "c", and "o" are also Cyrillic characters in this example. Viewing the source reveals a URL of "http://www.еxаmрlе.соm". An adversary can utilize this approach to perform an attack such as a phishing attack in order to drive traffic to a malicious website.
The following displays an example of how creating usernames containing homoglyphs can lead to log forgery.
Assume an adversary visits a legitimate, trusted domain and creates the account "admin" where the 'a' and 'i' characters are Cyrillic characters instead of the expected ACII. Any actions the adversary performs will be saved to the log file and look like they came from a legitimate administrator account.
However, upon closer inspection, the account that generated these log entries is "аdmіn". This makes it more difficult to determine which actions were performed by the adversary and which actions were executed by the legitimate "admin" account.
Weaknesses in this category are related to or introduced in the User Interface (UI).
This view (slice) covers all the elements in CWE.
CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...
This view (slice) lists weaknesses that can be introduced during implementation.