2017年11月 BBC 報(bào)道了一個(gè)假冒 WhatsApp 的新聞。假應(yīng)用似乎與官方應(yīng)用屬于同一個(gè)開發(fā)者名下。原來(lái)這些騙子通過(guò)在開發(fā)者名字中加入 Unicode 的非打印空格（nonprintable space），繞開驗(yàn)證。在 Google Play 維護(hù)人員發(fā)現(xiàn)之前，下載假應(yīng)用超過(guò) 100 萬(wàn)人。

Unicode 是極其有價(jià)值的標(biāo)準(zhǔn)，使得電腦、智能手機(jī)和手表，在全球范圍內(nèi)以同樣的方式顯示同樣的消息。不幸的是，它的復(fù)雜性使其成為了騙子和惡作劇者的金礦。如果像 Google 這樣的巨頭都不能抵御 Unicode 造成的基本問(wèn)題，那對(duì)小一點(diǎn)的公司來(lái)說(shuō)，這可能就像是必輸?shù)膽?zhàn)役了。然而，大多數(shù)這些問(wèn)題都是圍繞著幾個(gè)漏洞利用的。以下是關(guān)于 Unicode 所有開發(fā)者都應(yīng)該知道的前五件事，并用來(lái)防止欺詐。

1. 很多 Unicode 代碼點(diǎn)是不可見的

Unicode 中有一些零寬度代碼點(diǎn)，例如零寬度連接器（U+200D）和零寬度非連接器（U+200C），它們都暗示了連字符工具。零寬度代碼點(diǎn)對(duì)屏幕顯示沒有可見的影響，但是它們?nèi)詴?huì)影響字符串比較。這也是假 WhatApp 應(yīng)用的騙子能這么長(zhǎng)時(shí)間不被發(fā)現(xiàn)的原因。這些字符大多數(shù)都在一般標(biāo)點(diǎn)符號(hào)區(qū)（從 U+2000 到 U+206F）。一般來(lái)說(shuō)，沒有理由允許任何人在標(biāo)識(shí)符中使用這個(gè)區(qū)的代碼點(diǎn)，所以它們是最不易過(guò)濾的。但是該區(qū)域外也有部分其他不可見的特別代碼，比如蒙古文元音分隔符（U+180E）。

一般來(lái)說(shuō)，用 Unicode 對(duì)唯一性約束做簡(jiǎn)單的字符串比較，這很危險(xiǎn)的。有一個(gè)可能的解決方法，限制允許用作標(biāo)識(shí)符及其他任何能被騙子濫用的數(shù)據(jù)的字符集。不幸的是，這并非該問(wèn)題的徹底解決方法。

2. 很多代碼點(diǎn)看起來(lái)很相似

Unicode 努力覆蓋全世界書寫語(yǔ)言中的所有符號(hào)，必然有很多看起來(lái)相似的字符。人類甚至無(wú)法把它們區(qū)分開來(lái)，但是電腦能毫不費(fèi)力地識(shí)別出差別。對(duì)這個(gè)問(wèn)題的一種令人驚訝的濫用是擬態(tài)（Mimic）。擬態(tài)是一項(xiàng)有趣的應(yīng)用，將軟件開發(fā)所使用的常見符號(hào)，例如冒號(hào)和分號(hào)，替換成相似的 Unicode 字符。這能在代碼編譯工具中制造混亂，留下一臉懵逼的開發(fā)者。

相似符號(hào)帶來(lái)的問(wèn)題，遠(yuǎn)不止是簡(jiǎn)單的惡作劇?；ㄉ诘慕蟹ㄊ?homomorphic attacks（同態(tài)攻擊）。利用這些漏洞，會(huì)導(dǎo)致嚴(yán)重的安全問(wèn)題。在 2017 年 4 月，一位安全研究員通過(guò)混合不同字符集中的字母，成功地注冊(cè)了一個(gè)看起來(lái)與 apple.com 非常相似的域名，甚至為它拿到了 SSL 證書。各大瀏覽器都愉快地顯示了 SSL 掛鎖，將該域名列為安全域名。

與混合可見字符和不可見字符相似，沒有道理允許標(biāo)識(shí)符，尤其是域名，使用混合字符集名。大多數(shù)瀏覽器已經(jīng)采取了行動(dòng)，將混合字符集域名顯示為十六進(jìn)制的 unicode 值以對(duì)其進(jìn)行處罰，這樣用戶就不會(huì)輕易地被迷惑。如果你向用戶顯示標(biāo)識(shí)符，比如說(shuō)在搜索結(jié)果中，考慮類似的方法來(lái)避免混淆。但是，這也不是完美的解決方法。某些域名可以輕易地用一個(gè)非拉丁字符集中的單單一個(gè)區(qū)來(lái)構(gòu)建，比如 ap.com 或者 chase.com。

Unicode 協(xié)會(huì)出版了一張易混淆字符表，可能作為自動(dòng)檢查潛在詐騙的好參考。另一方面，如果你想找一個(gè)快速創(chuàng)造疑惑的方法，看看Shapecatcher吧。它是一個(gè)奇妙工具，列舉了視覺上像圖畫的 Unicode 符號(hào)。

3. 規(guī)范化并不那么規(guī)范

規(guī)范化對(duì)像用戶名這樣的標(biāo)識(shí)符來(lái)說(shuō)非常重要，幫助人們用不同的方法輸入值，但是用一致的方法來(lái)處理。規(guī)范標(biāo)識(shí)符的一個(gè)常見方法是把所有字符都轉(zhuǎn)變成小寫，確保 JamesBond 和 jamesbond 是一樣的。

因?yàn)橛腥绱硕嗟南嗨谱址徒徊婕?，不同的語(yǔ)言或者 unicode 處理庫(kù)，可能應(yīng)用不同的規(guī)范化策略。如果在若干地方進(jìn)行了規(guī)范化，會(huì)潛在地帶來(lái)安全風(fēng)險(xiǎn)。簡(jiǎn)單來(lái)說(shuō)，不要假設(shè)小寫轉(zhuǎn)換在應(yīng)用軟件中的不同部分是一樣的。來(lái)自 Spotify 的 Mikael Goldmann 在他們的一名用戶發(fā)現(xiàn)了一個(gè)盜用賬戶的方法后，于 2013 年針對(duì)這個(gè)問(wèn)題寫了一份事件分析。攻擊者可以注冊(cè)其他人用戶名的變體，比如 BIGBIRD，會(huì)轉(zhuǎn)換成標(biāo)準(zhǔn)的賬戶名 bigbird。該應(yīng)用軟件的不同層對(duì)單詞的規(guī)范化不同，使得人們能夠注冊(cè)模仿賬號(hào)，而重置目標(biāo)賬戶的密碼。

4. 屏幕顯示長(zhǎng)度和內(nèi)存大小無(wú)關(guān)

使用基礎(chǔ)拉丁字符集和大多數(shù)歐洲字符集時(shí)，一段文本在屏幕或者紙上所占的空間大致與符號(hào)數(shù)成比例，大致與文本的內(nèi)存大小成比例。這也是 EM 和 EN 成為流行長(zhǎng)度單位的原因。但使用 Unicode 時(shí)，像這樣任何種類的假設(shè)都會(huì)變得危險(xiǎn)。有像 Bismallah Ar-Rahman Ar-Raheem (U+FDFD)這樣可愛的字符，單單一個(gè)字符就比大多數(shù)英文單詞都要長(zhǎng)，能夠輕易地超過(guò)網(wǎng)頁(yè)上假定的視覺外框。這意味著基于字符串字符長(zhǎng)度的任何種類的自動(dòng)換行，或者文本中斷算法都能輕易被愚弄。大多數(shù)終端程序要求固定寬度的字體，所以在這些程序中顯示的話，你會(huì)看到右引號(hào)完全標(biāo)在了錯(cuò)誤的位置上。

該問(wèn)題一種濫用是 zalgo 文本生成器，它在一段文本周圍加上垃圾，讓這些東西占據(jù)了更多的垂直空間。

當(dāng)然了，整個(gè)不可見代碼點(diǎn)的問(wèn)題導(dǎo)致屏幕長(zhǎng)度和內(nèi)存大小無(wú)關(guān)。所以與輸入?yún)^(qū)恰好合適的東西可能長(zhǎng)到能摧毀一個(gè)數(shù)據(jù)庫(kù)區(qū)。過(guò)濾不可見字符來(lái)規(guī)避問(wèn)題還不夠，因?yàn)檫€有很多不占用它們自己空間的其他例子。

混合占據(jù)前一個(gè)字母上的空間的拉丁字符（比如U+036B 和 U+036C），這樣你能在一行文本行中寫多行文本（Nu036BOu036C 產(chǎn)生 N?O?）。吟誦標(biāo)記是用來(lái)示意吟唱希伯來(lái)圣經(jīng)經(jīng)文的語(yǔ)調(diào)的。這些吟誦標(biāo)記能夠在同樣的視覺空間中無(wú)限堆疊，意味著他們能被輕易地濫用，將大量信息編寫進(jìn)屏幕上的一個(gè)字符空間。Martin Kleppe 用吟誦標(biāo)記為瀏覽器編碼了Conway’s Game of Life 的實(shí)現(xiàn)?？纯丛擁?yè)面的源代碼吧，你會(huì)感到震驚的。

5. Unicode 遠(yuǎn)不止是被動(dòng)數(shù)據(jù)

有些代碼點(diǎn)是用來(lái)影響輸出字符的顯示方式的，意味著用戶不僅可以復(fù)制粘貼數(shù)據(jù)，也能鍵入處理指令。一個(gè)常見惡作劇是，使用右到左覆蓋（U+202E）來(lái)轉(zhuǎn)變文本方向。例如，用谷歌地圖搜索 Ninjas。該查詢字符串實(shí)際上轉(zhuǎn)換了搜索單詞的方向，盡管頁(yè)面上的搜索區(qū)域顯示著“ninjas”，但是實(shí)際上搜索的是“sajnin”。

這種漏洞利用非常流行，XKCD漫畫網(wǎng)站上有一張相應(yīng)漫畫。

混合數(shù)據(jù)和處理指令——可有效執(zhí)行的代碼——不是個(gè)好主意，尤其是如果用戶可以直接鍵入。這對(duì)任何在頁(yè)面顯示中包括的用戶鍵入來(lái)說(shuō)都是大問(wèn)題。大多數(shù)網(wǎng)頁(yè)開發(fā)者知道通過(guò)移除 HTML 標(biāo)簽來(lái)清理用戶鍵入，但是也需要注意鍵入中的 Unicode 控制字符。這是個(gè)應(yīng)對(duì)任何臟話或者內(nèi)容過(guò)濾器的簡(jiǎn)單方法——只要把單詞倒轉(zhuǎn)過(guò)來(lái)，在開始加上右到左覆蓋。

右到左（Right-to-left）hack 可能無(wú)法嵌入惡意代碼，但是如果你不小心的話，它能擾亂內(nèi)容或者翻轉(zhuǎn)整個(gè)頁(yè)面。抵御這個(gè)問(wèn)題，常見方法是把用戶提供的內(nèi)容放進(jìn)一個(gè)輸入?yún)^(qū)域或者文本區(qū)域，這樣處理指令不會(huì)影響頁(yè)面。

處理指令對(duì)顯示的另一個(gè)特別問(wèn)題是字型變換選取器。為了避免為每種顏色的 emoji 創(chuàng)造單獨(dú)的代碼，Unicode 允許使用字型變換選取器來(lái)混合基本符號(hào)和顏色。白旗，字型變換選取器和彩虹正常會(huì)產(chǎn)生彩虹顏色的旗。但是并不是所有變換都可行。在 2017 年1 月，iOS unicode 處理中的一個(gè) bug 允許惡作劇者，僅僅發(fā)送一條特制信息就遠(yuǎn)程導(dǎo)致 iPhone 癱瘓。該信息包括白旗，字型變換選取器和一個(gè)零。iOS CoreText 陷入了恐慌模式，想要挑出正確的變換，導(dǎo)致了 OS 的癱瘓。這個(gè)惡作劇在直接信息，群聊甚至分享聯(lián)系人名片中都奏效。這個(gè)問(wèn)題也影響了 iPad，甚至部分 MacBook。該惡作劇針對(duì)的目標(biāo)人群，面對(duì)系統(tǒng)崩潰，無(wú)能為力。

相似的 bug 每幾年就發(fā)生一次。在 2013 年，出現(xiàn)了一個(gè)阿拉伯字符處理 bug，它能使 OSX 和 iOS 崩潰。所有這些 bug 都深深埋藏在 OS 文本處理模塊里，所以典型客戶端應(yīng)用開發(fā)者根本無(wú)法躲開它們。