亚洲一级毛片欧美一级说乱,思思久久99er热只有频精品66,国产亚洲高清视频

if (!Strings.isNullOrEmpty(token)) {
hasAuth = redisTemplate.hasKey("userToken:" + token);
}

這類方法實現比較簡單，可以做基本的身份認證，防君子不防小人，可通過中間人攻擊獲得 Authorization。使用 HTTPS 安全性會得到提高，但是無法抵御重放攻擊造成的影響，例如 DDOS，我們這里來分析一下會遭受什么攻擊？怎么實現攻擊手法

中間人攻擊（MITM）

在非加密的HTTP連接上，任何在網絡路徑上的攻擊者都可以截取和讀取請求和響應的內容。這意味著如果Authorization頭包含的是純文本的用戶名/密碼組合或者是一個靜態令牌，攻擊者可以輕松地獲取這些信息，并在后續的請求中重用它們來冒充合法用戶。

重放攻擊（Replay Attack）

即使使用HTTPS來加密通信，靜態的認證令牌仍然容易受到重放攻擊。在這種攻擊中，攻擊者不是截取和解密數據，而是簡單地記錄下一次成功的認證請求，然后重復發送這個請求來訪問資源。這是因為靜態令牌在一段時間內保持不變，所以攻擊者可以多次使用同一個令牌

API簽名認證流程

Part 1: 請求端加密

請求端加密是說，比如我對你說話，那么我是請求端，是我這里說話的時候進行加密，把我說的話加密一下再說給你，而你是服務端

秘鑰分發：服務器向API使用者提供一對密鑰，即AK（Access Key）和SK（Secret Key）。AK是公開的，而SK需要保密，因為它是用于生成簽名的密鑰。
簽名規則：
- HTTP Header：請求頭中包含AK，這允許服務器驗證請求來自已注冊的用戶。
- 參數排序與拼接：對于GET請求，所有參數按照key進行字典排序，并拼接成字符串；對于POST請求，根據不同的Content-Type進行相應處理。
- 簽名計算：使用HMAC-SHA256算法，以SK作為密鑰，對拼接后的字符串進行簽名，然后將簽名結果base64編碼。
請求構造：將X-Ca-Key（即AK）和X-Ca-Signature（即簽名）添加到HTTP請求頭中，一同發送至服務器。

看一下下面的圖

Part 2: 服務器端驗證

剛才我說道服務端是你，請求端是我，還用這個舉例子，我把話說給你之后然后你是服務端，我加密了，說給你的話是加密的，這時候你需要驗證并解密我說的話才行，那么是服務端解密和驗證

驗證AK：服務器收到請求后，首先檢查請求頭中的AK，確認請求者身份。
重新計算簽名：服務器使用相同的算法和SK重新計算簽名，以驗證請求的完整性和一致性。
比較簽名：將計算出的簽名與請求頭中的簽名進行對比。如果匹配，則認為請求有效；如果不匹配，則拒絕請求，因為可能存在數據篡改或非授權訪問。

防御重放攻擊

主要防的是你burpsuite抓包重放，有了這個驗證你想著通過bp抓包重放進行攻擊，抱歉不可能了，因為會驗證和加密，你抓包后在放包的時候會出現驗證不過，會丟棄你那個包，到最后實現防御你這個攻擊。API簽名機制可以通過加入時間戳和nonce（一次性隨機數）來進一步增強安全性，以防御重放攻擊。時間戳和nonce都會被包含在簽名計算中，且每個請求的時間戳和nonce都應該唯一。服務器會檢查時間戳，確保請求沒有過期，并且會跟蹤nonce，以避免處理重復的請求。

為了提高安全性，通常會結合使用timestamp（時間戳）和nonce（一次性隨機數），以防止重放攻擊（replay attack）。下面我進行全面的講解

Timestamp 和 Nonce 的作用

Timestamp：這是請求發出的時刻，通常精確到毫秒。服務器會檢查這個時間戳，如果與當前時間相差超過預設的閾值，認為請求過期，不予處理。這有助于防止攻擊者捕獲舊的請求并稍后重放，這個時間戳大家學過linux應該知道，不是單純一個時間而是一長串數字，可以轉換時間，用這個驗證也是說雙方必須用標準時間，不能出現時間誤差，不然可能出現第一次請求驗證不過，因為兩個人時間不一樣，所以需要用到ntp時間服務器同步時間。
Nonce：這是一個隨機數，每次請求都不同。服務器會存儲最近收到的nonce，當接收到新的請求時，會檢查這個nonce是否已經被使用過。如果nonce是新的，那么請求被認為是有效的；如果nonce已經存在，那么這可能是一個重放攻擊。

使用Timestamp和Nonce的挑戰

Nonce的存儲：隨著請求量的增加，服務器需要存儲越來越多的nonce，這可能導致內存壓力。通常，使用如Redis這樣的鍵值存儲系統來管理nonce，它可以設置過期時間（TTL），這樣舊的nonce會自動被刪除。

API簽名與HTTPS的關系

我們講到這里會有人詢問，這個API簽名加密和https是不是一回事？直接用https加密不行了還搞那么麻煩那么多事情干嘛？抱歉，這里我要說的是，不是一個概念，甚至這兩個東西不是同樣的東西，https是傳輸層的一個加密，和API簽名不在同一層，我來進行一下解析。

HTTPS：提供了傳輸層的安全，確保數據在網絡上傳輸時不會被竊聽或篡改。但是，HTTPS本身并不提供對請求的驗證或重放攻擊的防護所以只是單單用一個https加密不太行，還得增加API簽名。
API簽名：在應用層上保證了請求的完整性和來源的真實性，防止數據被篡改，同時也可以防止重放攻擊。

結合HTTPS和API簽名，可以提供更全面的安全保障，既保護了數據在傳輸過程中的安全，也確保了到達服務器的請求是合法且未被篡改的。在實際部署中，這是推薦的做法，尤其對于涉及敏感數據和交易的API。

作者：幻城