前言
web與后端,andorid與后端,ios與后端,像這種類型的交互其實(shí)就屬于典型的前端與后端進(jìn)行交互。在與B端用戶進(jìn)行交互的過程中,我們通常忽略了其安全性(甚至從未考慮安全性)。比如,請求和響應(yīng)數(shù)據(jù)的明文傳輸,對接口并沒有做嚴(yán)格的身份校驗(yàn)。如果我們還是按照這種思路去做C端用戶的交互,那么等待著必將是血淋淋的教訓(xùn)。接下來,我?guī)ьI(lǐng)大家如何在與C端用戶安全的進(jìn)行交互。
保證安全性的幾種方式
前后端安全性的交互,大致可以分成如下幾類:
1、通信請求使用https
2、對請求參數(shù)進(jìn)行簽名,防止數(shù)據(jù)被踹改
3、對請求參數(shù)以及響應(yīng)進(jìn)行加密解密處理
4、APP中使用
ssl pinning防止抓包操作
使用https
谷歌 Chrome 在18年七月份已經(jīng)將所有的 HTTP 網(wǎng)站標(biāo)記為“不安全”。并且已經(jīng)有越來越多的第三方服務(wù)開始推薦甚至是強(qiáng)制要求使用 HTTPS 連接方式,比如現(xiàn)在用得特別多的微信登錄、微信支付、短信驗(yàn)證碼、地圖 API 等等,又比如蘋果公司 2016 年在 WWDC 上宣稱,公司希望官方應(yīng)用商店中的所有 iOS App 都使用安全的 HTTPS 鏈接與服務(wù)器進(jìn)行通信。
那為什么越來越多的 HTTP 都在逐漸 HTTPS 化?HTTP 協(xié)議(超文本傳輸協(xié)議)是客戶端瀏覽器或其他程序與 Web 服務(wù)器之間的應(yīng)用層通信協(xié)議;HTTPS 協(xié)議可以理解為 HTTP+
ssl/TLS, 即 HTTP 下加入
ssl 層,HTTPS 的安全基礎(chǔ)是
ssl,因此加密的詳細(xì)內(nèi)容就需要
ssl,用于安全的 HTTP 數(shù)據(jù)傳輸,http與https的區(qū)別如下圖所示:
不使用
ssl/TLS的HTTP通信,就是不加密的通信。所有信息明文傳播,帶來了三大風(fēng)險(xiǎn)。
ssl/TLS協(xié)議是為了解決這三大風(fēng)險(xiǎn)而設(shè)計(jì)的,希望達(dá)到:
因此強(qiáng)烈建議,為了你的系統(tǒng)安全性,趕快切到https中去吧。
對請求進(jìn)行簽名
我們先來看一個(gè)例子,假設(shè)用戶在下完單之后,可以更改訂單的狀態(tài),用戶對后端發(fā)起請求 /user?orderId=123, 假設(shè)后端剛好也沒有對這筆訂單的身份進(jìn)行驗(yàn)證,那么后果就是,我們根據(jù)orderId, 將這筆訂單的狀態(tài)進(jìn)行了修改:
如果這時(shí)候,嘗試著將請求中的orderId 換成另外一個(gè)orderId, 也會(huì)同樣對這筆訂單做了修改,從安全角度來說這是我們不希望看到的,當(dāng)然我們也可以加一下身份校驗(yàn),判斷該筆訂單是否屬于當(dāng)前的用戶;除此之外,我們還應(yīng)該對請求參數(shù)做一次簽名處理。
加簽和驗(yàn)簽就是在請求發(fā)送方將請求參數(shù)通過加密算法生成一個(gè)sign值,放到請求參數(shù)里;請求接收方收到請求后,使用同樣的方式對請求參數(shù)也進(jìn)行加密得到一個(gè)sign值,只要兩個(gè)sign值相同,就說明參數(shù)沒有被篡改。
簽名參數(shù)sign生成的方法
舉例
現(xiàn)在假設(shè)需要傳輸?shù)臄?shù)據(jù):/guest/rechargeNotify?p2=v2&p1=v1&method=cancel&p3=&pn=vn(實(shí)際情況最好是通過post方式發(fā)送)
驗(yàn)簽過程
其實(shí)就是將請求url按照上述的規(guī)則進(jìn)行同樣的操作,計(jì)算得到參數(shù)的簽名值,然后和參數(shù)中傳遞的sign值進(jìn)行對比,如果一致則校驗(yàn)通過,否則校驗(yàn)不通過。
對請求和響應(yīng)進(jìn)行加解密
可能有人會(huì)問,都使用了https了,為什么還要對請求和響應(yīng)再做一次加解密,因?yàn)橛行┑谌阶グぞ?,例如Charles 通過某些手段是可以抓取https的明文的,因此對一些敏感數(shù)據(jù),我們需要進(jìn)行加密處理,常見的加解密方式有AES 對成加密方式和RSA非對成方式,至于如何運(yùn)用,可以參考https的原理,有點(diǎn)復(fù)雜,不過可以簡單分成如下幾步:
1.服務(wù)器端有一個(gè)密鑰對,即公鑰和私鑰,是用來進(jìn)行非對稱加密使用的,服務(wù)器端保存著私鑰,不能將其泄露,公鑰可以發(fā)送給任何人。
2.服務(wù)器將自己的公鑰發(fā)送給客戶端。
3.客戶端收到服務(wù)器端的公鑰之后,會(huì)對公鑰進(jìn)行檢查,驗(yàn)證其合法性,如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問題,那么HTTPS傳輸就無法繼續(xù)。嚴(yán)格的說,這里應(yīng)該是驗(yàn)證服務(wù)器發(fā)送的數(shù)字證書的合法性,關(guān)于客戶端如何驗(yàn)證數(shù)字證書的合法性,下文會(huì)進(jìn)行說明。如果公鑰合格,那么客戶端會(huì)生成一個(gè)隨機(jī)值,這個(gè)隨機(jī)值就是用于進(jìn)行對稱加密的密鑰,我們將該密鑰稱之為client key,即客戶端密鑰,這樣在概念上和服務(wù)器端的密鑰容易進(jìn)行區(qū)分。然后用服務(wù)器的公鑰對客戶端密鑰進(jìn)行非對稱加密,這樣客戶端密鑰就變成密文了,至此,HTTPS中的第一次HTTP請求結(jié)束。
4.客戶端會(huì)發(fā)起HTTPS中的第二個(gè)HTTP請求,將加密之后的客戶端密鑰發(fā)送給服務(wù)器。
5.服務(wù)器接收到客戶端發(fā)來的密文之后,會(huì)用自己的私鑰對其進(jìn)行非對稱解密,解密之后的明文就是客戶端密鑰,然后用客戶端密鑰對數(shù)據(jù)進(jìn)行對稱加密,這樣數(shù)據(jù)就變成了密文。
6.然后服務(wù)器將加密后的密文發(fā)送給客戶端。
7.客戶端收到服務(wù)器發(fā)送來的密文,用客戶端密鑰對其進(jìn)行對稱解密,得到服務(wù)器發(fā)送的數(shù)據(jù)。
總結(jié)
前后端的交互如果做到以上使用https,對請求加解密以及對請求參數(shù)進(jìn)行驗(yàn)簽,基本上能解決大部分問題,但除此之外我們還應(yīng)該做到對每個(gè)接口進(jìn)行身份校驗(yàn),確保該接口只能由特定的用戶訪問,或者該筆數(shù)據(jù)只能由特定的用戶去進(jìn)行修改。
新聞名稱:前后端交互如何保證安全性?
當(dāng)前URL:http://redsoil1982.com.cn/news41/101841.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、Google、做網(wǎng)站、移動(dòng)網(wǎng)站建設(shè)、云服務(wù)器、用戶體驗(yàn)
廣告
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源:
創(chuàng)新互聯(lián)