前言:
隨着項目前後端分離的火熱，後臺開發的重點主要是對外提供接口，那麼API接口的安全就是要考慮的問題。本文將針對api安全問題進行探討。
目錄
爲什麼前後分離需要關注接口安全問題
接口是通過http請求的方式來請求和獲取數據的，這樣的請求是可以通過抓包工具來攔截請求的，如果不處理的話會有很大的安全隱患。比如獲取短信的接口被攔截那麼別人就可以惡意刷你的短信流量，上傳文件接口被攔截別人可以惡意上傳從而導致服務器崩潰。黑客還可以通過Dos或CSRF來攻擊服務器，
個人覺得安全措施大體來看主要在兩個方面，一方面就是如何保證數據在傳輸過程中的安全性，另一個方面是數據已經到達服務器端，服務器端如何識別數據，如何不被攻擊；所以接口安全還是很重要的。下面具體看看都有哪些安全措施。
攻擊方式有哪些
- 常見的web攻擊方式有：XSS、CSRF、SQL注入、DDOS、重放。
- XSS(跨站腳本攻擊)：對所有用戶提交內容進行可靠的輸入驗證對“<”，“>”，“；”，“””等字符做過濾。
- CSRF(跨站請求僞造 cross site request forgery)：
- 通過僞裝來自受信任用戶的請求來利用受信任的網站，可以利用你的身份發郵件、發短信、進行交易轉賬等，甚至盜取你的賬號
- 例如：你在A網站登錄了賬號，在沒有退出的情況下訪問了B網站，B網站有黑客上傳的圖片且地址爲A網站的接口。如果A網站存在CSRF漏洞那麼你在B網站時相當於你時A的登錄用戶，那麼B的圖片地址請求的接口就被僞造成你的合法請求。
- 防禦：儘量使用POST；cookie設置爲HttpOnly；增加token；通過Referer識別。
- 重放攻擊：利用抓包工具將請求重複多次發送的方式來達到攻擊服務器的目的。可以通過請求時效性來防禦。
如何保障接口的安全
1. 數據加密
我們知道數據在傳輸過程中是很容易被抓包的，如果直接傳輸比如通過 http 協議，那麼用戶傳輸的數據可以被任何人獲取；所以必須對數據加密，常見的做法對關鍵字段加密比如用戶密碼直接通過 md5 加密；現在主流的做法是使用 https 協議，在 http 和 tcp 之間添加一層加密層 (SSL 層)，這一層負責數據的加密和解密。
2. 數據加簽
數據加簽就是由發送者產生一段無法僞造的一段數字串，來保證數據在傳輸過程中不被篡改；你可能會問數據如果已經通過 https 加密了，還有必要進行加簽嗎？數據在傳輸過程中經過加密，理論上就算被抓包，也無法對數據進行篡改；但是我們要知道加密的部分其實只是在外網，現在很多服務在內網中都需要經過很多服務跳轉，所以這裏的加簽可以防止內網中數據被篡改；
3. 時間戳機制
數據是很容易被抓包的，但是經過如上的加密，加簽處理，就算拿到數據也不能看到真實的數據；但是有不法者不關心真實的數據，而是直接拿到抓取的數據包進行惡意請求；這時候可以使用時間戳機制，在每次請求中加入當前的時間，通過timestamp和redis來限制請求的時效首先根據項目情況設定一個有效時長比如設爲60s，當請求到達服務器時首先拿timestamp和系統時間對比，如果在60s內那麼timestamp校驗通過，如果大於60s那麼請求過期。如果只通過timestamp來防重放那麼在60s內還是可以重放請求的，所以這樣還是不夠的。我們還需要設置一個nonce。請求到達服務器時去redis中查找key爲nonce:{sign}的string，如果沒有就創建這個key並把失效期設置爲timestamp的失效期比如是60s，如果有說明在60s內這個請求已經請求過那麼這個請求可以判斷爲重放請求。
4. 白名單機制
如果請求的服務器是已知的，可以在服務端判斷請求api的服務器的ip是否是約定好的，例如：A部門（192.168.1.1）和B部門（192.168.1.2）需要通過公網進行遠程數據調用（方法XXX）。那麼B部門在方法XXX被調用的時候，判斷時候和已經保存在redis或者數據庫中的A部門服務器ip是否一致，如果一致，則放行，如果不一致則終止調用。
5. AppId 機制
大部分網站基本都需要用戶名和密碼才能登錄，並不是誰來能使用我的網站，這其實也是一種安全機制；對應的對外提供的接口其實也需要這麼一種機制，並不是誰都可以調用，需要使用接口的用戶需要在後臺開通 appid，提供給用戶相關的密鑰；在調用的接口中需要提供 appid + 密鑰，服務器端會進行相關的驗證；
6. 黑名單機制
與白名單相對應的就是白名單機制：黑名單是適用於，開放給多個客戶使用的一種安全手段，假設你不知道調用方的具體信息，並且不能將全部調用都禁止調，那麼可以採用黑名單機制。黑名單是基於公司內部的安全規則來規定的，比如，公司規定，1分鐘調用5次，就拉入黑名單等等。
7. 限流機制
此方法是針對服務器的某個具體的方法而言，並不是針對調用者的。具體方法是，假設方法AAA請求量過大。我們可以使用業內開源的一些方法來進行處理，常見的算法有，漏桶限流，令牌桶限流。和計數器限流，這裏就不細講了，感興趣的可以留言或者百度即可。
總結：
本文總結了一些常用api安全的方法，各位可以基於自己業務的需求，選擇性使用即可。過多的限制和判斷必然會導致性能的下降和代碼維護難度的增加
創作不易，各位的支持和認可，就是我創作的最大動力，
【轉載請聯繫本人】 如有問題，請聯繫我。歡迎斧正！不勝感激 ！
求點贊👍 求關注❤️ 求分享👥 求留言📪