When technologies touch and encompass the whole world, they pose challenges in integrating the vast amount of languages, mainstream and regional alike.
While English is the link language and all codes are written around it, some of the characters, say Chinese, will appear quite different.
Google’s Chrome browser realized the kind of vulnerability this issue presents and has since taken steps to rectify it.
Chinese researcher, Xudong Zheng, brought the vulnerability to Google’s attention in the third week of January 2017, that some websites can be represented in a different way using the Chinese alphabets.
The vulnerability is being described as Punycode, which is the way Unicode is represented using foreign language characters.
This vulnerability was being exploited by cyber-criminals indulging in phishing and luring the browsing public to other sites, which might not be legitimate.
Once inside, the visitors may end up divulging personal data that could be lost to the hackers.
The problem explained
The vulnerability was explained by Xudong Zheng using the URL apple.com as an example.
While one would expect the link to take you to Apple, Inc.’s website, it did not.
The URL took the visitor to https://www.xn--80ak6aa92e.com.
The reason for this vulnerability, as described above, has to do with the registration of websites, which are allowed to be done using the alphabets in their local language.
The phishing attacks are also called homograph attacks because it is the way certain English alphabets characters are represented in another language.
Google says it’s fixed now
Google acted on this vulnerability and took care of it in March in the Chrome beta version, and now they have announced that they have fixed this vulnerability.
Google now assures that the vulnerability has been solved with the latest update of Chrome 58.
It has also been announced that Google has paid the researchers for their help in identifying such a vulnerability, as would be expected noting their renowned bug bounty program.
For the record, there were also a couple of more lacunae pointed out in addition to the Punycode vulnerability, and Google has said those have also been handled in the final version out for download as well.
Contain the vulnerability during the time of Domain Registration
One group of experts feel that the vulnerability can be avoided if the problem is addressed at the domain registration stage itself.
Some experts also feel that there is no perfect solution to this issue.
This is because of the fact that each language has its own unique script and the way the language expresses certain texts.
The suggestion from Google is that the website owners should be advised to register their websites in the local or native language parallel to the main registration they obtain in English.
This will make sure the vulnerability cannot be easily exploited, even if the local customers input the URL in his or her native language.
This is easier said than done, though. After all, how can this be implemented across millions of commercial organizations being registered across the world?
Meanwhile, Mozilla’s Firefox appears to have found the solution to this vulnerability issue by introducing an adjustment in the browser’s about:config settings.
By choosing ‘true’ under “network.IDN_show_punycode”, the visitor to any website will be warned when there is an illegitimate site or URL is displayed, because the IDN domains will be shown in the Punycode form.
Security certification process needs to be upgraded
The Security certificate issue is another angle through which the problem could be addressed.
The trouble is domains continue to carry the SSL certification based on the “Common Name” field of the website.
This practice was done away with 2 years back, and the accepted practice is the Subject Alternative Name (SAN) method for listing the domain and obtaining the SSL certification.
To get around this issue, the latest Chrome 58 has ensured that the “Common Name” listing is ignored completely.
This would further reduce the vulnerability, as seen through the homograph attack possibility to a great extent.
A typical example for this type of situation is the answer “NET::ERR_CERT_COMMON_NAME_INVALID” people may get when they type in a domain name which has not followed the SAN route and is still sticking to the “Common Name” domain listing.
This indeed is even being touted as an important security change brought about in Chrome 58.
Lastly, going one step further, Google has also made a change in Chrome 58 requiring Encrypted Media Extensions (EMEs) to have HTTPS authorization.