如何保證API接口數(shù)據(jù)安全？
點擊上方?泥瓦匠 關注我！
前后端分離的開發(fā)方式，我們以接口為標準來進行推動，定義好接口，各自開發(fā)自己的功能，最后進行聯(lián)調(diào)整合。無論是開發(fā)原生的APP還是webapp還是PC端的軟件,只要是前后端分離的模式，就避免不了調(diào)用后端提供的接口來進行業(yè)務交互。
網(wǎng)頁或者app，只要抓下包就可以清楚的知道這個請求獲取到的數(shù)據(jù)，也可以偽造請求去獲取或攻擊服務器；也對爬蟲工程師來說是一種福音，要抓你的數(shù)據(jù)簡直輕而易舉。那我們怎么去解決這些問題呢？
接口簽名
我們先考慮一下接口數(shù)據(jù)被偽造，以及接口被重復調(diào)用的問題，要解決這個問題我們就要用到接口簽名的方案，
簽名流程
簽名規(guī)則
1、線下分配appid和appsecret，針對不同的調(diào)用方分配不同的appid和appsecret
2、加入timestamp（時間戳），5分鐘內(nèi)數(shù)據(jù)有效
3、加入臨時流水號?nonce（防止重復提交），至少為10位。針對查詢接口，流水號只用于日志落地，便于后期日志核查。針對辦理類接口需校驗流水號在有效期內(nèi)的唯一性，以避免重復請求。
4、加入簽名字段signature，所有數(shù)據(jù)的簽名信息。
以上字段放在請求頭中。
簽名的生成
簽名signature字段生成規(guī)則
所有動態(tài)參數(shù) = 請求頭部分 + 請求URL地址 + 請求Request參數(shù) + 請求Body
上面的動態(tài)參數(shù)以key-value的格式存儲，并以key值正序排序，進行拼接
最后拼接的字符串 在拼接appSecret
signature =?DigestUtils.md5DigestAsHex(sortParamsMap +?appSecret)
即拼接成一個字符串，然后做md5不可逆加密
請求頭部分
請求頭=“appId=xxxx&nonce=xxxx×tamp=xxxx&sign=xxx”
請求頭中的4個參數(shù)是必須要傳的，否則直接報異常
請求URL地址
這個就是請求接口的地址包含協(xié)議，如
https://mso.xxxx.com.cn/api/user
請求Request參數(shù)
即請求為Get方式的時候，獲取的傳入的參數(shù)
請求Body
即請求為Post時，請求體Body
從request inputstream中獲取保存為String形式
簽名算法實現(xiàn)
基本原理其實也比較簡單，就是自定義filter，對每個請求進行處理；整體流程如下
1）驗證必須的頭部參數(shù)
2）獲取頭部參數(shù)，request參數(shù)，Url請求路徑，請求體Body，把這些值放入SortMap中進行排序
3）對SortMap里面的值進行拼接
4）對拼接的值進行加密，生成sign
5）把生成的sign和前端傳入的sign進行比較，如果不相同就返回錯誤
我們來看一下代碼
以上是filter類，其中有個appSecret需要自己業(yè)務去獲取，它的作用主要是區(qū)分不同客戶端app。并且利用獲取到的appSecret參與到sign簽名，保證了客戶端的請求簽名是由我們后臺控制的，我們可以為不同的客戶端頒發(fā)不同的appSecret。
我們再來看看驗證頭部參數(shù)
上圖其實就是驗證是否傳入值；不過其實有個很重要的一點，就是對此請求進行時間驗證，如果大于10分鐘表示此鏈接已經(jīng)超時，防止別人來到這個鏈接去請求。這個就是防止盜鏈。
我們在來看看，如何獲取各個參數(shù)
上面我們獲取了各個參數(shù)，相對比較簡單；我們在來看看生成sign，和驗證sign
上面的流程中，會有個額外的安全處理，
· 防止盜鏈，我們可以讓鏈接有失效時間
· 利用nonce參數(shù)，防止重復提交
在簽名驗證成功后，判斷是否重復提交；
原理就是結合redis，判斷是否已經(jīng)提交過
總結
今天我們用簽名的方式，對我們對外提供的接口起到了保護作用；但這種保護僅僅做到了防止別人篡改請求，或者模擬請求。
但是還是缺少對數(shù)據(jù)自身的安全保護，即請求的參數(shù)和返回的數(shù)據(jù)都是有可能被別人攔截獲取的，而這些數(shù)據(jù)又是明文的，所以只要被攔截，就能獲得相應的業(yè)務數(shù)據(jù)。
往期推薦
下方二維碼關注我
技術草根，堅持分享?編程，算法，架構