2012-02-25 71 views
3

我正在開發一個SSO解決方案,其中有一個主認證站點和多個從站點。我處於某個人註冊的狀態,它需要將註冊轉發給主服務器,並將用戶註冊到主服務器。跨域安全地通過HTTP發送數據

有很多方法可以解決這個問題,目前我計劃加密所需的註冊/登錄數據,並將最終用戶的數據重定向到隱藏的iframe中,以便最終用戶不會爲此感到困擾過程(這將包括在網站T & C中)。現在它已經在使用SSL了,但我想盡可能地保證這個過程的安全。目前,我正在使用主設備和從設備在其配置中保存的密鑰來加密數據發送。我很擔心,雖然有人可能能夠解決這個問題,因爲關鍵始終是相同的,並且我正在考慮使用鹽以及主人必須從每個單獨的查詢從奴隸獲得的密鑰,但是這個雙打需要的HTTP查詢量。

我只是想知道我是否過度這麼做,或者我是否過於謹慎(畢竟,理論上來說SSL本身就足夠了)。

有什麼建議嗎?謝謝

回答

2

在大多數情況下,SSL應該足夠了。如果服務器的證書和私鑰安全存儲,定期檢查證書撤銷,私鑰不弱(等等......),最終用戶的瀏覽器和服務器之間的通道(以及服務器之間的通道主站和奴隸站點)將免受竊聽,防止他人看到憑證。

什麼SSL不就是認證連接的「客戶」方面,也就是任何人都知道正確的URL可以連接,進行身份驗證(冒充從站點),並獲得認證/註冊令牌(如果的提供的憑據是正確的)。這意味着,給定一個令牌,您的主服務器將無法辨別哪個站點正在執行「特權」功能。證書本身仍然受SSL保護,攻擊者仍然需要知道他們執行攻擊。 (我假定網站本身沒有其他錯誤,比如XSS漏洞或cookie管理不正確)。

這就是說,你應該用一個鍵(或字符串形式的祕密),並從從站點傳遞到主一個只有如果你需要在一個偉大的級別來管理這個網絡內部的權限(如阻止在某些網站上登錄並根據用戶的身份允許登錄其他網站,或暫時拒絕某些網站的登錄,如果其中一些網站不在您的直接控制之下並且您懷疑有妥協);如果是這種情況,我建議你看看OAuth site,它是專門爲此目的而設計的協議(您可以簡單地編寫一個允許登錄並從主服務器檢索必要數據的API)。

如果(且僅當)所有站點都受到您的直接控制,則只需使用SSL即可;管理兩組密鑰(一組用於SSL和一組用於額外加密)的負擔過重,並且服務器將使用太多的資源。只有確保瀏覽器和服務器之間使用SSL以及服務器本身之間的所有通信,才能防範網絡嗅探。

+0

在[oauth.net/code/](http://oauth.net/code/)還有一個即時可用庫的存儲庫,不需要從頭開始編寫所有的代碼。 – 2012-02-25 19:53:12

+0

感謝您的信息elgaton。我想我會停止偏執,並對SSL有一定的信心。 – Naatan 2012-02-25 20:57:30

+0

@Naatan不客氣。 – 2012-02-26 08:30:27