2014-09-19 60 views
1

我正在開發一個代碼遊戲類型的應用程序,用戶(web開發人員/設計師)可以輸入HTML,CSS和Javascript並在iframe上查看結果。輸入的代碼將被保存在數據庫(MySQL)中,並在show_results視圖/操作中的iframe中再次呈現。在數據庫中保存用戶創建的javascript是否安全?

現在的問題:是否安全地直接在數據庫中保存javascripts?如果不是,那麼我應該如何保存它?

+4

將JS存儲在任何數據庫中是安全的。當您檢索該JS並將其呈現爲「

1

數據庫不會是你的問題在這裏。使用預準備語句來允許將各種字符安全地存儲在數據庫中是相當簡單的。使用除準備語句之外的任何內容來存儲用戶輸入是不夠的,並且基本上從未被推薦

但你說的是允許任意的javascript被執行,這總是會成爲一個安全問題。正如上面的評論者所暗示的那樣,您將會複製jsfiddle.net的複雜性,而沒有安全體驗,開發知識或明確希望修補不斷出現的漏洞。

當然,你應該知道你在做什麼會完全危害你設置的任何域,所以基本上這個JavaScript應該只寫在你不使用的一次性域或子域上爲任何其他目的。當然,在這樣的環境下,這只是微不足道的,只需簡單地構建幀並將觀看者從託管該幀的站點拉出即可。

我敢肯定,這只是抓住了潛在濫用的表面,即任意JavaScript執行(又名有意的自我跨站點腳本)會帶來它。

既然你基本上正在用這個概念重新發明一個非常危險的車輪,爲什麼不簡單地使用一些已經存在的嵌入服務呢?例如,codepen.io允許你嵌入它的片段。

+0

我正在構建一個應用程序,該應用程序使用「代碼遊樂場應用程序」背後的技術規定,用於完全不同的目的。 Codepen和CSSdeck非常棒,我同意你的觀點。我願意接受潛在的XSS攻擊,並對其進行修補,並繼續在我的項目中學習。如果你可以建議我寫作,最佳實踐和地方開始/參考?提前致謝! – marvindanig 2014-09-19 19:15:11

+1

那麼,你在說什麼(除了使用預處理語句之後不會過於複雜的保存方面),所有客戶端都是這樣,所以只需複製jsfiddle或codepen或cssdeck,以最接近您實際需要的爲準,並從那裏完善。只要確保檢查它的服務器標題,並嘗試複製那些看起來很有必要的東西。祝你好運。 – Kzqai 2014-09-21 14:13:42

1

是的,如果您在客戶端執行javascript,則它作爲架構決策是安全的。

在任何網站上,您都可以使用諸如chrome的「檢查元素」等工具來操作客戶端上的html,javascript等。您的系統不能假定客戶端上的項目未被操縱。這就是爲什麼服務器端驗證仍然如此重要。

我完全不同意kzqai。 如果是這樣的話,那麼小提琴手就會陷入嚴重的困境。

存在潛在的問題,可以更容易地暴露與你在做什麼,但這些問題已經存在,只是晦澀難懂。

IFF你在服務器端執行javascript,這是一個非常複雜的決定。如果可能的話,我會親自避免它,因爲你玩的遊戲是你能夠抓住每一個可能的場景來解決麻煩,而一個壞人能夠抓住你沒有的那個。

+0

你基本上說在服務器端執行javascript時要非常小心,因爲這是一個非常複雜的決定,但後來說在客戶端執行它就好,完全沒有問題。唯一的區別是誰受傷。服務器端它是你的服務器,客戶端是你的用戶。如果您認爲jsfiddle是開發人員完全可以「設置並忘記它」的事情,而不必爲了客戶端而不斷修補新的攻擊途徑,那麼您只是不知道持續的攻擊的新客戶端漏洞。 – Kzqai 2014-09-21 14:17:31

+0

情況並非如此。 我同意客戶端JavaScript可能會導致問題。但是,您永遠不能相信Web環境中的任何類型的javascript都不會在客戶端執行。事實上,你必須承擔相反的事情。例如,可以說未來會出現新的威脅。威脅被利用與客戶端下面的JavaScript代碼: 功能beBad(){ .. } 你不能說「嗯,我們是很好的,因爲我們沒有這樣的代碼」。相反,你必須說明並執行IT將被執行的事實。因此,您需要正確處理該威脅。 – vereecjw 2014-09-26 16:11:57

+0

通過這種邏輯,允許任意的javascript被存儲在數據庫中並在客戶端上執行本身不是安全威脅。 更具體的例子是: 假設數據可用IFF你有一個安全令牌。 每個用戶都有自己的令牌。 您保存的JavaScript允許其他用戶訪問。 令牌允許訪問的數據被認爲是機密的(讓我們只是說身份信息) 允許javascript訪問該令牌顯然是致命的,因爲它們可以輕鬆捕獲和傳輸令牌,從而授予訪問權限。 – vereecjw 2014-09-26 16:12:33

相關問題