本地化消息中可能存在的安全風險

如果Web應用程序允許用戶提供翻譯消息以將應用程序本地化爲給定的語言或語言環境，那麼涉及的潛在安全風險是什麼。 [除了顯而易見的社交工程]本地化消息中可能存在的安全風險

這些翻譯消息通常是某種格式的鍵值對的集合，具體取決於語言/庫等。例如，許多OSS中的PHP數組文件PHP應用程序，使用gettext的應用程序的getetxt .po文件，Rails中的Yaml文件等等。

這樣的翻譯數據然後用於在可用於站點的語言環境列表中提供新的語言環境。

2011-11-30 Basel Shishani

說實話，這是一個奇怪的問題。我會假設你已經閱讀並理解了OWASP top 10。我假設你知道如何保護自己的服務器免受攻擊。

在我的腦海裏，對這個翻譯系統的最明顯的攻擊是持久的XSS，這將允許攻擊者使用這個數據集來破壞每個網站。只是說「我們對價值進行了解碼」是不夠的。如果您將這些數據集提供給第三方，您不能指望它們都能正確地清理數據。更糟的是，XSS是an output problem，你不能HTML encode整個數據集，並期望它是100％安全的，因爲你不知道如何在HTML文檔中使用數據。問題是數據可能會在腳本標記或事件中結束，然後HTML編碼的保護可能完全無效。當我看到有人使用strip_tags()嘗試停止xss時，我總是輕笑，但這只是錯誤的方法。

在求和是不是真的有一個100％解決問題的辦法，但這會阻止大多數的XSS：

$var=htmlspecialchars($var,ENT_QUOTES,"UTF-8"); 
$var=rtrim($var,"\\");

顯然rtrim()被用來幫助防止腳本標籤內XSS。如果字符串以反斜槓結尾，您可以跳出引用的字符串，反斜槓與引號相同。

來源

2011-11-30 08:28:11 rook

感謝您的回答。我知道（在某種程度上）各種攻擊。這個問題沒有說明這一點，但我試圖從更廣泛的角度來看待這個問題 - 大多數（所有）應用程序的設計都假設了l10n數據的單一控制點 - 我正在考慮其他情況例如說，其中l10n數據由第三方維護並且通過CDN提供。 –

@Basel Shishani你正抓着稻草。我擔心在一天結束時，你會花太多時間處理異乎尋常的問題，這些簡單的問題會讓人們流淚。持久XSS是一個非常嚴重的漏洞，允許攻擊者引入iframe並利用瀏覽器或破壞網站。 – rook

@Basel Shishani還應該注意的是，在我已經清理的絕大多數受損網站中，攻擊者在服務器上使用複雜的遠程代碼執行，在主頁上引入一個簡單的iframe來利用瀏覽器。首頁上存儲的xss是絕大多數犯罪分子最有價值的Web應用程序漏洞。 – rook

只要您放棄對內容的控制，您就可以有效地允許任何「授權」的內容提供商向您的用戶界面添加他們想要的任何內容。即使您阻止執行內容中包含的潛在代碼，也不能阻止向用戶顯示不適當的文本（或圖像），除非您在該文本的入口點將該文本顯示在系統中。

解決此問題的一種方法是通過與內容提供商簽訂的服務合同來指定其內容驗證的義務。取決於提供者是誰，這可能足以讓你在放棄控制的情況下變得舒適。否則，在應用程序的所有者組織批准發佈之前，幾乎無法替代所有提交的內容。

來源

2011-11-30 13:42:43

我認爲可以安全地說，「新」字符串中的HTML元素只能是舊字符串中的HTML元素，減去一些特定的屬性，如title和alt。

例子：

英文字符串：Hover this message
荷蘭語翻譯：Hang hier met de muis boven - 將被標記爲安全
荷蘭語翻譯：Hang hier met de muis boven會被過濾器失效

你會不得不編寫一個相當強大的過濾器，並且始終驗證沒有屬性被添加，刪除，並且沒有HTML元素打擾或刪除。此外，請始終小心"和'。

來源

2011-11-30 15:36:56

本地化消息中可能存在的安全風險

回答

相關問題