分享一篇常見(jiàn)的面試題，前端開(kāi)發(fā)中的數(shù)據(jù)傳輸要怎么確保安全呢？
     

    

正文

連夜肝文，面試以來(lái)最尷尬的一次，事情是這樣的，最近有開(kāi)始面稍微有難度一點(diǎn)崗位，本文的主題出自北京某一小廠的正式崗面試題，薪資水平大概開(kāi)在10k-12k。之前一直是投的比較小的公司比較簡(jiǎn)單的實(shí)習(xí)崗位，這個(gè)是無(wú)意間投出去的一個(gè)，由于是 0 年經(jīng)驗(yàn)小白*1，結(jié)果沒(méi)想到簡(jiǎn)歷過(guò)篩，硬著頭皮上了。

結(jié)果很慘，40分鐘的面試有 80% 不會(huì)回答，像大文件上傳、緩存優(yōu)化、滑動(dòng) text-area標(biāo)簽用什么屬性（話說(shuō)為什么有這么冷的題）等等，有一個(gè)算一個(gè)，都沒(méi)答出來(lái)。

重點(diǎn)來(lái)了，在兩個(gè)面試官問(wèn)到前端請(qǐng)求如何避免明文傳輸的時(shí)候，在我絞盡腦汁思考五秒之后，現(xiàn)場(chǎng)氣氛非常凝重，這道題也成為了這次面試的最后一題。

在此提醒各位小伙伴，如果你的簡(jiǎn)歷或者自我介紹中有提到網(wǎng)絡(luò)請(qǐng)求，一定要注意了解一下有關(guān)數(shù)據(jù)加密處理，出現(xiàn)頻率巨高！！！

最后，下午四點(diǎn)面試，六點(diǎn)hr就通知了我面試結(jié)果，涼涼

如何避免前端請(qǐng)求明文傳輸

要在前端發(fā)送請(qǐng)求時(shí)做到不明文，有以下幾種方法：

1. HTTPS 加密傳輸： 使用 HTTPS 協(xié)議發(fā)送請(qǐng)求，所有的數(shù)據(jù)都會(huì)在傳輸過(guò)程中進(jìn)行加密，從而保護(hù)數(shù)據(jù)不以明文形式傳輸。這樣即使數(shù)據(jù)被截獲，黑客也無(wú)法直接獲取到數(shù)據(jù)的內(nèi)容。

2. 數(shù)據(jù)加密處理： 在前端對(duì)敏感數(shù)據(jù)進(jìn)行加密處理，然后再發(fā)送請(qǐng)求。可以使用一些加密算法，如 AES、RSA 等，將敏感數(shù)據(jù)進(jìn)行加密后再發(fā)送到服務(wù)器。這樣即使數(shù)據(jù)在傳輸過(guò)程中被截獲，也無(wú)法直接獲取其內(nèi)容。

3. 請(qǐng)求簽名驗(yàn)證： 在發(fā)送請(qǐng)求之前，前端對(duì)請(qǐng)求參數(shù)進(jìn)行簽名處理，并將簽名結(jié)果和請(qǐng)求一起發(fā)送到服務(wù)器。服務(wù)器端根據(jù)事先約定的簽名算法和密鑰對(duì)請(qǐng)求參數(shù)進(jìn)行驗(yàn)證，確保請(qǐng)求的完整性和可靠性。

4. Token 驗(yàn)證： 在用戶登錄時(shí)，后端會(huì)生成一個(gè) Token 并返回給前端，前端在發(fā)送請(qǐng)求時(shí)需要將 Token 添加到請(qǐng)求頭或請(qǐng)求參數(shù)中。后端在接收到請(qǐng)求后，驗(yàn)證 Token 的有效性，以確保請(qǐng)求的合法性。

5. 請(qǐng)求頭加密處理： 在發(fā)送請(qǐng)求時(shí)，可以將請(qǐng)求頭中的一些關(guān)鍵信息進(jìn)行加密處理，然后再發(fā)送到服務(wù)器。服務(wù)器端需要在接收到請(qǐng)求后對(duì)請(qǐng)求頭進(jìn)行解密，以獲取其中的信息。

HTTPS 加密傳輸

HTTPS（HyperText Transfer Protocol Secure）是HTTP協(xié)議的安全版本，它通過(guò)在HTTP和TCP之間添加一層TLS/SSL加密層來(lái)實(shí)現(xiàn)加密通信。

HTTPS加密傳輸?shù)木唧w細(xì)節(jié)：

1. TLS/SSL握手過(guò)程： 客戶端與服務(wù)器建立HTTPS連接時(shí)，首先進(jìn)行TLS/SSL握手。在握手過(guò)程中，客戶端和服務(wù)器會(huì)交換加密算法和密鑰信息，以協(xié)商出雙方都支持的加密算法和密鑰，從而確保通信的安全性。

2. 密鑰交換： 在握手過(guò)程中，客戶端會(huì)向服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)，服務(wù)器使用該隨機(jī)數(shù)以及自己的私鑰生成一個(gè)對(duì)稱密鑰（即會(huì)話密鑰）。該對(duì)稱密鑰用于加密和解密后續(xù)的通信數(shù)據(jù)。

3. 證書驗(yàn)證： 在握手過(guò)程中，服務(wù)器會(huì)向客戶端發(fā)送自己的數(shù)字證書。客戶端會(huì)驗(yàn)證服務(wù)器的數(shù)字證書是否有效，包括檢查證書的頒發(fā)機(jī)構(gòu)、有效期等信息，以確認(rèn)與服務(wù)器建立連接的真實(shí)性。

4. 加密通信： 客戶端和服務(wù)器在握手成功后，就會(huì)使用協(xié)商好的加密算法和密鑰進(jìn)行通信。客戶端和服務(wù)器之間傳輸?shù)乃袛?shù)據(jù)都會(huì)被加密，包括HTTP請(qǐng)求和響應(yīng)內(nèi)容、URL、請(qǐng)求頭等信息。

5. 完整性保護(hù)： 在通信過(guò)程中，TLS/SSL還會(huì)使用消息認(rèn)證碼（MAC）來(lái)保護(hù)通信的完整性，防止數(shù)據(jù)在傳輸過(guò)程中被篡改。MAC是通過(guò)將通信內(nèi)容和密鑰進(jìn)行哈希計(jì)算得到的，用于驗(yàn)證數(shù)據(jù)的完整性。

通過(guò)以上步驟， HTTPS這種加密通信方式在保護(hù)用戶隱私、防止數(shù)據(jù)被竊取或篡改方面起到了重要作用。

數(shù)據(jù)加密處理

數(shù)據(jù)加密處理是指在前端對(duì)敏感數(shù)據(jù)進(jìn)行加密處理，以確保數(shù)據(jù)在傳輸過(guò)程中的安全性。

數(shù)據(jù)加密處理的一般步驟和具體方法：

1. 選擇加密算法： 首先需要選擇合適的加密算法，常見(jiàn)的包括對(duì)稱加密算法（如AES）和非對(duì)稱加密算法（如RSA）。對(duì)稱加密算法使用相同的密鑰進(jìn)行加密和解密，而非對(duì)稱加密算法使用公鑰和私鑰進(jìn)行加密和解密。

2. 生成密鑰： 對(duì)于對(duì)稱加密算法，需要生成一個(gè)密鑰，用于加密和解密數(shù)據(jù)。對(duì)于非對(duì)稱加密算法，需要生成一對(duì)公鑰和私鑰，公鑰用于加密數(shù)據(jù)，私鑰用于解密數(shù)據(jù)。

3. 加密數(shù)據(jù)： 在前端，使用選擇好的加密算法和密鑰對(duì)敏感數(shù)據(jù)進(jìn)行加密處理。例如，對(duì)用戶的密碼、個(gè)人信息等敏感數(shù)據(jù)進(jìn)行加密處理，確保在數(shù)據(jù)傳輸過(guò)程中不被竊取或篡改。

4. 傳輸加密數(shù)據(jù)： 加密后的數(shù)據(jù)可以作為請(qǐng)求的參數(shù)發(fā)送到服務(wù)器。在發(fā)送請(qǐng)求時(shí)，可以將加密后的數(shù)據(jù)作為請(qǐng)求體或請(qǐng)求參數(shù)發(fā)送到服務(wù)器，確保數(shù)據(jù)在傳輸過(guò)程中的安全性。

5. 解密數(shù)據(jù)（可選）： 在服務(wù)器端接收到加密數(shù)據(jù)后，如果需要對(duì)數(shù)據(jù)進(jìn)行解密處理，則需要使用相同的加密算法和密鑰對(duì)數(shù)據(jù)進(jìn)行解密操作。這樣可以得到原始的明文數(shù)據(jù)，進(jìn)一步進(jìn)行業(yè)務(wù)處理。

總的來(lái)說(shuō)，數(shù)據(jù)加密處理通過(guò)選擇合適的加密算法、安全地管理密鑰，以及正確地使用加密技術(shù)，可以有效地保護(hù)用戶數(shù)據(jù)的安全性和隱私性。

請(qǐng)求簽名驗(yàn)證

請(qǐng)求簽名驗(yàn)證是一種驗(yàn)證請(qǐng)求完整性和身份驗(yàn)證的方法，通常用于確保請(qǐng)求在傳輸過(guò)程中沒(méi)有被篡改，并且請(qǐng)求來(lái)自于合法的發(fā)送方。

請(qǐng)求簽名驗(yàn)證的一般步驟：

1. 簽名生成： 發(fā)送請(qǐng)求的客戶端在發(fā)送請(qǐng)求之前，會(huì)根據(jù)事先約定好的簽名算法（如HMAC、RSA等）以及密鑰對(duì)請(qǐng)求參數(shù)進(jìn)行簽名處理。簽名處理的結(jié)果會(huì)作為請(qǐng)求的一部分發(fā)送到服務(wù)器。

2. 請(qǐng)求發(fā)送： 客戶端發(fā)送帶有簽名的請(qǐng)求到服務(wù)器。簽名可以作為請(qǐng)求頭、請(qǐng)求參數(shù)或請(qǐng)求體的一部分發(fā)送到服務(wù)器。

3. 驗(yàn)證簽名： 服務(wù)器接收到請(qǐng)求后，會(huì)根據(jù)事先約定好的簽名算法以及密鑰對(duì)請(qǐng)求參數(shù)進(jìn)行簽名驗(yàn)證。服務(wù)器會(huì)重新計(jì)算請(qǐng)求參數(shù)的簽名，然后將計(jì)算得到的簽名和請(qǐng)求中的簽名進(jìn)行比較。

4. 比較簽名： 服務(wù)器會(huì)將計(jì)算得到的簽名和請(qǐng)求中的簽名進(jìn)行比較。如果兩者一致，則說(shuō)明請(qǐng)求參數(shù)沒(méi)有被篡改，且請(qǐng)求來(lái)自于合法的發(fā)送方；否則，說(shuō)明請(qǐng)求可能被篡改或來(lái)自于非法發(fā)送方，服務(wù)器可以拒絕該請(qǐng)求或采取其他適當(dāng)?shù)奶幚泶胧?/p>

5. 響應(yīng)處理（可選）： 如果請(qǐng)求簽名驗(yàn)證通過(guò)，服務(wù)器會(huì)處理請(qǐng)求，并生成相應(yīng)的響應(yīng)返回給客戶端。如果請(qǐng)求簽名驗(yàn)證不通過(guò)，服務(wù)器可以返回相應(yīng)的錯(cuò)誤信息或拒絕請(qǐng)求。

通過(guò)請(qǐng)求簽名驗(yàn)證，可以確保請(qǐng)求在傳輸過(guò)程中的完整性和可靠性，防止數(shù)據(jù)被篡改或偽造請(qǐng)求。這種方法經(jīng)常用于對(duì) API 請(qǐng)求進(jìn)行驗(yàn)證，保護(hù) API 服務(wù)的安全和穩(wěn)定。前端開(kāi)發(fā)博客 公眾號(hào)

Token 驗(yàn)證

Token 驗(yàn)證是一種常見(jiàn)的用戶身份驗(yàn)證方式，通常用于保護(hù) Web 應(yīng)用程序的 API 端點(diǎn)免受未經(jīng)授權(quán)的訪問(wèn)。

Token驗(yàn)證的一般步驟：

1. 用戶登錄： 用戶使用用戶名和密碼登錄到Web應(yīng)用程序。一旦成功驗(yàn)證用戶的憑據(jù)，服務(wù)器會(huì)生成一個(gè)Token并將其返回給客戶端。

2. Token生成： 服務(wù)器生成一個(gè)Token，通常包括一些信息，如用戶ID、角色、過(guò)期時(shí)間等，然后將Token發(fā)送給客戶端（通常是作為響應(yīng)的一部分）。

3. Token發(fā)送： 客戶端在每次向服務(wù)器發(fā)送請(qǐng)求時(shí)，需要將Token作為請(qǐng)求的一部分發(fā)送到服務(wù)器。這通常是通過(guò)HTTP請(qǐng)求頭的Authorization字段來(lái)發(fā)送Token，格式可能類似于Bearer Token。

4. Token驗(yàn)證： 服務(wù)器在接收到請(qǐng)求時(shí)，會(huì)檢查請(qǐng)求中的Token。驗(yàn)證過(guò)程包括檢查Token的簽名是否有效、Token是否過(guò)期以及用戶是否有權(quán)限執(zhí)行請(qǐng)求的操作。

5. 響應(yīng)處理： 如果Token驗(yàn)證成功，服務(wù)器會(huì)處理請(qǐng)求并返回相應(yīng)的數(shù)據(jù)給客戶端。如果Token驗(yàn)證失敗，服務(wù)器通常會(huì)返回401 Unauthorized或其他類似的錯(cuò)誤代碼，并要求客戶端提供有效的Token。

6. Token刷新（可選）： 如果Token具有過(guò)期時(shí)間，客戶端可能需要定期刷新Token以保持登錄狀態(tài)。客戶端可以通過(guò)向服務(wù)器發(fā)送刷新Token的請(qǐng)求來(lái)獲取新的Token。

在Token驗(yàn)證過(guò)程中，服務(wù)器可以有效地識(shí)別和驗(yàn)證用戶身份，以確保API端點(diǎn)僅允許授權(quán)用戶訪問(wèn)，并保護(hù)敏感數(shù)據(jù)不被未經(jīng)授權(quán)的訪問(wèn)。前端開(kāi)發(fā)博客 公眾號(hào)

請(qǐng)求頭加密處理

請(qǐng)求頭加密處理是指在前端將請(qǐng)求頭中的一些關(guān)鍵信息進(jìn)行加密處理，然后再發(fā)送請(qǐng)求到服務(wù)器。

請(qǐng)求頭加密處理的一般步驟：

1. 選擇加密算法： 首先需要選擇適合的加密算法，常見(jiàn)的包括對(duì)稱加密算法（如AES）和非對(duì)稱加密算法（如RSA）。根據(jù)安全需求和性能考慮選擇合適的加密算法。

2. 生成密鑰： 對(duì)于對(duì)稱加密算法，需要生成一個(gè)密鑰，用于加密和解密請(qǐng)求頭中的信息。對(duì)于非對(duì)稱加密算法，需要生成一對(duì)公鑰和私鑰，公鑰用于加密數(shù)據(jù)，私鑰用于解密數(shù)據(jù)。

3. 加密請(qǐng)求頭： 在前端，使用選擇好的加密算法和密鑰對(duì)請(qǐng)求頭中的關(guān)鍵信息進(jìn)行加密處理。可以是請(qǐng)求中的某些特定參數(shù)、身份驗(yàn)證信息等。確保加密后的請(qǐng)求頭信息無(wú)法直接被識(shí)別和篡改。

4. 發(fā)送加密請(qǐng)求： 加密處理后的請(qǐng)求頭信息作為請(qǐng)求的一部分發(fā)送到服務(wù)器。可以是作為請(qǐng)求頭的一部分，也可以是作為請(qǐng)求體中的一部分發(fā)送到服務(wù)器。

5. 解密處理（可選）： 在服務(wù)器端接收到加密請(qǐng)求頭信息后，如果需要對(duì)請(qǐng)求頭進(jìn)行解密處理，則需要使用相同的加密算法和密鑰對(duì)數(shù)據(jù)進(jìn)行解密操作。這樣可以得到原始的請(qǐng)求頭信息，服務(wù)器可以進(jìn)一步處理請(qǐng)求。

請(qǐng)求頭加密處理這種方法可以有效地防止請(qǐng)求頭中的敏感信息被竊取或篡改，并提高了數(shù)據(jù)傳輸?shù)陌踩浴?/p>

請(qǐng)求頭加密處理和數(shù)據(jù)加密處理的區(qū)別

請(qǐng)求頭加密處理和數(shù)據(jù)加密處理在概念和步驟上非常相似，都是為了保護(hù)數(shù)據(jù)在傳輸過(guò)程中的安全性。

要區(qū)別在于加密的對(duì)象和處理方式：

1. 加密對(duì)象：

• 請(qǐng)求頭加密處理： 主要是對(duì)請(qǐng)求頭中的一些關(guān)鍵信息進(jìn)行加密處理，例如身份驗(yàn)證信息、授權(quán)信息等。請(qǐng)求頭中的這些信息通常是用來(lái)授權(quán)訪問(wèn)或識(shí)別用戶身份的關(guān)鍵數(shù)據(jù)。
• 數(shù)據(jù)加密處理： 主要是對(duì)請(qǐng)求體中的數(shù)據(jù)或響應(yīng)體中的數(shù)據(jù)進(jìn)行加密處理，例如用戶提交的表單數(shù)據(jù)、API請(qǐng)求中的參數(shù)數(shù)據(jù)等。這些數(shù)據(jù)通常是需要保護(hù)隱私的用戶輸入數(shù)據(jù)或敏感業(yè)務(wù)數(shù)據(jù)。

2. 處理方式：

• 請(qǐng)求頭加密處理： 一般來(lái)說(shuō)，請(qǐng)求頭中的關(guān)鍵信息通常較少，并且不像請(qǐng)求體中的數(shù)據(jù)那樣多樣化。因此，請(qǐng)求頭加密處理可以更加靈活，可以選擇性地對(duì)請(qǐng)求頭中的特定信息進(jìn)行加密處理，以提高安全性。
• 數(shù)據(jù)加密處理： 數(shù)據(jù)加密處理通常是對(duì)請(qǐng)求體中的整體數(shù)據(jù)進(jìn)行加密處理，以保護(hù)整體數(shù)據(jù)的安全性。例如，對(duì)表單數(shù)據(jù)進(jìn)行加密處理，或?qū)PI請(qǐng)求參數(shù)進(jìn)行加密處理，確保數(shù)據(jù)在傳輸過(guò)程中不被竊取或篡改。

結(jié)論：請(qǐng)求頭加密處理和數(shù)據(jù)加密處理都是為了保護(hù)數(shù)據(jù)在傳輸過(guò)程中的安全性，但針對(duì)的對(duì)象和處理方式有所不同。

請(qǐng)求頭加密處理主要針對(duì)請(qǐng)求頭中的關(guān)鍵信息進(jìn)行加密，而數(shù)據(jù)加密處理主要針對(duì)請(qǐng)求體中的數(shù)據(jù)進(jìn)行加密。

關(guān)于本文

作者：知了知了__

https://juejin.cn/post/7338702103882399744