1
用戶輸入的unicode是否存在真正的危險，這不是由用戶代理/瀏覽器等處理的？Unicode輸入危險
很明顯，從服務器到客戶端，有一個真正的欺騙威脅，但我試圖找出具體的'攻擊'（如果有的話）或對待unicode輸入時應該注意的不滿。
問題是語言不可知的，但我提出這個問題時要考慮GWT應用程序的安全含義。
A
回答
4
我能想到的幾個問題與用戶控制的unicode字符串：
- 有多種方式來表達的Unicode字符串等同。例如，
ä可以表示爲單個碼點，或者可以表示爲a，然後是組合¨。 Unicode規範化有助於抵禦大部分這些問題。 - 有允許奇怪的脫口處動作的字符。我聽說過一個聊天室，你可以將你的信息放在別人的信息上。由於管理員沒有意識到誰實際發送了所述消息，所以他們被禁止說不適當的事情。
- 有看起來相似的字符。例如，有一些俄語或希臘字符在光學上與它們的ASCII等價物無法區分。這是字符串應該唯一標識的問題。例如用戶名或域名。類似於傳統的
l與I的問題，除了差很多。 - 使用UTF-8和UTF-16，在代碼點中間拆分字符串可能會導致一些問題。
- 字符串的某些操作可能會意外更改其長度。例如，大寫一個字符串可能會使其更長。
可能有更多的問題，我肯定對Unicode的
+1
1.這不是一個真正的「危險」，只是需要考慮的事情。如果4.是一個問題，你只是沒有正確處理字符串/編碼。 5.這是需要考慮的事情，這是否「危險」取決於您的語言水平如何。我同意2和3是可能導致用戶問題的點。 – deceze 2012-04-26 11:30:55
+1
這給我帶來了一個後續問題，這些問題中有多少已經被像GWT這樣的語言/框架內部處理過了？ （例如，我正在考慮unicode標準化） – 2012-04-26 11:38:10
+1
可能有幫助函數，但您仍需要了解大多數這些問題。它們不能自動解決。 – CodesInChaos 2012-04-26 11:44:19
5
與任何用戶輸入的最大危險是使用在具有「特殊字符」一背景下，輸入沒有專家。即，將它簡單地連接成SQL查詢或將其輸出到HTML中。如果應用程序行爲的一部分受字符串（如SQL查詢或HTML頁面）控制，並且用戶可以控制這些字符串並可以注入自己的命令，那就很危險。
雖然在這方面沒有什麼特別的關於Unicode的其他編碼。您的環境中的特殊字符已定義良好，您只需對所有用戶輸入進行轉義，過濾或清理，以便將這些特殊字符呈現爲非特殊字符。這與您需要爲其他編碼所做的一樣。您需要注意您的轉義/過濾/清理功能知道正確的編碼，以便他們可以正確地完成他們的工作。
除此之外，Unicode編碼的文本就是文本。當你中性化任何特殊字符並且正確處理編碼時，在文本中沒有危險。除了你的用戶sbuıɥʇpɹıǝʍbuıʇıɹʍ或利用類似人物的特定用途，但這不是廣義的危險了。
*輸出*用戶控制的unicode字符串可能非常成問題。但是我沒有看到很多輸入問題。 – CodesInChaos 2012-04-26 11:04:45
輸出用戶控制的unicode會遇到什麼樣的問題？ – 2012-04-26 11:09:34