API安全的盲點：GraphQL
如今，在API現代化的大趨勢下，越來越多的企業從REST架構切換到開源數據查詢和操作語言GraphQL。這種轉變帶來很多好處：GraphQL更靈活、可擴展，更易于開發人員使用，但這同時也給攻擊者打開了一扇窗戶。企業的開發團隊需要避免重蹈Kubernetes安全的覆轍——匆忙切換到時髦的，對開發人員友好的技術，同時留下巨大的安全隱患和代價高昂的“安全債務”。
GraphQL的兩大漏洞風險
根據MITRE CVE數據庫和HackerOne Hacktivity的最新漏洞數據，攻擊者正在積極滲透GraphQL及其開發人員，在GraphQL服務器、客戶端和其他組件中尋找可用的漏洞利用。企業DevOps和DevSecOps團隊需要對此給與足夠的重視。
MITRE CVE數據庫跟蹤的45個GraphQL漏洞（2019年首次發現）數據顯示，當前GraphQL的安全漏洞主要是授權繞過漏洞（占總數的54.8%）和拒絕服務漏洞（16.7%）。
在所有跟蹤的GraphQL漏洞中：
- 9.5%的漏洞與信息泄露有關
- 7.1%與代碼執行有關
- 7.1%與跨站點請求偽造有關
- 4.8%與注入有關
Hacktivity門戶網站收集的研究人員報告的漏洞數據與MITRE CVE的數據基本一致：授權繞過風險更加突出，87%的已知GraphQL漏洞屬于這一類。拒絕服務漏洞以7%的份額位居第二。條件競爭漏洞和會話管理漏洞各占2.8%。
值得注意的是，Hacktivity作為漏洞賞金門戶，其數據可能會出現一定的偏差，因為授權漏洞對敏感數據的威脅更大，為研究人員帶來更豐厚的賞金。此外，測試DoS漏洞也在很大程度上被禁止，因為測試可能會造成真正的傷害，這也會導致對此類漏洞的報告數量偏少。
針對GraphQL面臨的主要漏洞威脅，GraphQL開發人員需要實施有效的基于模式的訪問控制來限制功能訪問，防范授權繞過攻擊。此外還應設置動態速率限制以遏制拒絕服務攻擊。開發團隊需要通過精細分析對上述安全措施提供支持，并維護活動日志以獲得更好的可見性，這將進一步確保團隊能夠在攻擊者造成傷害之前阻止未經授權的行為。
GraphQL API攻擊偵察
為何不可見？
如今，攻擊者擁有復雜的自動化方法來偵察GraphQL應用的安全漏洞。攻擊者的工具箱中已經有很多現成的工具可以對目標GraphQL API展開被動研究、發起評估應用程序行為的無害查詢，以及通過簡單的推理來定位GraphQL API。
此類攻擊前的偵察活動很難被檢測到，因為標準API安全網關不會對傳入的GraphQL請求查詢進行上下文分析。這是API開發運營團隊的一個盲點，會顯著增加合規失敗的風險。
例如，如果開發人員不小心將訪問憑據留在公共存儲庫中可用的代碼中，則有可能被攻擊者獲取。而發送到應用程序的GraphQL查詢（即使無效）也會告訴攻擊者GraphQL是否正在使用中。攻擊者還可以自動查詢可能部署GraphQL的多個端點（例如/graphql、/query、/api、/playground、/console和/graphiql），而服務器響應則會向攻擊者確認目標的準確位置。
但是，如果采用了正確的GraphQL安全策略，攻擊者所依賴的自動查詢將被標記為異常行為。通過標記針對多個端點（其中許多不存在）的無效查詢和批量流量的保護措施，開發人員可以在漏洞利用升級之前檢測并阻止（或緩解）攻擊。
此外，限制應用程序的對象請求和操作數量/速率也是保護GraphQL API端點的有效措施（應在對象級別而不是調用級別完成）。通過部署正確的安全措施，即便攻擊者找到GraphQL目標，API團隊也能有效阻止攻擊。
GraphQL安全優先級亟待提升
對于使用GraphQL的企業來說，了解GraphQL API和應用程序面臨的獨特威脅，并及早準備和部署相應的安全措施至關重要。
企業還應該意識到，只有在部署GraphQL的早期階段就提高其安全優先級才能起到事半功倍的效果，只有通過正確的安全策略和流程主動監控流量的異常活動，同時保護訪問控制（和其他已知的攻擊途徑），開發人員才可以安全地，大規模地發揮GraphQL的優勢。
