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

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)目來說，安全策略我個(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ù)傳輸之外，傳遞額外的約定加密簽名信息等，來過濾非授權(quán)的接口請(qǐng)求。

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

大數(shù)據(jù)培訓(xùn),云培訓(xùn),數(shù)據(jù)挖掘培訓(xùn),云計(jì)算培訓(xùn),高端軟件開發(fā)培訓(xùn),項(xiàng)目經(jīng)理培訓(xùn)

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

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

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

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

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

大數(shù)據(jù)培訓(xùn),云培訓(xùn),數(shù)據(jù)挖掘培訓(xùn),云計(jì)算培訓(xùn),高端軟件開發(fā)培訓(xùn),項(xiàng)目經(jīng)理培訓(xùn)

 

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

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

　　1. 簽名驗(yàn)證

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

　　這里因?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. 參數(shù)名ASCII碼從小到大排序（字典序）

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

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

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

　　　　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)過程，當(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）中，通過自定義AuthorizeSignMiddleware中間件在程序入口處進(jìn)行攔截，主要包含以下參數(shù)（實(shí)現(xiàn)代碼詳見GitHub）：

大數(shù)據(jù)培訓(xùn),云培訓(xùn),數(shù)據(jù)挖掘培訓(xùn),云計(jì)算培訓(xùn),高端軟件開發(fā)培訓(xùn),項(xiàng)目經(jīng)理培訓(xùn)

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

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

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

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

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

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

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

 

     注：有些朋友說這些在頁面上并無用處，可能大家還沒搞清楚相互的層級(jí)關(guān)系，當(dāng)前一個(gè)常見的系統(tǒng)一般分為兩個(gè)主要部分：1.  接口層    2.  交互層（客戶端，web站點(diǎn)）

     首先：本文的驗(yàn)證安全主要討論的是接口層，朋友們擔(dān)心的短信利用在交互層面上需要做交互層面上對(duì)應(yīng)的措施，包括但不限于手動(dòng)驗(yàn)證碼，臨時(shí)令牌等，切不可混為一談，但如果接口層都沒有做好最基礎(chǔ)的防護(hù)，上層做再多的措施也都為零，有點(diǎn)經(jīng)驗(yàn)的人通過網(wǎng)絡(luò)監(jiān)控就可以獲取接口地址，直接繞開前端。

　 其次： ip限流，https等在有一定條件的情況下，添加最好，交叉驗(yàn)證，和上述方法是互補(bǔ)的關(guān)系，而不是互斥的關(guān)系。但在項(xiàng)目前期并不建議，精力最好還是集中在項(xiàng)目本身，這些都有第三方產(chǎn)品，上線之后添加即可。

http://www.cnblogs.com/osscoder/p/7004427.html