如何安全加固API，遠(yuǎn)離漏洞風(fēng)險(xiǎn),？
作為一種中介式接口的應(yīng)用程序編程接口(API),，是一組允許軟件組件彼此交互的協(xié)議。他通?？梢詫⒒A(chǔ)架構(gòu)與運(yùn)行在其上面的應(yīng)用程序分離開來(lái),，并抽象出系統(tǒng)之間的不同功能。同時(shí),，API也能夠讓軟件團(tuán)隊(duì)通過重用代碼的方式,，來(lái)簡(jiǎn)化開發(fā)。
隨著API在現(xiàn)代業(yè)務(wù)中的優(yōu)勢(shì)和用例的不斷增加,，由其固有的弱點(diǎn)所帶來(lái)了各種安全風(fēng)險(xiǎn)也逐漸引起了開發(fā)界的重視,。下面，我將和您深入探討與API漏洞相關(guān)的各種風(fēng)險(xiǎn),，同時(shí)通過介紹各種常見的API安全實(shí)踐,，以構(gòu)建出API安全機(jī)制,。
一、什么是API安全性?
作為一組服務(wù),，API實(shí)現(xiàn)了一個(gè)程序與另一個(gè)外部,、或內(nèi)部程序之間的通信。在談?wù)揂PI安全性時(shí),，我們通常指的是保護(hù)應(yīng)用程序的后端服務(wù),，其中包括數(shù)據(jù)庫(kù)、用戶管理系統(tǒng),、以及與數(shù)據(jù)存儲(chǔ)交互的其他組件,。因此，API安全性常常包含了采用多種工具和實(shí)踐,，來(lái)保護(hù)技術(shù)棧的完整性,，進(jìn)而防止惡意攻擊者訪問到敏感的信息，或執(zhí)行各種違規(guī)操作,。
不幸的是,，雖然API是現(xiàn)代應(yīng)用程序的關(guān)鍵部分，但它們也是攻擊者訪問敏感信息的常見目標(biāo)入口,。隨著API越來(lái)越成為攻擊的眾矢之的,，我們有必要在構(gòu)建API時(shí)，了解第三方應(yīng)用程序是如何通過接口傳輸敏感數(shù)據(jù)的,，并在此基礎(chǔ)上,，通過部署API的安全措施，來(lái)協(xié)助安全團(tuán)隊(duì)評(píng)估風(fēng)險(xiǎn),，并提高服務(wù)的整體安全態(tài)勢(shì),。
二、API漏洞風(fēng)險(xiǎn)
由于API往往是可以被公開訪問的,，因此它們自然也成為了竊取應(yīng)用程序邏輯,、用戶憑據(jù)、信用卡號(hào)等敏感信息的常見途徑,。通常,，攻擊者會(huì)利用API端點(diǎn)中的漏洞，以跨站點(diǎn)腳本和代碼注入等方式,，獲得針對(duì)目標(biāo)系統(tǒng)的未經(jīng)授權(quán)的訪問,、以及其他網(wǎng)絡(luò)形式的攻擊。
目前,，業(yè)界比較公認(rèn)的在線Web應(yīng)用程序安全項(xiàng)目(Open Web Application Security Project,，OWASP)，針對(duì)常見的Web API十大漏洞，發(fā)布了基于各類風(fēng)險(xiǎn)的說明與建議,。在此,，我將和您重點(diǎn)討論如下方面：
失效的用戶身份驗(yàn)證(Broken User Authentication)：由于API需要依賴那些被嵌入到調(diào)用中的會(huì)話令牌，令牌已對(duì)客戶端進(jìn)行身份驗(yàn)證,，因此如果未能在API中實(shí)施多因素身份驗(yàn)證和基于憑據(jù)的登錄,，而僅靠基本的密碼驗(yàn)證的話,，這樣的驗(yàn)證機(jī)制顯然是不足的,。攻擊者可以輕松地通過冒充合法用戶的身份，來(lái)迫使API錯(cuò)誤地允許他們?cè)L問到令牌,。而且,，對(duì)于那些長(zhǎng)期存在的令牌而言，還會(huì)導(dǎo)致攻擊者能夠長(zhǎng)期駐留并損害系統(tǒng),。
失效的對(duì)象級(jí)授權(quán)(Broken Object Level Authorization)：在API中,，對(duì)象級(jí)授權(quán)是一種代碼級(jí)的控制機(jī)制，可用于驗(yàn)證對(duì)象的訪問,。而對(duì)于那些存在著對(duì)象級(jí)授權(quán)漏洞的API而言,，外部用戶可以將自己的資源ID，替換為其他用戶的資源ID,。據(jù)此,，攻擊者能夠訪問到指定的用戶資源，進(jìn)而未經(jīng)授權(quán)地訪問到敏感數(shù)據(jù),。
資源缺乏和速率受限(Lack of Resource and Rate Limiting)：當(dāng)API不限制來(lái)自特定客戶端的請(qǐng)求數(shù)量和頻率時(shí),，它們可能會(huì)被迫進(jìn)行每秒大量的調(diào)用。同時(shí),，API客戶端也可以一次性請(qǐng)求訪問多個(gè)資源與記錄,，從而使得應(yīng)用服務(wù)器為了立即給多個(gè)請(qǐng)求提供服務(wù)，而出現(xiàn)過載,。這種由于客戶端的單次過多請(qǐng)求,，而阻礙服務(wù)器處理正常請(qǐng)求的能力，便是常見的拒絕服務(wù)(DoS)攻擊,。此外,，缺乏速率的限制還會(huì)引發(fā)攻擊者，對(duì)于身份驗(yàn)證端點(diǎn)開展暴力破解式的攻擊,。
批量分配(Mass Assignment)：批量分配的漏洞發(fā)生在自動(dòng)將用戶的輸入傳遞給對(duì)象,、或程序變量的API時(shí)。雖然此項(xiàng)功能簡(jiǎn)化了代碼的開發(fā),，但一些用戶可以通過初始化和覆蓋服務(wù)器端的變量,，從而危及到應(yīng)用程序的安全。也就是說，攻擊者主要會(huì)通過在偽造請(qǐng)求時(shí),，猜測(cè)和提供額外的對(duì)象屬性,，來(lái)達(dá)到該目的。此外,，他們還可以通過閱讀應(yīng)用程序的相關(guān)文檔,、或識(shí)別出允許其修改服務(wù)器端對(duì)象的弱API端點(diǎn)。
安全錯(cuò)誤配置(Security Misconfigurations)：各種安全錯(cuò)誤配置都會(huì)對(duì)API構(gòu)成不同的威脅,，其中包括：
(1)詳細(xì)的錯(cuò)誤消息(Verbose error messages)：一些API會(huì)發(fā)送包含著棧跟蹤和描述性系統(tǒng)信息的錯(cuò)誤消息,，讓接收者能夠了解到應(yīng)用程序是在后臺(tái)如何工作的。
(2)錯(cuò)誤配置的HTTP標(biāo)頭(Misconfigured HTTP Headers)：標(biāo)頭會(huì)暴露出安全漏洞,，攻擊者可以利用此類漏洞,，去竊取數(shù)據(jù)，并執(zhí)行更深層次的復(fù)雜攻擊,。
(3)非必要的HTTP方法和服務(wù)(Unnecessary HTTP methods and services)：如果管理員未能關(guān)閉不必要的服務(wù),，那么惡意攻擊者便可以使用不同的HTTP方法，去修改已發(fā)布的內(nèi)容與資源,。
(4)不安全的默認(rèn)配置(Insecure default configurations)：API往往會(huì)與第三方依賴項(xiàng)相關(guān)聯(lián),。不過，在默認(rèn)情況下,，此類關(guān)聯(lián)是不安全的,，需要我們通過增強(qiáng)安全態(tài)勢(shì)，來(lái)應(yīng)對(duì)由此擴(kuò)大的攻擊面,。
三,、API安全性的優(yōu)秀實(shí)踐
下面給出各項(xiàng)有助于緩解API攻擊的優(yōu)秀實(shí)踐：
1.使用節(jié)流和速率限制
您可以設(shè)置一個(gè)臨時(shí)狀態(tài)，以評(píng)估每個(gè)API請(qǐng)求,，并通過使用反垃圾郵件措施,、以及防止濫用等措施，來(lái)抵御拒絕服務(wù)攻擊,。在實(shí)施限流的過程中,，您可以重點(diǎn)考慮的因素包括：每個(gè)用戶應(yīng)該允許占用多少數(shù)據(jù)、以及何時(shí)應(yīng)該實(shí)施限制,。
此外,，在某些API中，開發(fā)人員可以設(shè)置“軟”速率限制,，允許客戶端在較短的時(shí)間內(nèi)臨時(shí)超出請(qǐng)求限制,。由于可以處理同步和異步請(qǐng)求，因此設(shè)置超時(shí)成為了最直接的避免DoS和蠻力攻擊,、以及管理REST API安全性的實(shí)踐之一,。例如：各種編程語(yǔ)言都可以通過隊(duì)列庫(kù)目錄來(lái)管理請(qǐng)求隊(duì)列,。其中，請(qǐng)求隊(duì)列庫(kù)能夠支持已創(chuàng)建的可接受最大請(qǐng)求數(shù)的API,，并且將其余的請(qǐng)求放入等待隊(duì)列中,。
2.掃描API漏洞
為了保持API服務(wù)的持續(xù)安全性，啟用自動(dòng)化掃描,、漏洞識(shí)別,、以及在軟件生命周期的各階段及時(shí)彌補(bǔ)各種漏洞是至關(guān)重要的。自動(dòng)化的掃描工具通過將應(yīng)用程序的配置與已知漏洞數(shù)據(jù)庫(kù)進(jìn)行比較,，實(shí)現(xiàn)了安全漏洞的自動(dòng)檢測(cè),。
3.對(duì)REST API實(shí)施HTTPS/TLS
在實(shí)踐過程中，我們需要針對(duì)每個(gè)API實(shí)現(xiàn)完整性,、機(jī)密性和真實(shí)性,。而作為一種安全協(xié)議,，HTTPS和傳輸層安全(Transport Layer Security,，TLS)可被用于在Web瀏覽器和服務(wù)器之間傳輸經(jīng)過加密的數(shù)據(jù)，并在傳輸中保護(hù)身份驗(yàn)證憑據(jù),。安全團(tuán)隊(duì)?wèi)?yīng)當(dāng)考慮使用雙向驗(yàn)證的客戶端證書方式,，為敏感數(shù)據(jù)和服務(wù)提供額外的保護(hù)。
此外,，在構(gòu)建安全的REST API時(shí),，開發(fā)人員不但應(yīng)當(dāng)避免因?yàn)橹苯訉TTP重定向到HTTPS處，而可能破壞API客戶端的安全性;而且應(yīng)當(dāng)采取適當(dāng)?shù)拇胧?，?lái)轉(zhuǎn)移各種跨域資源共享(Cross-Origin Resource Sharing,，CORS)和JSONP請(qǐng)求，畢竟兩者往往具有跨域調(diào)用的各種基本漏洞,。
4.限制HTTP方法
REST API允許Web應(yīng)用執(zhí)行各種類型的HTTP(動(dòng)詞)操作,。不過，由于HTTP上的數(shù)據(jù)是未經(jīng)加密的,，一旦我們使用此類HTTP操作,，則可能會(huì)被某些攻擊向量攔截和利用到。作為一種優(yōu)秀實(shí)踐,，我們應(yīng)該禁止本質(zhì)上已被證明極其不安全的HTTP方法(如：GET,、PUT、DELETE,、以及POST等),。如果無(wú)法完全禁止此類使用的話，安全團(tuán)隊(duì)也應(yīng)當(dāng)采用相應(yīng)的策略,，以嚴(yán)苛的允許列表形式,，來(lái)審查此類方法的使用,，進(jìn)而拒絕所有與列表不匹配的請(qǐng)求。
當(dāng)然,，我也推薦您使用RESTful API身份驗(yàn)證的各項(xiàng)優(yōu)秀實(shí)踐,，來(lái)確保請(qǐng)求的客戶端只能在操作、記錄和資源集合上,，使用指定的HTTP方法,。
5.實(shí)施充分的輸入驗(yàn)證
原則上，我們不應(yīng)當(dāng)盲目地信任API客戶端提供的各種數(shù)據(jù),，畢竟身份驗(yàn)證服務(wù)器最終可能會(huì)執(zhí)行那些來(lái)自未經(jīng)授權(quán)的用戶或應(yīng)用服務(wù)的惡意腳本,。雖然客戶端的驗(yàn)證已經(jīng)能夠給出交互式的錯(cuò)誤指示、以及可接受的用戶輸入建議,，但是,，安全團(tuán)隊(duì)仍然需要在服務(wù)器端實(shí)施輸入驗(yàn)證機(jī)制，以防止有害數(shù)據(jù)的輸入,，并避免不同類型的XSS和SQL注入攻擊,。
6.使用API網(wǎng)關(guān)
API網(wǎng)關(guān)能夠有效地將客戶端接口與后端的API集合相分離，提供集中式的資源,，以實(shí)現(xiàn)API服務(wù)的一致性,、可用性和可擴(kuò)展性。同時(shí),，網(wǎng)關(guān)也能夠充當(dāng)反向代理,，協(xié)調(diào)所有API調(diào)用所需的資源，并在身份驗(yàn)證后,，返回適當(dāng)?shù)慕Y(jié)果,。在實(shí)踐中，我們可以通過API管理平臺(tái),，來(lái)處理各種遙測(cè)(Telemetry),、速率限制、以及用戶認(rèn)證等標(biāo)準(zhǔn)化功能,，以維護(hù)內(nèi)部服務(wù)之間的安全性,。
