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

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

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

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

d2fdd638c55c5f89ddf1469f42c021c.jpg

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


我們都知道,數(shù)據(jù)在網(wǎng)絡(luò)傳輸過(guò)程中,很容易被抓包。如果使用的是http協(xié)議,因?yàn)樗敲魑膫鬏數(shù)?,用?hù)的數(shù)據(jù)就很容易被別人獲取。所以需要對(duì)數(shù)據(jù)加密。


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


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

什么是對(duì)稱(chēng)加密:加密和解密使用相同密鑰的加密算法。

b34ce46163f970fdfcb8c822bc5a4add.png

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

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

34a8bd06a50f125ca8d517236a5adc70.png

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


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

837dd31bf90919393c4a48bb23c39a1f.png

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

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

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

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

客戶(hù)端收到數(shù)字證書(shū)之后,會(huì)驗(yàn)證證書(shū)的合法性。如果證書(shū)驗(yàn)證通過(guò),就會(huì)生成一個(gè)隨機(jī)的對(duì)稱(chēng)密鑰,用證書(shū)的公鑰加密。

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

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

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

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

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


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


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


2.1 什么是加簽驗(yàn)簽呢?


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

107dd6c74e3dbe218792e63cc0e6dd36.png

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

d505fe6f4d216e60bf5f212b1ec00484.png

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


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


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


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


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


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


3.token授權(quán)認(rèn)證機(jī)制


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


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

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

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

67d0ca978edb33a3ddd4563c4f17bd37.png

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

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

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

4.把這個(gè)token返回給客戶(hù)端

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

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


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


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

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

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

使用https協(xié)議

token可以再次加密

如果訪(fǎng)問(wèn)的是敏感信息,單純加token是不夠的,通常會(huì)再配置白名單


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


4. 時(shí)間戳timestamp超時(shí)機(jī)制


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


我們可以引入時(shí)間戳超時(shí)機(jī)制,來(lái)保證接口安全。就是:用戶(hù)每次請(qǐng)求都帶上當(dāng)前時(shí)間的時(shí)間戳timestamp,服務(wù)端接收到timestamp后,解密,驗(yàn)簽通過(guò)后,與服務(wù)器當(dāng)前時(shí)間進(jìn)行比對(duì),如果時(shí)間差大于一定時(shí)間 (比如3分鐘),則認(rèn)為該請(qǐng)求無(wú)效。


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


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


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


然而對(duì)服務(wù)器來(lái)說(shuō),永久保存nonce的代價(jià)是非常大的??梢越Y(jié)合timestamp來(lái)優(yōu)化。因?yàn)閠imstamp參數(shù)對(duì)于超過(guò)3min的請(qǐng)求,都認(rèn)為非法請(qǐng)求,所以我們只需要存儲(chǔ)3min的nonce參數(shù)的“集合”即可。


6. 限流機(jī)制


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


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


可以使用Guava的RateLimiter單機(jī)版限流,也可以使用Redis分布式限流,還可以使用阿里開(kāi)源組件sentinel限流。比如說(shuō),一分鐘可以接受多少次請(qǐng)求。


7. 黑名單機(jī)制


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


8.白名單機(jī)制


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


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


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


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


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


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


接口數(shù)據(jù)的安全性保證,還需要我們的系統(tǒng),有個(gè)數(shù)據(jù)合法性校驗(yàn),簡(jiǎn)單來(lái)說(shuō)就是參數(shù)校驗(yàn),比如身份證長(zhǎng)度,手機(jī)號(hào)長(zhǎng)度,是否是數(shù)字等等。



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

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

15934152105 掃描微信