對於api安全性的思考

　　目前的狀況下api被不少地方應用，隨之而來的是api的安全性問題。

　　我所認識到的安全性問題有如下幾個方面：
　　一、DDoS(拒絕服務攻擊)，接口被惡意調用，使真實的用戶沒法享受到正常暢通的服務。
    　　這個比較單純，也比較容易處理，經過IP限制來作，而且輔以一些硬件設備應該就沒問題了，同時服務器供應商也能夠提供相應的服務。

　　二、傳輸過程當中數據被截獲，http數據包是能夠被截獲到的，這一點咱們沒法防止，能作的只有使被截獲到的數據對截獲者來講無心義。
    　　這個問題要分紅兩種狀況來講明，第一種狀況，api站點採用了https，那麼在網絡中傳輸的數據就是被加密過的數據，這種數據截獲者很難把他解密出來，因此能夠保證數據的安全性。第二狀況，api站點沒有采用https，而是使用的普通的http，若是不加任何處理其實傳輸的數據是在裸奔，固然有些數據就是給截獲者截獲到也沒有什麼影響，但對於敏感的信息咱們仍是要想辦法來處理下的，要麼協商一種相同的加密方法，這樣起到加密做用。另外請求時使用token不直接傳以明文密碼暴露的機會，同時最好是在傳輸前就把信息MD5一下，這樣對用戶的在網站上的安全性是有好處的。總的來講不使用https的傳輸是不安全的，有意義的敏感信息有可能會被截獲到，建議在登陸相關的接口有條件時必定使用https，若是使用http登陸也必定要處理一下敏感信息，好比這樣MD5(變形(MD5(原文)))，這樣即便被截獲也能夠保證截獲人不能獲得原文，也就保證了用戶在其餘網站上賬號的安全。

　　三、僞造請求，在上一種狀況的基礎上，截獲者能夠利用截獲到的數據發起僞造的請求，固然https不會有這個問題。
    　　解決這個問題的一個方法是，讓請求成爲一次性的或者說只能在短期內有效，能夠在參數中再加入一個簽名（sign），簽名是由時間戳加參數MD5構成的，這樣能夠在服務端驗證其有效性與時效性，這個方法在他人不知道簽名生成規則時是有效的。可是若是程序被反編譯就能夠比較容易的知道生成規則。更靠譜一點的話就在生成sign時增長key值（不過這對app並非太適用，由於若是key改變就要更新app），不過這樣仍是躲不過反編譯，因而防止反編譯也是重要的一環了。另外的一個途徑是保證數據確實是從真實的客戶端發出來的，這個就要從token上想辦法了，例如對比IP，但這種途徑顯得比較蒼白無力同時有侷限性（如第一次登陸，同時IP在實際狀況下發生變化也不該該被認爲不合法）。還有能夠在重要的操做時應用二次受權，這樣能夠下降風險。

 

附：

一、 傳輸中加上簽名sign不是爲了防止被截獲，而是爲了防止被篡改或發出僞造請求。

二、 數字簽名是對所傳輸數據的散列後的摘要使用私鑰加密獲得的結果，
　　數字簽名使得接收方能夠確認信息是可靠的，由於只有指定私鑰加密的內容接收方纔能夠解密出來。
　　對於指定的MD5結果，能夠有方法找到多個文本與之對應。即單次單純的MD5是不夠安全的，能夠經過MD5(變形(MD5(原文)))來解決這個問題。
三、 數字證書是由權威機構用本身的私鑰加密服用提供方的公鑰並搭載其餘相關信息組成的。

四、 使用token是爲了惟一標識用戶，應該在數據庫中維護這些數據，它應有的關聯屬性（用戶ID、IP、到期時間、是否有效）