前言
日常開發中少不了和第三方服務進行交互，我們經常會提供對外接口給第三方服務調用，這種接口是直接在公網暴露給第三方的，接口安全性是必須要考慮的，接口總不能在公網上直接裸奔吧。這裏和大家一起總結下公網接口安全性問題。安全措施大體來看主要在兩個方面，一方面就是如何保證數據在傳輸過程中的安全性，另一個方面是數據已經到達服務器端，服務器端如何識別數據，如何不被攻擊；下面具體看看都有哪些安全措施。
數據加密
我們知道數據在傳輸過程中是很容易被抓包的，如果直接通過http協議傳輸，用戶傳輸的數據可以被任何人獲取；所以必須對數據加密，常見的做法對關鍵字段加密比如用戶密碼直接通過md5加密；現在主流的做法是使用https協議，在http和tcp之間添加一層加密層(SSL層)，這一層負責數據的加密和解密。主流的加密方式有對稱加密和非對稱加密。
對稱加密：對稱密鑰在加解密過程中使用的密鑰是相同的，常見的對稱加密算法有DES，AES；優點是計算速度快，缺點是在數據傳送前，發送方和接收方必須商定好祕鑰，然後使雙方都能保存好祕鑰，如果一方的祕鑰被泄露，那麼加密信息也就不安全了。
非對稱加密：服務端會生成一對密鑰，私鑰存放在服務器端，公鑰可以發佈給任何人使用；優點就是比起對稱加密更加安全，但是加解密的速度比對稱加密慢太多了；廣泛使用的是RSA算法。兩種方式各有優缺點，而https的實現方式正好是結合了兩種加密方式，整合了雙方的優點，在安全和性能方面都比較好。
AppId機制
大部分網站基本都需要用戶名和密碼才能登錄，並不是誰都能使用我的網站，這其實也是一種安全機制；對應的對外提供的接口其實也需要這麼一種機制，並不是誰都可以調用，需要使用接口的用戶需要在後臺開通appid，提供給用戶相關的密鑰；在調用的接口中需要提供appid+密鑰，服務器端會進行相關的驗證。
生成一個唯一的AppId，密鑰使用字母、數字等特殊字符隨機生成即可；生成唯一AppId根據實際情況看是否需要全局唯一；但是不管是否全局唯一最好讓生成的Id儘量不要連續的，容易發現規律，常見的有類snowflake方式等。
sign機制
參數簽名是防止參數被非法篡改。sign的值一般是將所有非空參數按照升續排序然後+token+key+timestamp+nonce(隨機數)拼接在一起，然後使用某種加密算法進行加密，作爲接口中的一個參數sign來傳遞，也可以將sign放到請求頭中。接口在網絡傳輸過程中如果被黑客挾持，並修改其中的參數值，然後再繼續調用接口，雖然參數的值被修改了，但是因爲黑客不知道sign是如何計算出來的，不知道sign都有哪些值構成，不知道以怎樣的順序拼接在一起的，最重要的是不知道簽名字符串中的key是什麼，所以黑客可以篡改參數的值，但沒法修改sign的值，當服務器調用接口前會按照sign的規則重新計算出sign的值然後和接口傳遞的sign參數的值做比較，如果相等表示參數值沒有被篡改，如果不等，表示參數被非法篡改了，就不執行接口了。數據簽名使用比較多的是md5算法，將需要提交的數據通過某種方式組合和一個字符串，然後通過md5生成一段加密字符串，這段加密字符串就是數據包的簽名，可以看一個簡單的例子：
str：參數1={參數1}&參數2={參數2}&……&參數n={參數n}$key={用戶密鑰};
MD5.encrypt(str);
時間戳機制
數據是很容易被抓包的，經過如上的加密，加簽處理，就算拿到數據也不能看到真實的數據；但是有不法者不關心真實的數據，而是直接拿到抓取的數據包進行惡意請求；比如常見的DoS攻擊，當黑客劫持了請求的url去DoS攻擊，每次調用接口時接口都會判斷服務器當前系統時間和接口中傳的的timestamp的差值，如果這個差值超過某個設置的時間(假如5分鐘)，那麼這個請求將被攔截掉，如果在設置的超時時間範圍內，是不能阻止DoS攻擊的。時間戳機制只能減輕DoS攻擊的時間，縮短攻擊時間。如果黑客修改了時間戳的值可通過sign簽名機制來處理。
DoS攻擊
DoS是Denial of Service的簡稱，即拒絕服務，造成DoS的攻擊行爲被稱爲DoS攻擊，其目的是使計算機或網絡無法提供正常的服務。最常見的DoS攻擊有計算機網絡帶寬攻擊和連通性攻擊。
DoS攻擊是指故意的攻擊網絡協議實現的缺陷或直接通過野蠻手段殘忍地耗盡被攻擊對象的資源，目的是讓目標計算機或網絡無法提供正常的服務或資源訪問，使目標系統服務系統停止響應甚至崩潰，而在此攻擊中並不包括侵入目標服務器或目標網絡設備。這些服務資源包括網絡帶寬，文件系統空間容量，開放的進程或者允許的連接。這種攻擊會導致資源的匱乏，無論計算機的處理速度多快、內存容量多大、網絡帶寬的速度多快都無法避免這種攻擊帶來的後果。
-
Pingflood: 該攻擊在短時間內向目的主機發送大量ping包，造成網絡堵塞或主機資源耗盡。
-
Synflood: 該攻擊以多個隨機的源主機地址向目的主機發送SYN包，而在收到目的主機的SYN ACK後並不迴應，這樣，目的主機就爲這些源主機建立了大量的連接隊列，而且由於沒有收到ACK一直維護着這些隊列，造成了資源的大量消耗而不能向正常請求提供服務。
-
Smurf：該攻擊向一個子網的廣播地址發一個帶有特定請求（如ICMP迴應請求）的包，並且將源地址僞裝成想要攻擊的主機地址。子網上所有主機都回應廣播包請求而向被攻擊主機發包，使該主機受到攻擊。
-
Land-based：攻擊者將一個包的源地址和目的地址都設置爲目標主機的地址，然後將該包通過IP欺騙的方式發送給被攻擊主機，這種包可以造成被攻擊主機因試圖與自己建立連接而陷入死循環，從而很大程度地降低了系統性能。
-
Ping of Death：根據TCP/IP的規範，一個包的長度最大爲65536字節。儘管一個包的長度不能超過65536字節，但是一個包分成的多個片段的疊加卻能做到。當一個主機收到了長度大於65536字節的包時，就是受到了Ping of Death攻擊，該攻擊會造成主機的宕機。
-
Teardrop：IP數據包在網絡傳遞時，數據包可以分成更小的片段。攻擊者可以通過發送兩段（或者更多）數據包來實現TearDrop攻擊。第一個包的偏移量爲0，長度爲N，第二個包的偏移量小於N。爲了合併這些數據段，TCP/IP堆棧會分配超乎尋常的巨大資源，從而造成系統資源的缺乏甚至機器的重新啓動。
-
PingSweep：使用ICMP Echo輪詢多個主機。
限流機制
本來就是真實的用戶，並且開通了appid，但是出現頻繁調用接口的情況；這種情況需要給相關appid限流處理，常用的限流算法有令牌桶和漏桶算法；具體的限流機制可以參見這篇文章分佈式服務限流實戰。
黑、白名單機制
如果此appid進行過很多非法操作，或者說專門有一箇中黑系統，經過分析之後直接將此appid列入黑名單，所有請求直接返回錯誤碼；或者我們可以列舉了一個IP白名單，只有在白名單列表中的IP才能訪問我們的接口，具體白名單可以在Nginx配置文件中配置，也可以在服務內部的配置文件中配置，在服務接口邏輯中做白名單匹配。
數據合法性校驗
這個可以說是每個系統都會有的處理機制，只有在數據是合法的情況下才會進行數據處理；每個系統都有自己的驗證規則，當然也可能有一些常規性的規則，比如身份證長度和組成，電話號碼長度和組成等等。
總結
上面這些只是從大體概念上講解接口安全性，能讓大家在設計對外接口的時候考慮這些問題。具體的設計細節，我們還需要結合項目中的實際場景進行設計。最近肺炎比較嚴重，走親戚不方便，還是在家多學習總結，不給醫護人員添亂，加油武漢！