客戶端和服務器之間的安全連接

Question

我正在開發一個服務器組件，該組件將為嵌入式客戶端的請求提供服務，這也在我的控制之下。

現在，所有內容都是beta版本，其安全性如下所示：

1. 客戶端通過https發送用戶名/密碼。

2. 服務器返回訪問令牌。

3. 客戶端使用自定義標頭中的訪問令牌通過http發出進一步的請求。

這對於演示很好，但是在發布它之前，需要解決一些問題：

• 任何人都可以復制 login請求，然后重新發送並獲得訪問令牌。 正如一些用戶回答的那樣，這不是問題，因為它遍歷了https。 我的錯。

• 任何人都可以通過檢查請求標頭來偵聽並獲取訪問密鑰。

我可以想到帶有時間戳的對稱密鑰加密，因此我可以拒絕重復的請求，但是我想知道這種情況是否存在一些眾所周知的良好做法（這很常見）。

非常感謝您的見解。

PS：我正在為服務器使用Java，並且客戶端以C ++編碼，以防萬一。

Answer 1

常見建議之一是-使用https

除了在整個會話中使用https的中間攻擊之外的https man應該足夠可靠。 您甚至不必擔心訪問令牌-https會為您解決這一問題。

使用http發出進一步的請求似乎會引入一些漏洞。 現在，任何具有網絡嗅探器的人都可以攔截您的流量，從而竊取令牌並欺騙您的請求。 您可以建立保護措施來防止這種情況發生-令牌加密，使用一次令牌等，但是這樣做會重新創建https。

回到中間人攻擊中的https人-它是基於某人將自己插入服務器和客戶端之間並通過其代碼來收集請求的能力。 這都是可行的，即如果攻擊者可以訪問物理網絡。 此類攻擊者將面臨的問題是，他將無法為您提供適當的數字證書-他沒有用於簽名的私鑰。 通過瀏覽器訪問https時，瀏覽器會向您發出警告，但仍然可以使您進入頁面。

在您的情況下，將由您的客戶端與服務器進行通信。 您可以確保已對證書進行了所有正確的驗證。 如果這樣做，你應該沒事

編輯

其次，Yeshai-是的，涉及一些開銷，主要是CPU，但是如果這筆額外開銷使服務器負擔過重，則您的應用程序會遇到更大的問題

Answer 2

第一個問題，就是要解決這個問題：如果您對惡意的客戶端模擬訪問有足夠的關注，為什么不通過HTTPS進行整個對話呢？ 最低性能對這個應用程序是否足夠重要，以至於不值得增加額外的安全性？

第二，有人如何重播登錄請求？ 如果我沒記錯的話，那是通過HTTPS進行的。 如果連接設置正確，HTTPS將使用一次性隨機數來防止重放攻擊（請參閱此處 ）。

Answer 3

我沒有得到第一部分，如果登錄請求是https，那么誰能復制它呢？

\n

關於第二部分， 這是一個非常標准的會話劫持方案。 看到這個問題 。 當然，這里沒有內置的瀏覽器選項，但是基本思想是相同的-要么僅在重要時通過安全連接發送令牌，要么以某種方式將令牌與發送設備關聯。

在瀏覽器中，基本上您只擁有IP地址（不是很好），但是在您的情況下，您可以表達針對設備的特定內容，並根據請求進行驗證，以確保不會使用相同的令牌從其他地方使用。

編輯：您可能在這里很幸運，並且可以排除代理后面的IP地址更改，並且可以將其實際用於此目的。

但是，歸根結底，使用來自知名且經過審查的庫中的https比嘗試將自己的腳本放到這里要安全得多 。 我意識到https是一項開銷，但是如果您自己進行滾動，則會遺漏一些攻擊者可以利用的明顯事物的巨大風險。