1.應用場景
| 主要用於接口安全. |
2.學習/操作
|
對外接口安全措施的作用主要體現在兩個方面，一方面是如何保證數據在傳輸過程中的安全性，另一方面是數據已經到達服務器端，服務器端如何識別數據，如何不被攻擊。此前，一位網名爲 ksfzhaohui 的高級程序員在開源中國社區分享了一些常用的安全措施以及實現方法，希望給廣大開發者參考。
1. 數據加密 數據在傳輸過程中是很容易被抓包的，如果直接傳輸，數據可以被任何人獲取，所以必須對數據加密。加密方式有對稱加密和非對稱加密：對稱加密：對稱密鑰在加密和解密的過程中使用的密鑰是相同的，常見的對稱加密算法有 DES、AES。優點是計算速度快，缺點是在數據傳送前，發送方和接收方必須商定好密鑰，並完好保存。如果一方的密鑰被泄露，那麼加密信息也就不安全了；非對稱加密：服務端會生成一對密鑰，私鑰存放在服務器端，公鑰可以發佈給任何人使用。與對稱加密相比，這種方式更安全，但速度慢太多了。現在主流的做法是使用 HTTPS 協議，在 HTTP 和 TCP 之間添加一層加密層 (SSL 層)，這一層負責數據的加密和解密。HTTPS 的實現方式結合了對稱加密與非對稱加密的優點，在安全和性能方面都比較突出。
2. 數據加簽 數據加簽就是由發送者產生一段無法僞造的數字串，來保證數據在傳輸過程中不被篡改。數據如果已經通過 HTTPS 加密了，其加密部分只是在外網，而加簽可以防止內網中數據被篡改。數據簽名使用較多的是 MD5 算法，將需要提交的數據通過某種方式組合，然後通過 MD5 生成一段加密字符串，這段加密字符串就是數據包的簽名。而其中的用戶密鑰，客戶端和服務端都保留一份，會更加安全。
3. 時間戳機制 數據經過如上的加密、加簽處理後，就算被抓包也不能看到真實的數據。但是有的不法者不關心真實數據，而是直接拿到抓取的數據包進行惡意請求。這時可以使用時間戳機制，在每次請求中加入當前的時間，服務器端會拿到當前時間與消息中的時間相減，看看是否在一個固定的時間範圍內，比如 5 分鐘，這樣惡意請求的數據包是無法更改時間的，所以 5 分鐘後就視爲非法請求了。
4. AppID 機制 大部分網站都需要用戶名和密碼才能登錄，這其實也是一種安全機制。相應的對外接口也需要這麼一種機制，使用接口的用戶需要在後臺開通 AppID，提供給用戶相關的密鑰。在調用的接口中需要提供 AppID+ 密鑰，服務器端會進行相關的驗證。生成唯一的 AppID 即可，根據實際情況看是否需要全局唯一，同時密鑰使用字母、數字等特殊字符隨機生成。
5. 限流機制 本來就是真實的用戶，並且開通了 AppID，但出現了頻繁調用接口的情況，這時需要給相關 AppID 限流處理，常用的限流算法包括：令牌桶限流、漏桶限流、計數器限流。令牌桶算法的原理是系統以一定速率向桶中放入令牌，填滿了就丟棄令牌。請求來時會先從桶中取出令牌，如果能取到令牌，則可以繼續完成請求，否則等待或者拒絕服務。令牌桶允許一定程度突發流量，只要有令牌就可以處理，支持一次拿多個令牌。漏桶算法的原理是按照固定常量速率流出請求，流入請求速率任意，當請求數超過桶的容量時，新的請求等待或者拒絕服務，漏桶算法可以強制限制數據的傳輸速度。計數器算法比較簡單粗暴，主要用來限制總併發數，比如數據庫連接池、線程池、秒殺的併發數。計數器限流只要一定時間內的總請求數超過設定的閥值，就會進行限流。
6. 黑名單機制 如果一個 AppID 進行過很多非法操作，或者專門有一箇中黑系統，經過分析之後可以直接將此 AppID 列入黑名單，所有請求直接返回錯誤碼。如何查看黑名單列表呢？可以給用戶設置一個狀態比如：初始化狀態、正常狀態、中黑狀態、關閉狀態等等。或者直接通過分佈式配置中心，保存黑名單列表，每次檢查用戶是否在列表中即可。
7. 數據合法性校驗 這是每個系統都會有的處理機制，只有在數據合法的情況下才會進行數據處理。每個系統都有自己的驗證規則，當然也可能有一些常規性的規則，比如身份證號碼長度和組成、電話號碼長度和組成等等。合法性校驗包括常規性校驗以及業務校驗，前者包括簽名校驗、必填校驗、長度校驗、類型校驗、格式校驗等，後者根據實際業務而定，比如訂單金額不能小於 0 等等。
以上就是幾種常見的安全措施機制，也歡迎你在評論區補充其他方式. |
3.問題/補充
|
1.WiFi是什麼, 有絕對安全的WiFi嗎? TBD
2.如何取得路由器的管理員密碼? TBD
3.如何避免在網絡中暴露的位置信息 TBD |
4.參考
|
https://time.geekbang.org/column/article/224701 //如何設計一個安全的對外接口？ https://blog.csdn.net/william_n/article/details/103453284 //接口鑑權 |
後續補充
...