阿里一面：如何保證API接口數據安全？

前言

先後端分離的開發方式，咱們以接口爲標準來進行推進，定義好接口，各自開發本身的功能，最後進行聯調整合。不管是開發原生的APP仍是webapp仍是PC端的軟件,只要是先後端分離的模式，就避免不了調用後端提供的接口來進行業務交互。

網頁或者app，只要抓下包就能夠清楚的知道這個請求獲取到的數據，也能夠僞造請求去獲取或攻擊服務器；也對爬蟲工程師來講是一種福音，要抓你的數據簡直垂手可得。那咱們怎麼去解決這些問題呢？

接口簽名

咱們先考慮一下接口數據被僞造，以及接口被重複調用的問題，要解決這個問題咱們就要用到接口簽名的方案，

簽名流程

簽名規則

一、線下分配appid和appsecret，針對不一樣的調用方分配不一樣的appid和appsecret

二、加入timestamp（時間戳），5分鐘內數據有效

三、加入臨時流水號 nonce****（防止重複提交），至少爲10位。針對查詢接口，流水號只用於日誌落地，便於後期日誌覈查。針對辦理類接口需校驗流水號在有效期內的惟一性，以免重複請求。

四、加入簽名字段signature，全部數據的簽名信息。

以上字段放在請求頭中。

簽名的生成

簽名signature字段生成規則

全部動態參數 = 請求頭部分 + 請求URL地址 + 請求Request參數 + 請求Body

上面的動態參數以key-value的格式存儲，並以key值正序排序，進行拼接

最後拼接的字符串 在拼接appSecret

signature = DigestUtils.md5DigestAsHex(sortParamsMap + appSecret)

即拼接成一個字符串，而後作md5不可逆加密

請求頭部分

請求頭=「appId=xxxx&nonce=xxxx×tamp=xxxx&sign=xxx」

請求頭中的4個參數是必需要傳的，不然直接報異常

請求URL地址

這個就是請求接口的地址包含協議，如

https://mso.xxxx.com.cn/api/user

請求Request參數

即請求爲Get方式的時候，獲取的傳入的參數

請求Body

即請求爲Post時，請求體Body

從request inputstream中獲取保存爲String形式

簽名算法實現

基本原理其實也比較簡單，就是自定義filter，對每一個請求進行處理；總體流程以下:

1. 驗證必須的頭部參數

2. 獲取頭部參數，request參數，Url請求路徑，請求體Body，把這些值放入SortMap中進行排序

3. 對SortMap裏面的值進行拼接

4. 對拼接的值進行加密，生成sign

5. 把生成的sign和前端傳入的sign進行比較，若是不相同就返回錯誤

咱們來看一下代碼

@Component
public class SignAuthFilter extends OncePerRequestFilter{
static final String FAVICON = "/favicon.ico";
static final String PREFIX = "attack:signature:";
}

以上是filter類，其中有個appSecret須要本身業務去獲取，它的做用主要是區分不一樣客戶端app。而且利用獲取到的appSecret參與到sign簽名，保證了客戶端的請求籤名是由咱們後臺控制的，咱們能夠爲不一樣的客戶端頒發不一樣的appSecret。

咱們再來看看驗證頭部參數

上圖其實就是驗證是否傳入值；不過其實有個很重要的一點，就是對此請求進行時間驗證，若是大於10分鐘表示此連接已經超時，防止別人來到這個連接去請求。這個就是防止盜鏈。

咱們在來看看，如何獲取各個參數

上面咱們獲取了各個參數，相對比較簡單；咱們在來看看生成sign，和驗證sign

上面的流程中，會有個額外的安全處理，

· 防止盜鏈，咱們可讓連接有失效時間

· 利用nonce參數，防止重複提交

在簽名驗證成功後，判斷是否重複提交；

原理就是結合redis，判斷是否已經提交過

總結

今天咱們用簽名的方式，對咱們對外提供的接口起到了保護做用；但這種保護僅僅作到了防止別人篡改請求，或者模擬請求。

可是仍是缺乏對數據自身的安全保護，即請求的參數和返回的數據都是有可能被別人攔截獲取的，而這些數據又是明文的，因此只要被攔截，就能得到相應的業務數據。