你的介面真的安全嗎？

首頁>技術>Tom大發現2020-09-18 13:03

你的介面真的安全嗎？

Restful介面安全重要性

現在網際網路開發的框架越來越豐富，大多數的系統架構也都是朝著微服務化，雲原生化演進。而且自從中臺的概念提出之後，各大公司也開始拆分自己的技術中臺，抽離出一些公共的技術服務中臺。

這使得我們服務開發也越來越容易，較少的精力放在框架層處理，更多關注業務邏輯的實現。現在系統大都是異構化，服務之間通過 Http 或者 Rpc 進行遠端呼叫。當我們的後臺介面暴露給前端或者移動 app 端時就要考慮介面的安全性。

例如，現在的 app 登陸或者重置密碼介面都需要傳送簡訊驗證碼，如果我們的傳送介面被他人利用，不僅容易出現簡訊盜刷，還有可能影響我們正常的服務使用。所以我們在設計介面時可以從以下幾個方面加上介面安全性相關的設計。

簽名校驗生成 appId 和 appKey

首先，我們可以為每個請求呼叫方生成固定長度的隨機字串 appId 和 appKey，可以使用 RandomUtil 方法。

“Talk is cheap,show me your code.”

當然有很多其他的隨機字串生成方法，比如用機器 id + timestamp 時間戳方式，這裡只是簡單的列舉一種隨機方法。

public&nbsp;static&nbsp;void&nbsp;main(String[]&nbsp;args)&nbsp;{&nbsp;&nbsp;String&nbsp;appId&nbsp;=&nbsp;RandomUtil.randomString(20);&nbsp;&nbsp;String&nbsp;chars&nbsp;=&nbsp;&#34;$&@?&lt;&gt;~!%#&#34;;&nbsp;&nbsp;StringBuilder&nbsp;appKeyTemp&nbsp;=&nbsp;new&nbsp;StringBuilder(RandomUtil.randomString(20));&nbsp;&nbsp;for(int&nbsp;i=0;i&lt;chars.length();i++){&nbsp;&nbsp;&nbsp;&nbsp;int&nbsp;index&nbsp;=&nbsp;new&nbsp;Random().nextInt(chars.length());&nbsp;&nbsp;&nbsp;&nbsp;appKeyTemp.insert(index,&nbsp;chars.charAt(index));&nbsp;&nbsp;}&nbsp;&nbsp;System.out.println(&#34;appId:&#34;+appId+&#34;&nbsp;appKey:&#34;+appKeyTemp.toString());}

appId:tow9e8piyuj23w5e46yj&nbsp;appKey:$$$8?ze&gt;&lt;&lt;&gt;zuq%8ba#dqmr8dwx1jy

生成 appId 和 appKey 之後可以將其放在配置檔案或者配置中心，通過 @Value 註解獲取變數值，在介面呼叫時進行校驗。

@Componentpublic&nbsp;class&nbsp;EncryptUtils{&nbsp;&nbsp;@Value(&#34;${appId}&#34;)&nbsp;&nbsp;String&nbsp;appId;&nbsp;&nbsp;@Value(&#34;${appKey}&#34;)&nbsp;&nbsp;String&nbsp;appKey;&nbsp;&nbsp;/**&nbsp;&nbsp;&nbsp;*&nbsp;判斷&nbsp;appId&nbsp;和&nbsp;appKey&nbsp;是否校驗&nbsp;&nbsp;&nbsp;*&nbsp;&nbsp;&nbsp;*&nbsp;@param&nbsp;appId&nbsp;app&nbsp;id.&nbsp;&nbsp;&nbsp;*&nbsp;@param&nbsp;appKey&nbsp;app&nbsp;key.&nbsp;&nbsp;&nbsp;*&nbsp;@return&nbsp;result.&nbsp;&nbsp;&nbsp;*/&nbsp;&nbsp;&nbsp;public&nbsp;boolean&nbsp;appIdMatch(String&nbsp;appId,&nbsp;String&nbsp;appKey)&nbsp;{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return&nbsp;this.appId.equals(appId)&nbsp;&&&nbsp;this.appKey.equals(appKey);&nbsp;&nbsp;&nbsp;}}

介面簽名校驗 sign

但是以上生成的 appId 和 appKey 還是放在請求引數或者請求包頭，通過代理抓包還是能夠拿到這兩個引數。所以，為了安全我們還必須對請求呼叫方做簽名驗證。生成簽名的方式主要是對稱加密，這裡展示了 AES256 加密方法。

我們可以將 appId_appKey_timestamp 作為字串，用 AES/ECB/PKCS5Padding 演算法填充，AES256 演算法加密，由於 AES 是對稱加密，所以只需要根據請求引數再做一次加密，然後比較加密之後的密文和請求的 sign 是否一致即可以達到校驗介面請求的目的。

加密需要前後端約定金鑰，AES 加密金鑰長度為 16 位，這點需要注意。加密方法如下

/**&nbsp;*&nbsp;*&nbsp;@param&nbsp;content&nbsp;加密的字串&nbsp;*&nbsp;@param&nbsp;encryptKey&nbsp;key&nbsp;值&nbsp;*&nbsp;@return&nbsp;result.&nbsp;*&nbsp;@throws&nbsp;Exception&nbsp;IllegalBlockSizeException&nbsp;*/&nbsp;private&nbsp;String&nbsp;encryptAppId(String&nbsp;content,&nbsp;String&nbsp;encryptKey)&nbsp;throws&nbsp;Exception&nbsp;{&nbsp;&nbsp;&nbsp;KeyGenerator&nbsp;kgen&nbsp;=&nbsp;KeyGenerator.getInstance(&#34;AES&#34;);&nbsp;&nbsp;&nbsp;kgen.init(256);&nbsp;&nbsp;&nbsp;Cipher&nbsp;cipher&nbsp;=&nbsp;Cipher.getInstance(&#34;AES/ECB/PKCS5Padding&#34;);&nbsp;&nbsp;&nbsp;cipher.init(Cipher.ENCRYPT_MODE,&nbsp;new&nbsp;SecretKeySpec(encryptKey.getBytes(),&nbsp;&#34;AES&#34;));&nbsp;&nbsp;&nbsp;byte[]&nbsp;b&nbsp;=&nbsp;cipher.doFinal(content.getBytes(StandardCharsets.UTF_8));&nbsp;&nbsp;&nbsp;//&nbsp;base64&nbsp;進行轉碼&nbsp;&nbsp;&nbsp;return&nbsp;Base64.encodeBase64String(b);&nbsp;}/**&nbsp;*&nbsp;對&nbsp;appId&nbsp;生成簽名&nbsp;*&nbsp;@param&nbsp;appId&nbsp;app&nbsp;id.&nbsp;*&nbsp;@param&nbsp;appKey&nbsp;app&nbsp;key.&nbsp;*&nbsp;@param&nbsp;timestamp&nbsp;時間戳&nbsp;*&nbsp;@param&nbsp;encryptKey&nbsp;加密金鑰串&nbsp;*&nbsp;@return&nbsp;result.&nbsp;*/&nbsp;public&nbsp;String&nbsp;signAppId(String&nbsp;appId,&nbsp;String&nbsp;appKey,&nbsp;Long&nbsp;timestamp,&nbsp;String&nbsp;encryptKey)&nbsp;throws&nbsp;Exception&nbsp;{&nbsp;&nbsp;&nbsp;return&nbsp;this.encryptAppId(appId&nbsp;+&nbsp;&#34;_&#34;&nbsp;+&nbsp;appKey&nbsp;+&nbsp;&#34;_&#34;&nbsp;+&nbsp;timestamp,&nbsp;encryptKey);&nbsp;}&nbsp;public&nbsp;static&nbsp;void&nbsp;main(String[]&nbsp;args){&nbsp;&nbsp;&nbsp;String&nbsp;appId&nbsp;=&nbsp;&#34;tow9e8piyuj23w5e46yj&#34;;&nbsp;&nbsp;&nbsp;String&nbsp;appKey&nbsp;=&nbsp;&#34;$$$8?ze&gt;&lt;&lt;&gt;zuq%8ba#dqmr8dwx1jy&#34;;&nbsp;&nbsp;&nbsp;Long&nbsp;timestamp&nbsp;=&nbsp;1600143987258;&nbsp;&nbsp;&nbsp;String&nbsp;encryptKey&nbsp;=&nbsp;&#34;vcko6mqa2oucmuva&#34;;&nbsp;&nbsp;&nbsp;System.out.println(&#34;sign:&nbsp;&#34;signAppId(appId,appKey,timestamp,encryptKey))&nbsp;}

sign:&nbsp;Uw6yqZKmHZPPMPmDDKNiNXNOHM8RbVJ/aeI/og4Ex0wK48wKxxitjE0Gh3AabQZrU3JwqWRb6Wr8+ZaHKYgHrQ==

當呼叫方呼叫時傳入 sign 和 timestamp 欄位，這樣我們在介面呼叫時可以 sign 欄位進行簽名校驗。在攻擊方不知道加密金鑰時，基本上很難偽造簽名信息。介面校驗是每個介面都需要驗證的，所以我們可以定義公共切面方法對所有介面進行攔截並校驗。

介面切面攔截器

首先，引入 maven 包

&lt;dependency&gt;&nbsp;&nbsp;&lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;&nbsp;&nbsp;&lt;artifactId&gt;spring-boot-starter-aop&lt;/artifactId&gt;&lt;/dependency&gt;

定義切面

/**&nbsp;*&nbsp;定義切點&nbsp;*/@Pointcut(&#34;execution(public&nbsp;*&nbsp;com.test.controller..*(..))&#34;)public&nbsp;void&nbsp;appIdSign()&nbsp;{}/**&nbsp;*&nbsp;執行校驗方法&nbsp;*&nbsp;*&nbsp;@param&nbsp;joinPoint&nbsp;織入點&nbsp;*&nbsp;@throws&nbsp;Exception&nbsp;加密異常&nbsp;*/&nbsp;@Before(&#34;appIdSign()&#34;)&nbsp;public&nbsp;void&nbsp;doVilaSign(JoinPoint&nbsp;joinPoint)&nbsp;throws&nbsp;Exception&nbsp;{&nbsp;&nbsp;&nbsp;HttpServletRequest&nbsp;request&nbsp;=&nbsp;((ServletRequestAttributes)&nbsp;RequestContextHolder.getRequestAttributes()).getRequest();&nbsp;&nbsp;&nbsp;//&nbsp;獲取簽名&nbsp;&nbsp;&nbsp;String&nbsp;appId&nbsp;=&nbsp;request.getHeader(&#34;appId&#34;);&nbsp;&nbsp;&nbsp;String&nbsp;appKey&nbsp;=&nbsp;request.getHeader(&#34;appKey&#34;);&nbsp;&nbsp;&nbsp;String&nbsp;sign&nbsp;=&nbsp;request.getHeader(&#34;sign&#34;);&nbsp;&nbsp;&nbsp;String&nbsp;timestamp&nbsp;=&nbsp;request.getHeader(&#34;timestamp&#34;);&nbsp;&nbsp;&nbsp;logger.debug(&#34;appId:[{}],appKey:[{}],sign:[{}],timestamp:[{}]&#34;,appId,&nbsp;appKey,&nbsp;sign,&nbsp;timestamp);&nbsp;&nbsp;&nbsp;if&nbsp;(StringUtils.isEmpty(appId)&nbsp;||&nbsp;StringUtils.isEmpty(appKey)&nbsp;||&nbsp;StringUtils.isEmpty(sign)||&nbsp;StringUtils.isEmpty(timestamp)&nbsp;||&nbsp;!encryptUtils.appIdMatch(appId,&nbsp;appKey))&nbsp;{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;Exception(&#34;簽名校驗失敗&#34;);&nbsp;&nbsp;&nbsp;}&nbsp;&nbsp;&nbsp;String&nbsp;signValid&nbsp;=&nbsp;encryptUtils.signAppId(timestamp);&nbsp;&nbsp;&nbsp;if&nbsp;(!sign.equals(signValid))&nbsp;{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;throw&nbsp;new&nbsp;Exception(&#34;簽名校驗失敗&#34;);&nbsp;&nbsp;&nbsp;}}

以上，可以做到對 controller 包下的所有介面方法攔截，並獲取請求頭引數，通過請求引數生成 sign 簽名信息並校驗。

雖然以上可以做到簽名校驗，但是，當別人抓包拿到請求頭和請求引數，再重複呼叫我們的介面，還是會有安全問題。所以還需要對介面防重放做攔截。

介面防重基於時間戳

一般呼叫方到後臺的介面時間都遠小於 30s（正常網路情況）。同時，攻擊者抓包並偽造請求時間一般在 30s 之上。在之前我們約定了請求頭資訊包含 timestamp，所以我們可以限制超過當前時間 30s 的請求。

long&nbsp;now&nbsp;=&nbsp;System.currentTimeMillis();//介面防重防，30s&nbsp;有效if&nbsp;((Long.parseLong(timestamp))&nbsp;+&nbsp;30&nbsp;*&nbsp;1000&nbsp;&lt;&nbsp;now)&nbsp;{&nbsp;&nbsp;throw&nbsp;new&nbsp;Exception(&#34;簽名校驗失敗&#34;);}

基於時間戳+隨機數

以上時間限制還是給攻擊者留了 30s 的偽造時間，為了絕對安全，常用的防止重放的機制是使用 timestamp 和 nonce 來做的重放機制。

nonce 是客戶端呼叫方生成的隨機數，在呼叫端將 timestamp + nonce 作為 key 儲存在 redis 中，當客戶端第一次呼叫時先去 redis 查詢是否有該 key 資訊，如果沒有則快取並設定過期時間 (30s)，如果有則拒絕該請求（非法重複請求）。

https 加密

當然，最基礎的安全加密是介面採用 https 協議

http 和 https 的區別

https 可以視為 http+SSL 安全套接層，https 協議需要到 ca 申請證書，客戶端和服務端握手流程大致如下：

the TLS Handshake

圖片來源：https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

在傳統的 HTTP 三次握手之上增加了 SSL 加密認證的過程，保證了資料傳輸的安全性。所以條件允許的情況下，儘量採用 https 介面呼叫。

最後

“魔高一尺道高一丈”

安全無小事，凡事都沒有萬能之法，所以我們在介面設計時需要嚴謹考慮安全性，儘可能做到加密，驗籤，防篡改。

244

演算法

頭排看客

∨ 「Vue 入門系列」第二期，開發環境與 ESLint 配置

熱門排行

劇多

你的介面真的安全嗎？

演算法

頭排看客