2013-03-05 58 views
0

當這些服務器通過我們的測試時,我的客戶站點會按照IP爲其客戶提供證書。此認證僅適用於經過測試的IP。所以我們需要成爲服務證書的人員,以便我們驗證顯示我們證書的網站確實是由我們測試的。因此,當客戶的用戶點擊證書鏈接時,他們可以相信該網站確實經過了我們的測試(該網站沒有被另一臺未經我們測試過的服務器提供服務,但聲稱是) 。

siteB.com/certificate.php?companyid=1234 &服務器ID = 4321個

過程簡化:

用戶通過看起來像這樣的鏈接指向我們的網站

  • 用戶現場A
  • 用戶單擊指向我的站點(站點B)的鏈接查看站點A的證書。
  • 我的站點,站點B需要驗證它確實是正試圖顯示由網站A.賺

最初證書站點A,我認爲$ _ SERVER變種可能有一個值來表明誰引用的服務器是,但我收到的答覆,發佈有關該問題表明,雖然該信息存儲在$ _SERVER [「HTTP_REFERER」],它是不可靠的(插件或用戶可能會修改此值)。

由於我不能依賴於此,我需要另一種方法來驗證引用的服務器是誰,他們聲稱是。我考慮使用一次性使用令牌,但是然後有效的服務器可以將令牌簡單地傳遞給客戶擁有的其他服務器(尚未經過測試),並且客戶可以通過這種方式將任意數量的服務器聲明爲被認證由我們僅以一次測試的價格(以及破壞證書的完整性)爲準。

我想知道如果這個問題是不可能做出一個萬無一失的解決方案,並且最好的可以做的是混淆不受控制的端點(客戶的服務器)意味着張貼關鍵指示他們是(例如,一個鬼鬼祟祟的客戶必須閱讀一些混亂的JavaScript,或者爲了欺騙系統而拆卸閉源客戶端程序)。

我的想法到目前爲止是這樣的(和它的可怕):


我需要做一個封閉源代碼的程序運行客戶端,可能通過Native Client這將在點擊啓動證書鏈接在客戶網站(網站A)上首先通過我的網站(網站B)驗證自己,然後打開與網站A的服務器,網站B的服務器和用戶在網站B中的三方通信線路將驗證網站A是他們自稱是誰,然後向用戶返回證書或錯誤消息,說明證書無法加載的原因(例如連接超時)。

網站B上的腳本與用戶NaCl程序的公開流將use curl獲取站點A的服務器的IP地址並進行驗證。


對我來說,這是一個非常粗的解決方案(如果它甚至是一個解決方案),雖然大多數用戶不會在意看別人的證書,讓誰做護理去赴湯蹈火的用戶(安裝並運行NaCl計劃)只是看看證書就是瘋狂。

這感覺就像一個有點愚蠢的問題,但會運行此閃存,而不是隻是作爲安全/不安全運行一個程序的NaCl?

當然,有一種更好的方式去做的這一切......

回答

2

您最好的選擇是要麼信任REFERER或使用Origin標(你需要安裝一個AJAX腳本可以投進網站使用ORIGIN)。您的服務器接收

什麼都可以很容易地通過客戶計算機是僞造的,而不是由服務器他們正在訪問(未經客戶的同意)。由於您的服務似乎是爲客戶服務的,他們沒有理由僞造證書。你會有某些插件和代理的潛在問題,但你的警告信息可以解釋這一點。

沒有這樣的東西閉源的客戶端代碼。任何人都可以簡單地反編譯或模擬運行時,所以你不會得到額外的安全性。

公鑰/私鑰也將無法正常工作(你的網站產生的事情來編碼,有問題的服務器必須使用自己的私鑰對它進行編碼,客戶端使用公鑰來檢查它)。他們仍然容易受到相同的問題:一個虛假網站可以將請求連同完美複製的標題一起轉發到真實網站進行處理。

請注意以下事項:

  • AJAX允許報頭由客戶和/或服務器進行修飾,除非其由現代瀏覽器保證(但是可以由被改變ORIGIN頭客戶有一些工作)
  • 任何標準的URL請求具有瀏覽器產生的所有頭,所以他們可以信任的(只能由客戶
  • 改變
  • 發送到客戶端計算機的任何代碼或祕密(即使編譯,混淆或其他)應視爲公共。
  • 這是不是從瀏覽器的任何請求,可以在各方面被僞造,除IP地址(甚至可以代理)
+0

太棒了!我不知道ORIGIN標題。在查詢字符串中使用ajax驗證並重定向到帶有一次性使用標記(在驗證響應中提供)的證書頁面的URL聽起來很完美。就像你說的那樣,客戶沒有理由想改變這個頭值。謝謝,戴夫! – 2013-03-05 02:12:34

+0

酷!如果你需要任何幫助編程,請告訴我。我很樂意這樣做!哈哈 – 2013-03-05 03:05:00

1

我的想法..如果可能的話,拿到證書發行服務器來創建基於該參考服務器的名稱和一個hash一個cookie salt根據另一套這是在一個動態的,但可預見的方式產生的標準,如使用一週的用戶的IP地址以及白天和小時當前分鐘(太短期間對標準的數量可能拋出會導致一些假陽性認證失敗,所以要小心)。然後,當用戶到達您的站點時,閱讀cookie的散列並將其與$_SERVER[「HTTP_REFERER」]生成的散列和預先建立的條件進行比較。這一點的不利之處在於,如果他們想成爲dicks,引用服務器可以發佈安全算法。

另一個可能更安全的選項是創建一個JavaScript應用程序,您可以將這個應用程序發送給服務器,將服務器發送到AJAX調用,然後您的服務器會根據我上面提到的相同類型的標準返回哈希。然後根據你的AJAX返回的哈希來引用服務器設置cookie,當它們到達你的站點時,它的檢查方式與我前面提到的相同。但由於所有的處理都發生在你的服務器上,所以它是完全安全的。聽起來像一個很酷的項目,祝你好運。

+1

這是行不通的。假設用戶訪問一個虛假網站,虛假網站的服務器直接向良好網站的服務器(CURL或其他)發送請求,提取cookie信息並將其轉發給客戶端以及他們的惡意內容。假冒的網站現在有一個「好」的cookie,並且你使用的任何加密/散列都是沒有意義的。 – Dave 2013-03-05 01:44:46

+1

此外,AJAX的想法(並記住唯一安全的AJAX標題是ORIGIN)不比在標準URL中使用REFERER標題更安全。然而,它可能對代理和其他可能試圖隱藏引用者的東西更健壯(使其在更多情況下工作,不*使其更安全或更不安全)。 – Dave 2013-03-05 01:47:50