API網絡數據安全

前言

個推做爲國內第三方推送市場的早期進入者，專一於爲開發者提供高效穩定的服務，在保證穩定的狀況下，咱們的網絡數據交互也達到了一個很高的級別，今天給你們分享的是網絡數據安全的經常使用方法

簡介

TCP/IP做爲互聯網使用的標準協議集，在設計之初就是創建在接入主機互相信任的前提下，缺少對安全方面的考慮，而且爲了保證網絡的開放性，TCP/IP協議的內容是徹底公開的。所以，只使用TCP/IP協議在互聯網上傳輸的數據，實際上都是不安全的。 在SDK開發場景下，一般會在API設計時加入一些網絡安全的措施，這裏主要從數據防泄露、內容防篡改、身份放假裝、請求防重放幾個方面分析如何保證API網絡數據安全。

數據防泄露

爲了保證數據的機密性，通常會對數據作加密操做，這樣即使數據在傳輸時被抓取，也須要解密才能獲取真實數據。而要加密就須要用到加密算法，下面按兩種粗略的分類介紹下不一樣加密算法的特色，如何選擇合適的加密算法，以及加密算法使用的密鑰該如何管理。

公開加密與非公開加密算法

按照算法是否公開的特色，加密算法可分爲公開算法和非公開算法。

• 公開加密算法 加密算法公開，密碼的安全基於密鑰的安全
• 非公開加密算法 加密算法不公開，只有開發人員知道，密碼的安全性基於加密算法的安全；

建議使用公開加密算法。公開算法由於受全世界的密碼學者研究，經受了很大的考驗，加密強度有保障。而非公開算法除了做者以外基本上沒人看過，加密的強度沒有保障。一旦加密方式泄露，非公開加密算法須要作修改算法這種複雜操做來補救，而公開加密算法原本就是公開的，只要密鑰不泄露就是安全的，即便密鑰泄露也只需更換密鑰的簡單操做便可。 ##對稱加密與非對稱加密 按照密鑰的特色，公開加密算法又能夠分爲對稱算法和非對稱算法

• 對稱加密算法 只有一個密鑰，簡稱私鑰，加密和解密使用同一個密鑰 特色：計算量小，速度快，密鑰交換複雜 常見的對稱加密算法：DES，AES，TDEA 等
• 非對稱加密算法 有一對密鑰，可公開的公鑰與補課公開的密鑰，用其中一個密鑰對數據進行加密後，只有用對應的另外一個密鑰才能解密。 特色：計算量大，速度較慢，支持數字簽名，密鑰交換簡單。 常見的非對稱加密算法：RSA，Elgamal，Rabin，ECC，D-H。

實際使用中一般採用非對稱加密算法管理對稱算法的密鑰，而後用對稱加密算法加密數據，這樣咱們就集成了兩類加密算法的優勢，既實現了加密速度快的優勢，又實現了安全方便管理密鑰的優勢。

內容防篡改

數據在網絡的傳輸過程當中，頗有可能被攔截並對內容進行篡改，對於這種狀況，一般在傳輸內容中增長特定哈希算法生成的hash值，用來校驗內容是否被篡改過，以保證數據的完整性。

常見的哈希函數有 md4,md5,sha-1等，一般會在請求或響應的內容體中增長一個校驗參數sign，爲了增長破解的難度，校驗參數通常不會只是簡單地對內容進行哈希運算生成，而是使用一種被稱爲加鹽哈希的操做。 具體作法能夠是在內容中增長一些別的參數，好比SDK開發場景中一般會由開發者平臺生成一個appSecretKey，能夠把這個key放入請求內容中的特定位置，而後在再用哈希函數生成hash值，這以後還能夠根據須要多進行幾回哈希操做，好比先用md5作哈希計算生成hash值，再把這個值當成鹽放到下次的sha-1計算中等等。 接收端在接收到內容時使用一樣的哈希操做計算sign值，並將兩個sign值進行比對，若是不同則說明內容被篡改過了。

身份假裝

在網絡通訊中，通訊雙方的身份驗證也是網絡安全中很是重要的一環，它既能夠保證網絡通訊雙方的身份，又能夠防止經過網絡完成交易時，交易方宣稱交易沒發生過的抵賴行爲，保證了通訊雙方身份的可鑑別和通訊過程的不可抵賴。在SDK開發中，因爲api接口是對外公開的，所以對客戶端的身份校驗通常不會很嚴格，主要是對服務端的身份驗證。

Token 身份校驗

服務端爲了防止接口的未受權調用，一般會生成一個用於標識客戶端身份的token，客戶端在調用接口時在請求頭中添加token，服務端檢查token是否有效，若是有效則說明客戶端的身份可靠，能夠返回響應數據，一般會對token設置一個有效期以防止token泄露後的長期非法調用。若是對客戶端身份驗證要求較嚴，能夠將token的生成與apk的簽名文件關聯起來，若是不是使用指定簽名的客戶端，則沒法經過校驗。

數字簽名

服務端通常經過數字簽名的方式支持身份驗證，數字簽名是非對稱加密算法的另外一種用法，用私鑰加密，用公鑰解密，它能夠提供和現實中親筆簽名類似的效果，在技術上和法律上都有保證。 數字簽名與驗證過程：

• 發送方用哈希函數從報文文本中生成一個hash值；
• 發送方用本身的私鑰對這個hash值進行加密造成本身的數字簽名；
• 發送方將數字簽名和報文一塊兒發送給接收方；
• 接收方收到報文後，用一樣的哈希函數從原始報文中計算出hash值；
• 接收方再用發送方的公鑰來對報文附加的數字簽名進行解密得出另外一個hash值；
• 若是兩個hash值相同，那麼接收方就能確認該數字簽名是發送方的；

請求重放

即便傳輸的數據是通過加密的，竊聽者沒法獲得數據的準肯定義，但從請求的地址分析出這些數據的做用以後，能夠經過原封不動地屢次發送這條請求進行攻擊，就拿最簡單的數據入庫操做，若是API接口沒有作對應的安全防禦，將可能形成屢次入庫的嚴重後果。

爲了不這種狀況，一般會在請求中增長一些用於校驗的參數，好比時間戳、隨機數、流水號等等，下面簡單介紹一下這幾種方式的特色，以及經常使用方案。

加時間戳

在請求中增長一個時間戳，服務端將時間戳跟當前時間對比，若是時間差大於必定值(好比1分鐘)，則能夠認爲該請求失效。這種方式沒法防止在指定時間差內的重放攻擊，好比時間差是1分鐘的話，那麼只須要在1分鐘內完成重放攻擊便可。

加隨機數

在請求中增長一個隨機數，服務端檢查緩存中是否有相同的隨機數，若是有則認爲是無效請求，若是沒有則將其加入緩存。這種方式的問題在於，服務端不可能緩存全部請求的隨機數，只能緩存一部分，若是重放攻擊內包含的隨機數恰好被清除了，則依然能被攻擊。

加流水號

在請求中增長一個遞增的流水號，服務端若是收到的流水號不是連續遞增的，就認爲是無效請求。這種方式的缺點在於流水號的變化太過單調了，很容易就能被識別出來並作對應的修改。

時間戳+隨機數

經常使用的方案是把時間戳和隨機數配合使用，給每次請求都增長一個當前時間的時間戳timestamp，和一個隨機數nonce。服務端收到請求時，先檢查時間戳是否超時，若是超時則認爲是無效請求，若是沒超時再檢查緩存中是否有相同的nonce，若是有則認爲是無效請求，若是沒有則將其加入緩存，服務端只須要緩存超時時間內的nonce記錄便可。

使用 https

前面介紹的這些網絡安全的相關手段，若是實際開發中要嚴格按照上面的標準實現的話，仍是須要花費一些時間的，那麼有沒有一種快速簡單的方式來實現上面提到的那些功能呢，答案是有的，那就是直接使用Https。 Https其實是由Http+SSL組成，SSL可以提供數據加密、身份驗證功能，只需再加上簡單的防篡改和防重放功能便可知足上面的數據防泄密、內容防篡改、身份防假裝、請求防重放四個要求。

SSL/TLS

SSL是Netscape公司研發的用於保障數據在互聯網上安全傳輸的協議，SSL在更新到3.0時，IETF(互聯網工程任務組)對SSL3.0進行了標準化，添加了少數機制，並將其改名爲TLS。 SSL/TLS創建安全通訊的過程大概能夠分爲三步：

1. 對等協商支持的密鑰算法；
2. 基於公鑰加密的對稱密鑰交換，基於證書的身份認證；
3. 基於對稱加密的數據傳輸保密

數字證書

使用Https時，須要用到數字證書，數字證書的原理其實仍是前面說到的數字簽名，通常數字證書都是由CA機構用私鑰簽發的，固然也有企業本身用私鑰簽發的數字證書，只是這種證書默認是不被信任的，使用數字證書能夠有效地防止參數篡改和身份假裝。 數字證書的大體生成過程以下圖：

步驟：

1. 根據證書內容（好比公司名，公司稅號等）使用哈希算法生成一個證書摘要
2. 拿這個哈希過的摘要進行 RAS 加密。
3. 加密的數據又存放到證書中

數字證書的驗證過程大體以下圖：

步驟：

1. 在創建連接以前，下載證書進行校驗
2. 對證書內容進行哈希等到數字摘要 H1
3. 使用密鑰解密數字簽名獲得數組摘要 H2
4. 若是 H1=H2 則認爲校驗經過

在SDK開發中，使用CA頒發頒發的證書和使用自生成的證書差異並不大，主要區別在於，若是使用CA頒發的證書，只需在SDK中使用系統自帶的信任證書庫驗證便可（系統默認內置CA機構根證書），若是使用自生成的證書，則須要在SDK中導入證書或公鑰用於證書驗證過程。

單向與雙向認證

• 單向驗證 客戶端須要驗證服務器的身份，服務端不須要驗證客戶端身份。

• 雙向驗證 客戶端須要驗證服務器身份，服務端也須要驗證客戶端身份。 使用單向驗證仍是雙向驗證，一般是由服務端提供的服務決定的。通常狀況下服務器是對全部客戶端開放的，因此默認的配置是單向驗證。若是要限制訪問的客戶端，則須要在服務端開啓雙向驗證。

書籍推薦

《TCP-IP 詳解 卷一》，《圖解 Http》

總結

安全是個大課題，這篇文章僅是基於網絡安全這個很小的點進行拓展。後續還會出 設備安全，數據安全，代碼安全等文章,但願你們多多關照。