20多年的開發(fā)部署后，API已經(jīng)到處都是。2021年的調(diào)查研究中，73%的企業(yè)表示自己已經(jīng)發(fā)布了超過50個API，且這一數(shù)字還在不斷增長。

API在當今幾乎每個行業(yè)里都起著舉足輕重的作用，而且隨著它們逐漸邁向業(yè)務戰(zhàn)略前沿，其重要性還在平穩(wěn)上升。出現(xiàn)這種現(xiàn)象其實毫不意外：API無縫連接不同應用和設備，帶來前所未有的業(yè)務協(xié)同效應和效率。

[[416116]]

但是，與軟件任何其他組件一樣，API也免不了存在漏洞?；诖?，如果沒有經(jīng)過間隔的安全測試，API也有可能引入全新的攻擊途徑，將用戶暴露在前所未有的風險之下。坐等生產(chǎn)部門發(fā)現(xiàn)API漏洞是不現(xiàn)實的，你只會等來嚴重延遲。

API不僅受廣大企業(yè)青睞，也是攻擊者眼中的香餑餑

API可不僅僅是簡單連接企業(yè)各種應用，它們還會以無法預測的方式改變功能。API可能引入的很多獨特缺陷都廣為黑客所知，他們開發(fā)出不同方法攻擊API，從而訪問底層數(shù)據(jù)和功能。

開放Web應用安全項目(OWASP)的API Top 10表明，通過身份驗證的合法用戶利用API漏洞的情況并不鮮見，此類用戶利用看似合法的調(diào)用，實際上卻意圖篡改API。這種攻擊旨在篡改業(yè)務邏輯并利用設計缺陷，對攻擊者極具吸引力。

每個API都是獨特且專有的。因此，其軟件漏洞也是獨特且“未知”的。防御者很難發(fā)現(xiàn)這類可導致業(yè)務邏輯或業(yè)務過程級攻擊的漏洞。

圖1：業(yè)務邏輯漏洞和傳統(tǒng)漏洞

是否給予了API安全測試足夠的重視?

左移安全已廣為多數(shù)企業(yè)接受，整個開發(fā)過程貫穿持續(xù)測試的做法已成常規(guī)。然而，API安全測試常被漏掉，或者執(zhí)行時缺乏對所涉風險的重復理解。為什么會這樣?原因不止一個：

• 現(xiàn)有應用安全測試工具是通用型，目標檢出對象是傳統(tǒng)Web應用漏洞，無法有效處理API的業(yè)務邏輯復雜性。
• 由于API沒有用戶界面，企業(yè)通常需要單獨測試Web、應用和移動端，但不測試API本身。
• API測試可能很是耗費人工，在擁有幾百個API時是無法擴展的。
• 由于API測試比其他測試類型更復雜，企業(yè)可能缺乏相關經(jīng)驗和專業(yè)技能。
• 無法確知已經(jīng)部署了哪些老舊API，或者找不到老舊API的文檔。

因此，盡管左移安全已普遍受到大多數(shù)企業(yè)重視，但API安全測試卻常被排除在DevSecOps藍圖之外。

這是個令人遺憾的狀況，因為相比傳統(tǒng)應用漏洞，API漏洞需要更長的響應時間：近期一項調(diào)查中，63%的受訪者報告稱需要更長時間來修復API漏洞?？紤]到應用對API的依賴和快速采用情況，這一數(shù)字可能還會繼續(xù)上升。

圖2：相比傳統(tǒng)應用漏洞，存在API漏洞情況下的平均修復時間

雖然大多數(shù)安全主管都意識到了API安全測試的重要性，但仍有近一半的安全主管稱自己尚未將API安全測試解決方案完全集成進開發(fā)流水線中。

為什么常規(guī)安全測試方法無法覆蓋API?

要實現(xiàn)全面的安全方法，第一步就是仔細考察當前對于應用安全測試的普遍態(tài)度：靜態(tài)安全測試和動態(tài)安全測試。

靜態(tài)安全測試采用白盒測試方法，基于應用的已知功能創(chuàng)建測試，審查應用的設計、架構或代碼，包括數(shù)據(jù)在流經(jīng)應用時可采取的諸多復雜路徑。

動態(tài)安全測試采用黑盒測試方法，基于應用攝入特定輸入集的的預期性能創(chuàng)建測試，不考慮內(nèi)部處理或底層代碼知識。

至于API，開發(fā)人員和安全團隊常常爭論這兩種方法哪種最適用，各自的支持理由包括：

• 靜態(tài)測試是唯一有效的方法：因為API沒有用戶界面，你必須知道業(yè)務邏輯內(nèi)部在發(fā)生什么。
• 動態(tài)測試才是我們所需要的：因為單元測試適用靜態(tài)模型，且在流水線的早期階段就已經(jīng)完成了。

雖然有點掃興，但以上兩種觀點都不完全正確。事實上，兩種方法都需要確保廣泛覆蓋和處理一系列可能的場景。尤其是隨著近期API攻擊的興起，防御者不能在可擴展性、深度和頻率方面冒險。

圖3：動態(tài)API安全測試與靜態(tài)API安全測試

這種情況下，“灰盒”API安全測試成為了一個有趣的替代方案。因為沒有用戶界面，知道應用的內(nèi)部運行機制(如參數(shù)、返回類型等)有助于高效創(chuàng)建針對業(yè)務邏輯的功能性測試。

理想狀態(tài)下，綜合考慮API安全測試的各個方面可以更好地創(chuàng)建灰盒解決方案，彌補單個方法的不足。此類業(yè)務邏輯方法可智能檢查其他測試類型的結(jié)果，并自動或手動調(diào)整應用改進的測試。

業(yè)務邏輯API安全測試方法

業(yè)界越來越意識到API安全防護應貫穿整個API生命周期，將API置于安全控制的前端和中心。

為此，我們必須找到簡化和彌合企業(yè)API安全測試的方法，將API安全測試標準融入開發(fā)周期并加以實施。這樣一來，在運行時監(jiān)測的幫助下，安全團隊就能夠在一個地方獲得對所有已知漏洞的可見性。并且，左移API安全測試還可以削減成本并加速修復。

此外，如果能夠自動化測試工作流，企業(yè)就內(nèi)置了對重測試的支持：測試、修復、重測、部署的循環(huán)，保持流水線平穩(wěn)運行，避免出現(xiàn)瓶頸。

采用業(yè)務邏輯方法執(zhí)行API安全測試可以提高全生命周期API安全計劃的成熟度，改善企業(yè)安全狀態(tài)。

圖4：生產(chǎn)到設計

然而，這種現(xiàn)代方法需要能自學習的工具，通過攝入運行時數(shù)據(jù)逐漸改進性能，從而深入了解應用的結(jié)構和邏輯。

這將涉及創(chuàng)建能夠隨運行過程不斷學習的自適應測試引擎，積累關于API行為的深入認知，以便智能逆向工程其隱藏的內(nèi)部工作機制。借助運行時數(shù)據(jù)和業(yè)務邏輯信息，企業(yè)能夠享受黑盒和白盒兩種方法帶來的好處，實現(xiàn)可見性增強和自動化控制。

總結(jié)

除了逐漸普及，API也給Web應用帶來了更多漏洞。許多企業(yè)甚至不清楚自身API應用范圍和漏洞情況。黑客可以很容易地通過可用API探測已知和未知漏洞。

然而，企業(yè)常常忽視了API安全測試，像對待Web應用一樣處理API安全測試。大多數(shù)測試方法，比如黑盒測試和白盒測試，并不適合API測試。

自然語言處理和人工智能(AI)的結(jié)合提供了可行“灰盒”選項，能夠自動化、擴展和簡化API安全測試的復雜過程。