使用令牌（Java）保護REST Web服務

Question

這個問題在某種程度上與以下相關問題有關。 但是，我需要更清楚一些方面和一些其他信息。 請參閱： REST Web服務身份驗證令牌實現

背景：

• 我需要使用令牌為REST Web服務實現安全性
• Web服務旨在與Java客戶端一起使用。 因此，憑據的表單身份驗證和彈出窗口無用。
• 我是REST安全和加密的新手

這是我迄今所理解的：

第一次請求：

1. 用戶建立https連接（或容器使用301確保https）
2. 用戶POST用戶名和密碼登錄服務
3. 如果憑證有效，我們：
   • 生成隨機臨時令牌
   • 將隨機令牌存儲在服務器上，將其映射到實際用戶名
   • 使用僅為服務器所知的對稱密鑰加密令牌
   • 哈希加密的令牌
   • 將加密的令牌和哈希發送到客戶端

對於后續請求：

1. 客戶端發送此加密令牌和哈希組合（使用基本的用戶名字段？）
2. 我們確保加密的令牌不會被哈希篡改，然后解密
3. 我們檢查session-tracking-table中的解密令牌是否有未過期的條目，並獲取實際的用戶名（到期時間由代碼管理？）
4. 如果找到用戶名，則根據允許的角色配置允許的操作

更多細節：

1. 由於客戶端是java客戶端，因此第一個請求可以是包含憑據的POST。 但是，這似乎可能會在https建立之前公開憑據。 因此，是否應該對安全資源進行虛擬GET，以便首先建立https？
2. 假設上面是必需的，第二個請求是帶有憑據的LoginAction POST。 此請求是手動處理的（不使用容器的授權）。 這是正確的嗎？
3. 上面的LoginAction返回用戶加密令牌+哈希的組合
4. 用戶將其設置為BASIC身份驗證機制使用的標頭（字段用戶名）
5. 我們實現了一個JAASRealm來解密和驗證令牌，並找到允許的角色
6. 其余的授權過程由具有web.xml中定義的WebResourceCollection的容器負責

這是正確的方法嗎？

Answer 1

為什么不將它簡化為以下內容？

第一次請求：

1. 用戶建立與服務器的HTTPS連接（服務不在任何其他端口上偵聽）和POST登錄服務的憑據。
2. 服務器回復HSTS標頭以確保所有進一步的通信都是HTTPS。
3. 如果憑證有效，我們：
   • 生成使用CSPRNG安全生成的隨機臨時令牌。 使這長得足夠安全（128位）。
   • 將隨機令牌存儲在服務器上，將其映射到實際用戶名。
   • 將隨機令牌發送到客戶端

對於后續請求：

1. 客戶端通過HTTPS在自定義HTTP標頭中發送令牌。
2. 令牌位於數據庫中並映射到用戶名。 如果找到基於允許的角色和允許的操作的訪問權限。
3. 如果未找到，則認為用戶未經身份驗證，並且必須再次使用登錄服務進行身份驗證才能獲得新令牌。

在服務器端，令牌將以失效日期存儲。 在每次訪問服務時，將更新此日期以創建滑動到期日期。 每隔幾分鍾就會有一個作業刪除已過期的令牌，並且檢查令牌以查找有效會話的查詢只會檢查那些未被認為已過期的查詢（如果預定的作業因任何原因失敗，則會阻止永久會話）。

不需要對數據庫中的令牌進行散列和加密 - 除了通過默默無聞的安全性之外，它不會增加真正的價值。 你可以哈哈哈哈。 這可以防止設法進入會話數據表的攻擊者劫持現有用戶會話。

Answer 2

方法看起來不錯。 不太安全。 讓我強調一下該請求可能發生的一些攻擊。

1. 在POST請求中的中間人攻擊，用戶可以篡改請求，服務器無法確保數據不被篡改。

2. 重播攻擊：在此，攻擊者不會篡改請求。 攻擊者輕敲請求並在短時間內將其多次發送給服務器，雖然這是一個有效請求，服務器多次處理請求，這是不需要請閱讀Nonce。

3. 在第一步中，用戶將他的憑證（即用戶名和密碼）發送到登錄服務，如果您的基於Web的應用程序也使用相同的密碼，則可能是危險的。 如果密碼被泄露，API和Web上的所有內容都暴露出來，請使用不同的PIN進行API訪問。 另外，確保您指定的解密令牌，在一定時間后過期。

4. 確保服務（應用程序服務器）tomcat。 如果發生內部錯誤，jboss永遠不會返回服務器頁面，這會為攻擊者提供部署應用程序的服務器的額外信息。

- 基於第二次修改的修改 -
是的，如果您使用相互SSL，則是正確的，但如果是單向訪問，則您沒有客戶端證書。 如果你只是加倍確保請求中的所有內容，就像簽名（簽名）SOAP，強大的數據傳輸機制之一那樣。 但重放攻擊是HTTPS的一種可能性，只需處理即可。 休息使用令牌加密是好的。 為什么不讓客戶端用密碼解密令牌並返回解密輸出，你可以驗證輸出，如果它存在於你的數據庫中？ 這種方法即使是HTTPS，用戶也不會通過網絡發送密碼？