這篇文章一直說(shuō)寫(xiě)，遲遲沒(méi)有動(dòng)手，這兩天看到一些應(yīng)用接口數(shù)據(jù)被別人爬蟲(chóng)、短信接口被人高頻率請(qǐng)求***等案列，感覺(jué)簡(jiǎn)單概述分享一下接口安全驗(yàn)證還是有必要的。畢竟當(dāng)下基本都以客戶端應(yīng)用為主，如果前期疏忽，發(fā)布之后的維護(hù)升級(jí)等將會(huì)有很大的麻煩。這里我將主要圍繞以下幾個(gè)方面：

創(chuàng)新互聯(lián)公司致力于互聯(lián)網(wǎng)網(wǎng)站建設(shè)與網(wǎng)站營(yíng)銷(xiāo)，提供網(wǎng)站制作、成都做網(wǎng)站、網(wǎng)站開(kāi)發(fā)、seo優(yōu)化、網(wǎng)站排名、互聯(lián)網(wǎng)營(yíng)銷(xiāo)、微信小程序、公眾號(hào)商城、等建站開(kāi)發(fā)，創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)策劃專(zhuān)家，為不同類(lèi)型的客戶提供良好的互聯(lián)網(wǎng)應(yīng)用定制解決方案，幫助客戶在新的全球化互聯(lián)網(wǎng)環(huán)境中保持優(yōu)勢(shì)。

1. 基礎(chǔ)的安全策略

2. Restful安全實(shí)現(xiàn)方式介紹

3. OSS.Core實(shí)現(xiàn)案例

4. OSS.Core接口參數(shù)規(guī)范

一. 基礎(chǔ)的安全策略

 這里討論只針對(duì)應(yīng)用本身，像Https或者防火墻等第三方支持不在此討論范圍。

   對(duì)于一個(gè)接口項(xiàng)目來(lái)說(shuō)，安全策略我個(gè)人認(rèn)為主要分兩塊：1. 接口驗(yàn)證模塊  2. 用戶驗(yàn)證模塊

1. 接口驗(yàn)證模塊

這個(gè)模塊是對(duì)整個(gè)接口安全層面負(fù)責(zé)。對(duì)于接口安全而言，特別是客戶端接口，是直接暴露在整個(gè)互聯(lián)網(wǎng)中的，我們首先要保證的就是不會(huì)被別人冒名請(qǐng)求我們的接口數(shù)據(jù)。經(jīng)常使用的就是簽名驗(yàn)證，在接口正常的數(shù)據(jù)傳輸之外，傳遞額外的約定加密簽名信息等，來(lái)過(guò)濾非授權(quán)的接口請(qǐng)求。

這里可以舉一個(gè)去年我遇到的典型案列，當(dāng)時(shí)有個(gè)外賣(mài)的站點(diǎn)短信發(fā)送接口沒(méi)有添加任何驗(yàn)證，接口地址還寫(xiě)在了頁(yè)面上，可想而知后果有多么嚴(yán)重，網(wǎng)絡(luò)上的很多短信轟炸機(jī)用的就是這些接口，這里給一張當(dāng)時(shí)發(fā)現(xiàn)時(shí)測(cè)試的截圖：

當(dāng)然簽名校驗(yàn)只是最基礎(chǔ)的安全校驗(yàn)，如果再配合IP限流等校驗(yàn)措施效果更佳！

2. 用戶授權(quán)驗(yàn)證模塊

這個(gè)模塊主要是對(duì)用戶個(gè)體負(fù)責(zé)，上一步主要是在一定程度上過(guò)濾一些非自身應(yīng)用接口請(qǐng)求。但是應(yīng)用本身出了問(wèn)題，例如漏洞或者被反編譯等，又或者是人員流動(dòng)造成的秘鑰泄露，又如何保證接口的真實(shí)用戶數(shù)據(jù)不被輕易篡改。

對(duì)于這個(gè)問(wèn)題，我們可以獨(dú)立一個(gè)用戶驗(yàn)證模塊，核心思路就是通過(guò)給每個(gè)登錄用戶頒發(fā)token（可以通過(guò)用戶編號(hào)加密，或者編號(hào)+時(shí)間戳），對(duì)用戶相關(guān)的操作通過(guò)token驗(yàn)證，用戶主鍵信息不通過(guò)接口明文傳送，在服務(wù)端通過(guò)token解密獲取。token的加解密過(guò)程都在服務(wù)端完成，和簽名驗(yàn)證模塊獨(dú)立。

 這兩個(gè)模塊也可以通過(guò)下邊的簡(jiǎn)單時(shí)序圖了解相關(guān)分工：

二. Restful接口下安全實(shí)現(xiàn)方式介紹

上邊介紹了一個(gè)基礎(chǔ)的接口驗(yàn)證步驟，這邊我以常見(jiàn)的http接口協(xié)議來(lái)簡(jiǎn)單介紹下實(shí)現(xiàn)過(guò)程：

1. 簽名驗(yàn)證

這個(gè)主要是通過(guò)對(duì)每次請(qǐng)求通過(guò)參數(shù)和隨機(jī)數(shù)的排序組合生成唯一的簽名【sign】信息，方式多種多樣，這里我介紹一種通用做法，如果你對(duì)第三方網(wǎng)站簽名驗(yàn)證比較熟悉可以跳過(guò)。

這里因?yàn)橐粋€(gè)接口項(xiàng)目可能會(huì)給對(duì)個(gè)應(yīng)用提供數(shù)據(jù)服務(wù)，我們給每個(gè)應(yīng)用頒發(fā)對(duì)應(yīng)的appid和appsecret信息。

    第一步，在正常傳遞的參數(shù)外，添加appid，timespan（當(dāng)前時(shí)間戳）參數(shù)，把當(dāng)前參數(shù)集合中值不為空的參數(shù)按照參數(shù)名ASCII碼從小到大排序（字典序），使用URL鍵值對(duì)的格式（即key1=value1&key2=value2…）拼接成字符串str，同時(shí)需要注意一下幾點(diǎn)。

1. 1. 參數(shù)名ASCII碼從小到大排序（字典序）

   2. 參數(shù)的值為空不參與簽名

   3. 參數(shù)名區(qū)分大小寫(xiě)

   　　 第二步，將得到str使用簽名算法，生成sign（主要看和服務(wù)器約定的加密算法，一般使用單向簽名算法即可），一下是兩種常見(jiàn)加密算法

1. 使用MD5

在str后追加  &appsecret=xxx 后再進(jìn)行md5 加密，即 sign = md5(str&appsecret=xxx)

2.  使用SHA1

 因?yàn)閟ha1本身支持加鹽操作， 直接使用  appsecret加密 str ，即 sign=sha1(str, appsecret)

第三步：  傳遞內(nèi)容  str&sign=xxxx  到服務(wù)端。

以上是一個(gè)基本的簽名實(shí)現(xiàn)過(guò)程，當(dāng)然具體的實(shí)現(xiàn)可以根據(jù)實(shí)際情況各自調(diào)整，比如簽名信息也可以放在請(qǐng)求header中，參數(shù)格式也可以是json等，重要的是需要保證：每次請(qǐng)求簽名不會(huì)相同

2.  用戶授權(quán)驗(yàn)證實(shí)現(xiàn)

這個(gè)大家可以參考最近比較流行的 jwt 協(xié)議等實(shí)現(xiàn)，主要思路是用戶授權(quán)后，服務(wù)端頒發(fā)token返回給客戶端，在請(qǐng)求相關(guān)授權(quán)接口時(shí)附帶token即可。

這里加密算法需要使用雙向加密算法，然后服務(wù)端在處理請(qǐng)求時(shí)，攔截并解密相關(guān)信息，保存在上下文中。

三. OSS.Core實(shí)現(xiàn)案例

   1. 簽名驗(yàn)證：

在OSS.Core項(xiàng)目，我把簽名相關(guān)驗(yàn)證信息放置在請(qǐng)求頭（httpheader）中，通過(guò)自定義AuthorizeSignMiddleware中間件在程序入口處進(jìn)行攔截，主要包含以下參數(shù)（實(shí)現(xiàn)代碼詳見(jiàn)GitHub）：

如果你想了解詳細(xì)排序加密等處理，可參見(jiàn)OSS.Common中的SysAuthorizeInfo

2. 用戶驗(yàn)證模塊：

主要通過(guò)自定義Attribute注冊(cè)實(shí)現(xiàn)，代碼詳見(jiàn) GitHub中AuthorizeMemberAttribute，  同時(shí)我會(huì)將當(dāng)前用戶信息保存在一個(gè) AsyncLocal 變量中，詳細(xì)代碼參見(jiàn)OSS.Common中的MemberShiper

四.  OSS.Core接口參數(shù)規(guī)范

所有的接口信息中，我會(huì)定義套全局錯(cuò)誤碼，所有的接口返回信息中都會(huì)包含ret標(biāo)識(shí)，來(lái)返回當(dāng)前接口的正常與否，比如：如果ret=1423時(shí)表示非法應(yīng)用來(lái)源，ret=1425需要去獲取授權(quán)驗(yàn)證token，當(dāng)然每個(gè)接口也可以自定義其特有的局部錯(cuò)誤碼?！?/p>

全局錯(cuò)誤碼詳見(jiàn)：Github 下 ResultTypes

同時(shí)，接口請(qǐng)求頭中AppSource，AppVersion，AppClient 參數(shù)必填，來(lái)保證后續(xù)的活躍度，用戶注冊(cè)，訂單分布等情況統(tǒng)計(jì)。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性?xún)r(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專(zhuān)為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

當(dāng)前標(biāo)題：Api接口通用安全策略及實(shí)現(xiàn)-OSS.Core-創(chuàng)新互聯(lián)
轉(zhuǎn)載注明：http://aaarwkj.com/article2/isioc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、網(wǎng)站內(nèi)鏈、網(wǎng)站改版、App設(shè)計(jì)、ChatGPT、建站公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)