欧美大交乱xxxx,亚洲精品一区二区三区婷婷,日韩福利视频导航

<span class="hljs-keyword">if</span> (!Strings.isNullOrEmpty(token)) {
hasAuth = redisTemplate.hasKey(<span class="hljs-string">"userToken:"</span> + token);
}

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

中間人攻擊（MITM）

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

重放攻擊（Replay Attack）

即使使用HTTPS來加密通信，靜態(tài)的認(rèn)證令牌仍然容易受到重放攻擊。在這種攻擊中，攻擊者不是截取和解密數(shù)據(jù)，而是簡單地記錄下一次成功的認(rèn)證請(qǐng)求，然后重復(fù)發(fā)送這個(gè)請(qǐng)求來訪問資源。這是因?yàn)殪o態(tài)令牌在一段時(shí)間內(nèi)保持不變，所以攻擊者可以多次使用同一個(gè)令牌

API簽名認(rèn)證流程

Part 1: 請(qǐng)求端加密

請(qǐng)求端加密是說，比如我對(duì)你說話，那么我是請(qǐng)求端，是我這里說話的時(shí)候進(jìn)行加密，把我說的話加密一下再說給你，而你是服務(wù)端

秘鑰分發(fā)：服務(wù)器向API使用者提供一對(duì)密鑰，即AK（Access Key）和SK（Secret Key）。AK是公開的，而SK需要保密，因?yàn)樗怯糜谏珊灻拿荑€。
簽名規(guī)則：
- HTTP Header：請(qǐng)求頭中包含AK，這允許服務(wù)器驗(yàn)證請(qǐng)求來自已注冊(cè)的用戶。
- 參數(shù)排序與拼接：對(duì)于GET請(qǐng)求，所有參數(shù)按照key進(jìn)行字典排序，并拼接成字符串；對(duì)于POST請(qǐng)求，根據(jù)不同的Content-Type進(jìn)行相應(yīng)處理。
- 簽名計(jì)算：使用HMAC-SHA256算法，以SK作為密鑰，對(duì)拼接后的字符串進(jìn)行簽名，然后將簽名結(jié)果base64編碼。
請(qǐng)求構(gòu)造：將X-Ca-Key（即AK）和X-Ca-Signature（即簽名）添加到HTTP請(qǐng)求頭中，一同發(fā)送至服務(wù)器。

看一下下面的圖

Part 2: 服務(wù)器端驗(yàn)證

剛才我說道服務(wù)端是你，請(qǐng)求端是我，還用這個(gè)舉例子，我把話說給你之后然后你是服務(wù)端，我加密了，說給你的話是加密的，這時(shí)候你需要驗(yàn)證并解密我說的話才行，那么是服務(wù)端解密和驗(yàn)證

驗(yàn)證AK：服務(wù)器收到請(qǐng)求后，首先檢查請(qǐng)求頭中的AK，確認(rèn)請(qǐng)求者身份。
重新計(jì)算簽名：服務(wù)器使用相同的算法和SK重新計(jì)算簽名，以驗(yàn)證請(qǐng)求的完整性和一致性。
比較簽名：將計(jì)算出的簽名與請(qǐng)求頭中的簽名進(jìn)行對(duì)比。如果匹配，則認(rèn)為請(qǐng)求有效；如果不匹配，則拒絕請(qǐng)求，因?yàn)榭赡艽嬖跀?shù)據(jù)篡改或非授權(quán)訪問。

防御重放攻擊

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

為了提高安全性，通常會(huì)結(jié)合使用timestamp（時(shí)間戳）和nonce（一次性隨機(jī)數(shù)），以防止重放攻擊（replay attack）。下面我進(jìn)行全面的講解

Timestamp 和 Nonce 的作用

Timestamp：這是請(qǐng)求發(fā)出的時(shí)刻，通常精確到毫秒。服務(wù)器會(huì)檢查這個(gè)時(shí)間戳，如果與當(dāng)前時(shí)間相差超過預(yù)設(shè)的閾值，認(rèn)為請(qǐng)求過期，不予處理。這有助于防止攻擊者捕獲舊的請(qǐng)求并稍后重放，這個(gè)時(shí)間戳大家學(xué)過linux應(yīng)該知道，不是單純一個(gè)時(shí)間而是一長串?dāng)?shù)字，可以轉(zhuǎn)換時(shí)間，用這個(gè)驗(yàn)證也是說雙方必須用標(biāo)準(zhǔn)時(shí)間，不能出現(xiàn)時(shí)間誤差，不然可能出現(xiàn)第一次請(qǐng)求驗(yàn)證不過，因?yàn)閮蓚€(gè)人時(shí)間不一樣，所以需要用到ntp時(shí)間服務(wù)器同步時(shí)間。
Nonce：這是一個(gè)隨機(jī)數(shù)，每次請(qǐng)求都不同。服務(wù)器會(huì)存儲(chǔ)最近收到的nonce，當(dāng)接收到新的請(qǐng)求時(shí)，會(huì)檢查這個(gè)nonce是否已經(jīng)被使用過。如果nonce是新的，那么請(qǐng)求被認(rèn)為是有效的；如果nonce已經(jīng)存在，那么這可能是一個(gè)重放攻擊。

使用Timestamp和Nonce的挑戰(zhàn)

Nonce的存儲(chǔ)：隨著請(qǐng)求量的增加，服務(wù)器需要存儲(chǔ)越來越多的nonce，這可能導(dǎo)致內(nèi)存壓力。通常，使用如Redis這樣的鍵值存儲(chǔ)系統(tǒng)來管理nonce，它可以設(shè)置過期時(shí)間（TTL），這樣舊的nonce會(huì)自動(dòng)被刪除。

API簽名與HTTPS的關(guān)系

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

HTTPS：提供了傳輸層的安全，確保數(shù)據(jù)在網(wǎng)絡(luò)上傳輸時(shí)不會(huì)被竊聽或篡改。但是，HTTPS本身并不提供對(duì)請(qǐng)求的驗(yàn)證或重放攻擊的防護(hù)所以只是單單用一個(gè)https加密不太行，還得增加API簽名。
API簽名：在應(yīng)用層上保證了請(qǐng)求的完整性和來源的真實(shí)性，防止數(shù)據(jù)被篡改，同時(shí)也可以防止重放攻擊。

結(jié)合HTTPS和API簽名，可以提供更全面的安全保障，既保護(hù)了數(shù)據(jù)在傳輸過程中的安全，也確保了到達(dá)服務(wù)器的請(qǐng)求是合法且未被篡改的。在實(shí)際部署中，這是推薦的做法，尤其對(duì)于涉及敏感數(shù)據(jù)和交易的API。

作者：幻城