保證接口數(shù)據(jù)安全的10種方案

位置:首頁 / 新聞中心 / 行業(yè)資訊

行業(yè)資訊 Admin 2024-02-24 18:36:59 888

我們?nèi)粘i_發(fā)中,如何保證接口數(shù)據(jù)的安全性呢?個人覺得,接口數(shù)據(jù)安全的保證過程,主要體現(xiàn)在這幾個方面:一個就是數(shù)據(jù)傳輸過程中的安,還有就是數(shù)據(jù)到達服務(wù)端,如何識別數(shù)據(jù),最后一點就是數(shù)據(jù)存儲的安全性。今天跟大家聊聊保證接口數(shù)據(jù)安全的10個方案。

d2fdd638c55c5f89ddf1469f42c021c.jpg

1.數(shù)據(jù)加密,防止報文明文傳輸。


我們都知道,數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中,很容易被抓包。如果使用的是http協(xié)議,因為它是明文傳輸?shù)?,用戶的?shù)據(jù)就很容易被別人獲取。所以需要對數(shù)據(jù)加密。


1.1 數(shù)據(jù)如何加密呢?


常見的實現(xiàn)方式,就是對關(guān)鍵字段加密。比如,你一個登錄的接口,你可以對密碼加密。一般用什么加密算法呢?簡單點可以使用對稱加密算法(如AES)來加解密,或者哈希算法處理(如MD5)。

什么是對稱加密:加密和解密使用相同密鑰的加密算法。

b34ce46163f970fdfcb8c822bc5a4add.png

非對稱加密:非對稱加密算法需要兩個密鑰(公開密鑰和私有密鑰)。公鑰與私鑰是成對存在的,如果用公鑰對數(shù)據(jù)進行加密,只有對應(yīng)的私鑰才能解密。

更安全的做法,就是用非對稱加密算法(如RSA或者SM2),公鑰加密,私鑰解密。

34a8bd06a50f125ca8d517236a5adc70.png

如果你想對所有字段都加密的話,一般都推薦使用https協(xié)議。https其實就是在http和tcp之間添加一層加密層SSL。


1.2 小伙伴們,是否還記得https的原理呢?

837dd31bf90919393c4a48bb23c39a1f.png

面試也經(jīng)常問的,如下:

客戶端發(fā)起Https請求,連接到服務(wù)器的443端口。

服務(wù)器必須要有一套數(shù)字證書(證書內(nèi)容有公鑰、證書頒發(fā)機構(gòu)、失效日期等)。

服務(wù)器將自己的數(shù)字證書發(fā)送給客戶端(公鑰在證書里面,私鑰由服務(wù)器持有)。

客戶端收到數(shù)字證書之后,會驗證證書的合法性。如果證書驗證通過,就會生成一個隨機的對稱密鑰,用證書的公鑰加密。

客戶端將公鑰加密后的密鑰發(fā)送到服務(wù)器。

服務(wù)器接收到客戶端發(fā)來的密文密鑰之后,用自己之前保留的私鑰對其進行非對稱解密,解密之后就得到客戶端的密鑰,然后用客戶端密鑰對返回數(shù)據(jù)進行對稱加密,醬紫傳輸?shù)臄?shù)據(jù)都是密文啦。

服務(wù)器將加密后的密文返回到客戶端。

客戶端收到后,用自己的密鑰對其進行對稱解密,得到服務(wù)器返回的數(shù)據(jù)。

日常業(yè)務(wù)呢,數(shù)據(jù)傳輸加密這塊的話,用https就可以啦,如果安全性要求較高的,比如登陸注冊這些,需要傳輸密碼的,密碼就可以使用RSA等非對稱加密算法,對密碼加密。如果你的業(yè)務(wù),安全性要求很高,你可以模擬https這個流程,對報文,再做一次加解密。


2. 數(shù)據(jù)加簽驗簽


數(shù)據(jù)報文加簽驗簽,是保證數(shù)據(jù)傳輸安全的常用手段,它可以保證數(shù)據(jù)在傳輸過程中不被篡改。以前我做的企業(yè)轉(zhuǎn)賬系統(tǒng),就用了加簽驗簽。


2.1 什么是加簽驗簽呢?


數(shù)據(jù)加簽:用Hash算法(如MD5,或者SHA-256)把原始請求參數(shù)生成報文摘要,然后用私鑰對這個摘要進行加密,就得到這個報文對應(yīng)的數(shù)字簽名sign(這個過程就是加簽)。通常來說呢,請求方會把數(shù)字簽名和報文原文一并發(fā)送給接收方。

107dd6c74e3dbe218792e63cc0e6dd36.png

驗簽:接收方拿到原始報文和數(shù)字簽名(sign)后,用同一個Hash算法(比如都用MD5)從報文中生成摘要A。另外,用對方提供的公鑰對數(shù)字簽名進行解密,得到摘要B,對比A和B是否相同,就可以得知報文有沒有被篡改過。

d505fe6f4d216e60bf5f212b1ec00484.png

其實加簽,我的理解的話,就是把請求參數(shù),按照一定規(guī)則,利用hash算法+加密算法生成一個唯一標簽sign。驗簽的話,就是把請求參數(shù)按照相同的規(guī)則處理,再用相同的hash算法,和對應(yīng)的密鑰解密處理,以對比這個簽名是否一致。


再舉個例子,有些小伙伴是這么實現(xiàn)的,將所有非空參數(shù)(包含一個包AccessKey,唯一的開發(fā)者標識)按照升序,然后再拼接個SecretKey(這個僅作本地加密使用,不參與網(wǎng)絡(luò)傳輸,它只是用作簽名里面的),得到一個stringSignTemp的值,最后用MD5運算,得到sign。


服務(wù)端收到報文后,會校驗,只有擁有合法的身份AccessKey和簽名Sign正確,才放行。這樣就解決了身份驗證和參數(shù)篡改問題,如果請求參數(shù)被劫持,由于劫持者獲取不到SecretKey(僅作本地加密使用,不參與網(wǎng)絡(luò)傳輸),他就無法偽造合法的請求啦


2.2 有了https等加密數(shù)據(jù),為什么還需要加簽驗簽


有些小伙伴可能有疑問,加簽驗簽主要是防止數(shù)據(jù)在傳輸過程中被篡改,那如果都用了https下協(xié)議加密數(shù)據(jù)了,為什么還會被篡改呢?為什么還需要加簽驗簽?zāi)兀?/p>


數(shù)據(jù)在傳輸過程中被加密了,理論上,即使被抓包,數(shù)據(jù)也不會被篡改。但是https不是絕對安全的哦。還有一個點:https加密的部分只是在外網(wǎng),然后有很多服務(wù)是內(nèi)網(wǎng)相互跳轉(zhuǎn)的,加簽也可以在這里保證不被中間人篡改,所以一般轉(zhuǎn)賬類安全性要求高的接口開發(fā),都需要加簽驗簽。


3.token授權(quán)認證機制


日常開發(fā)中,我們的網(wǎng)站或者APP,都是需要用戶登錄的。那么如果是非登錄接口,是如何確保安全,如何確認用戶身份的呢?可以使用token授權(quán)機制。


3.1 token的授權(quán)認證方案

token的授權(quán)認證方案:用戶在客戶端輸入用戶名和密碼,點擊登錄后,服務(wù)器會校驗密碼成功,會給客戶端返回一個唯一值token,并將token以鍵值對的形式存放在緩存(一般是Redis)中。后續(xù)客戶端對需要授權(quán)模塊的所有操作都要帶上這個token,服務(wù)器端接收到請求后,先進行token驗證,如果token存在,才表明是合法請求。

token登錄授權(quán)流程圖如下:

67d0ca978edb33a3ddd4563c4f17bd37.png

1.用戶輸入用戶名和密碼,發(fā)起登錄請求

2.服務(wù)端校驗密碼,如果校驗通過,生成一個全局唯一的token。

3.將token存儲在redis中,其中key是token,value是userId或者是用戶信息,設(shè)置一個過期時間。

4.把這個token返回給客戶端

5.用戶發(fā)起其他業(yè)務(wù)請求時,需要帶上這個token

6.后臺服務(wù)會統(tǒng)一攔截接口請求,進行token有效性校驗,并從中獲取用戶信息,供后續(xù)業(yè)務(wù)邏輯使用。如果token不存在,說明請求無效。


3.2 如何保證token的安全?token被劫持呢?


我們?nèi)绾伪WCtoken的安全呢?

比如說,我如果拿到token,是不是就可以調(diào)用服務(wù)器端的任何接口?可以從這幾個方面出發(fā)考慮:

token設(shè)置合理的有效期

使用https協(xié)議

token可以再次加密

如果訪問的是敏感信息,單純加token是不夠的,通常會再配置白名單


說到token,有些小伙伴們可能會想起jwt,即(JSON Web Token),其實它也是token的一種。有興趣的小伙伴可以去了解一下哈。


4. 時間戳timestamp超時機制


數(shù)據(jù)是很容易抓包的,假設(shè)我們用了https和加簽,即使中間人抓到了數(shù)據(jù)報文,它也看不到真實數(shù)據(jù)。但是有些不法者,他根本不關(guān)心真實的數(shù)據(jù),而是直接拿到抓取的數(shù)據(jù)包,進行惡意請求(比如DOS攻擊),以搞垮你的系統(tǒng)。


我們可以引入時間戳超時機制,來保證接口安全。就是:用戶每次請求都帶上當前時間的時間戳timestamp,服務(wù)端接收到timestamp后,解密,驗簽通過后,與服務(wù)器當前時間進行比對,如果時間差大于一定時間 (比如3分鐘),則認為該請求無效。


5.timestamp+nonce方案防止重放攻擊


時間戳超時機制也是有漏洞的,如果是在時間差內(nèi),黑客進行的重放攻擊,那就不好使了??梢允褂胻imestamp+nonce方案。


nonce指唯一的隨機字符串,用來標識每個被簽名的請求。我們可以將每次請求的nonce參數(shù)存儲到一個“set集合”中,或者可以json格式存儲到數(shù)據(jù)庫或緩存中。每次處理HTTP請求時,首先判斷該請求的nonce參數(shù)是否在該“集合”中,如果存在則認為是非法請求。


然而對服務(wù)器來說,永久保存nonce的代價是非常大的??梢越Y(jié)合timestamp來優(yōu)化。因為timstamp參數(shù)對于超過3min的請求,都認為非法請求,所以我們只需要存儲3min的nonce參數(shù)的“集合”即可。


6. 限流機制


如果用戶本來就是就是真實用戶,他惡意頻繁調(diào)用接口,想搞垮你的系統(tǒng)呢?這種情況就需要接入限流了。


常用的限流算法有令牌桶和漏桶算法。


可以使用Guava的RateLimiter單機版限流,也可以使用Redis分布式限流,還可以使用阿里開源組件sentinel限流。比如說,一分鐘可以接受多少次請求。


7. 黑名單機制


如果發(fā)現(xiàn)了真實用戶惡意請求,你可以搞個黑名單機制,把該用戶拉黑。一般情況,會有些競爭對手,或者不壞好意的用戶,想搞你的系統(tǒng)的。所以,為了保證安全,一般我們的業(yè)務(wù)系統(tǒng),需要有個黑名單機制。對于黑名單發(fā)起的請求,直接返回錯誤碼好了。


8.白名單機制


有了黑名單機制,也可以搞個白名單機制啦。以前我負責的企業(yè)轉(zhuǎn)賬系統(tǒng),如果有外面的商戶要接入我們的系統(tǒng)時,是需要提前申請網(wǎng)絡(luò)白名單的。那時候運維會申請個IP網(wǎng)絡(luò)白名單,只有白名單里面的請求,才可以訪問我們的轉(zhuǎn)賬系統(tǒng)。


9.數(shù)據(jù)脫敏掩碼


對于密碼,或者手機號、身份證這些敏感信息,一般都需要脫敏掩碼再展示的,如果是密碼,還需要加密再保存到數(shù)據(jù)庫。


對于手機號、身份證信息這些,日常開發(fā)中,在日志排查時,看到的都應(yīng)該是掩碼的。目的就是盡量不泄漏這些用戶信息,雖然能看日志的只是開發(fā)和運維,但是還是需要防一下,做掩碼處理。


對于密碼保存到數(shù)據(jù)庫,我們肯定不能直接明文保存。最簡單的也需要MD5處理一下再保存,Spring Security中的 BCryptPasswordEncoder也可以,它的底層是采用SHA-256 +隨機鹽+密鑰對密碼進行加密,而SHA和MD系列是一樣的,都是hash摘要類的算法。


10. 數(shù)據(jù)參數(shù)一些合法性校驗。


接口數(shù)據(jù)的安全性保證,還需要我們的系統(tǒng),有個數(shù)據(jù)合法性校驗,簡單來說就是參數(shù)校驗,比如身份證長度,手機號長度,是否是數(shù)字等等。



以上就是“保證接口數(shù)據(jù)安全的10種方案”的詳細內(nèi)容,更多請關(guān)注木子天禾科技其它相關(guān)文章!

以上就是“保證接口數(shù)據(jù)安全的10種方案”的詳細內(nèi)容,更多請關(guān)注木子天禾科技其它相關(guān)文章!

15934152105 掃描微信