常見的 API 安全漏洞類型有哪些

常見的API安全漏洞類型有以下這些：

• 未受保護API：在現行的Open API開放平臺中，一般需要對第三方廠商的API接入身份進行監管和審核，通過準入審核機制來保護API。當某個API因未受保護而被攻破后，會直接導致對內部應用程序或內部API的攻擊。比如因REST、SOAP保護機制不全使攻擊者透明地訪問后端系統即屬于此類。

• 弱身份鑒別：當API暴露給公眾調用時，為了保障用戶的可信性，必須對調用用戶進行身份認證。因設計缺陷導致對用戶身份的鑒別和保護機制不全而被攻擊，比如弱密碼、硬編碼、暴力破解等。

• 中間人劫持：因API的通信鏈路安全機制不全，攻擊者通過攻擊手段將自己成為API鏈中的某個受信任鏈，從而攔截數據以進行數據篡改或加密卸載。此類攻擊，通常發生在網絡鏈路層。

• 傳統Web攻擊：在這里主要是指傳統Web攻擊類型，通過攻擊HTTP協議中不同的參數，來達到攻擊目的，比如SQL注入、LDAP注入、XXE等。而攻擊者在進一步攻擊中，會利用權限控制缺失、CSRF進行橫向移動，從而獲取更大的戰果。

• 弱會話控制：有時API身份鑒別沒有問題，但對會話過程安全保護不足，比如會話令牌（Cookie、一次性URL、SAML令牌和OAuth令牌）的保護。會話令牌是使API服務器知道誰在調用它的主要（通常是唯一的）方法，如果令牌遭到破壞、重放或被欺騙，API服務器很難區分是否是惡意攻擊行為。

• 反向控制：與傳統的交互技術不同，API通常連接著兩端。傳統的應用中大多數安全協議都認為信任服務器端是可信的，而在API中，服務器端和客戶端都不可信。如果服務器端被控制，則反向導致調用API的客戶端出現安全問題，這是此類安全問題出現的原因。

• 框架攻擊：在API安全威脅中，有一些特殊存在的攻擊場景，它們是API規范、架構設計導致的安全問題，這類威脅統稱為框架攻擊。最常見的比如同一API存在不同版本，導致攻擊者攻擊低版本API漏洞；同一API的不同客戶端調用，可能PC端沒有安全問題而移動端存在安全問題等。

加強API安全的措施有以下這些：

• 數據加密：必須對數據加密，常見的做法對關鍵字段加密比如用戶密碼直接通過md5加密，現在主流的做法是使用https協議 ，在http和tcp之間添加一層加密層(SSL層)，這一層負責數據的加密和解密。

• 數據加簽：數據加簽 就是由發送者產生一段無法偽造的一段數字串，來保證數據在傳輸過程中不被篡改。數據在傳輸過程中經過加密，理論上就算被抓包，也無法對數據進行篡改，但是我們要知道加密的部分其實只是在外網，現在很多服務在內網中都需要經過很多服務跳轉，所以這里的加簽可以防止內網中數據被篡改。

• 時間戳機制：但是有不法者不關心真實的數據，而是直接拿到抓取的數據包進行惡意請求。這時候可以使用時間戳機制，在每次請求中加入當前的時間，服務器端會拿到當前時間和消息中的時間相減，看看是否在一個固定的時間范圍內比如5分鐘內。這樣惡意請求的數據包是無法更改里面時間的，所以5分鐘后就視為非法請求了。

• AppId機制：大部分網站基本都需要用戶名和密碼才能登錄，并不是誰來能使用我的網站，這其實也是一種安全機制。對應的對外提供的接口其實也需要這么一種機制，并不是誰都可以調用，需要使用接口的用戶需要在后臺開通appid，提供給用戶相關的密鑰。在調用的接口中需要提供 appid+密鑰，服務器端會進行相關的驗證。

• 限流機制：本來就是真實的用戶，并且開通了appid，但是出現頻繁調用接口的情況。這種情況需要給相關appid限流處理，常用的限流算法有令牌桶和漏桶算法。

• 黑名單機制：如果此appid進行過很多非法操作，或者說專門有一個中黑系統，經過分析之后直接將此appid列入黑名單，所有請求直接返回錯誤碼。

• 數據合法性校驗：這個可以說是每個系統都會有的處理機制，只有在數據是合法的情況下才會進行數據處理。每個系統都有自己的驗證規則，當然也可能有一些常規性的規則，比如身份證長度和組成，電話號碼長度和組成等等。

回答所涉及的環境：聯想天逸510S、Windows 10。