近年來，互聯(lián)網(wǎng)上安全漏洞顯著增多。互聯(lián)網(wǎng)安全的話題也被技術(shù)博客和論壇討論得越來越頻繁:安全性非常重要，尤其是在REST API的世界中。

根據(jù)Jitterbit公司2018年API集成狀態(tài)報告:

APIs 正在改變商業(yè)

令人印象深刻的是，現(xiàn)在有64%的組織機構(gòu)正在創(chuàng)建用于內(nèi)部或外部用例的APIs。雖然現(xiàn)在有四分之一的受訪者根本沒有創(chuàng)建APIs，但是有40%的受訪者正在使用內(nèi)部和外部用例中的APIs。

API的創(chuàng)建和管理落到了開發(fā)人員的肩上

如今，大多數(shù)利用APIs的組織都依賴開發(fā)人員來編寫和管理這些api。33%的受訪者使用專門的技術(shù)來管理APIs，而90%的受訪者則依賴開發(fā)團隊或外部資源從頭開始編寫APIs。

由于在越來越多的新的云應(yīng)用程序之間編寫集成代碼，組織已經(jīng)不堪重負，因此要求開發(fā)人員為業(yè)務(wù)創(chuàng)建和管理APIs。

REST API安全

在設(shè)計、測試和部署REST API時，安全性問題必須是需要考慮的重要方面。隨著REST API的驚人發(fā)展，安全級別，大部分時間，在API的設(shè)計和開發(fā)中被低估了。敏感數(shù)據(jù)的安全性，無論是組織的還是個人的信息，都是當今困擾開發(fā)人員的一個重要因素。REST api也不例外，它是需要針對安全威脅和破壞進行保護的基本系統(tǒng)的一部分。

根據(jù)2018年P(guān)ostman community report (survey)，越來越多的開發(fā)者開始關(guān)注REST API的安全性:

在這篇文章中，我將介紹當今IT世界中最常見的7種REST API安全威脅，以便引起每個人的注意，并幫助了解能夠反映REST API性能的安全威脅。

REST的安全性問題。

REST通常使用HTTP作為它的底層協(xié)議,這帶來了一系列安全問題：

• 潛在的攻擊者可以完全控制HTTP請求或HTTP響應(yīng)。由于REST api通常用于交換保存在許多服務(wù)器中并可能在許多服務(wù)器中執(zhí)行的信息，因此它可能導(dǎo)致許多不可見的破壞和信息泄漏。
• 攻擊者可以在客戶端(REST API的消費者,受害者的REST API服務(wù)器)或者在服務(wù)器端(攻擊者獲得控制你的REST API服務(wù)器),他創(chuàng)建了一個流氓,惡意程序。受害者,在這種情況下,應(yīng)用程序從遠程REST API服務(wù)消費資源。
• 對于使用REST作為客戶機或服務(wù)器的應(yīng)用程序，另一方通常完全控制資源表示，并可以注入任何有效負載來攻擊資源處理(例如，獲取任意Java代碼或系統(tǒng)命令執(zhí)行)。

在REST架構(gòu)中，端到端處理意味著一系列潛在的脆弱操作：

• 在進行 from/to the HTTP 消息映射 和資源 URL (controller 映射).
• 實例化表示目標資源的對象并調(diào)用所請求的操作時(從控制器調(diào)用服務(wù))。
• 在為目標資源(特定于服務(wù)的功能)生成狀態(tài)表示時。
• 當訪問/修改托管資源狀態(tài)(保存到數(shù)據(jù)庫或存儲中)的后端系統(tǒng)中的數(shù)據(jù)時。

REST框架中的分層轉(zhuǎn)換序列意味著鏈中的一個薄弱環(huán)節(jié)可能使應(yīng)用程序變得脆弱。

7大REST API安全威脅：

1. 注入攻擊

在注入攻擊中，危險的代碼被嵌入到不安全的軟件程序中進行攻擊，尤其是SQL注入和跨站點腳本編寫。實際上，可以通過將不受信任的數(shù)據(jù)作為查詢或命令的一部分傳輸?shù)紸PI中來操縱此公開。輸入隨后由解釋器實現(xiàn)，這可能導(dǎo)致攻擊者獲得未經(jīng)授權(quán)的信息訪問或進行其他破壞。

阻止或拒絕注入攻擊的最有效方法是添加輸入驗證，下面是最關(guān)鍵的指導(dǎo)原則：

• 驗證輸入: 長度/范圍/格式和類型
• 通過使用API參數(shù)中的數(shù)字、布爾值、日期、時間或固定數(shù)據(jù)范圍等強類型來實現(xiàn)隱式輸入?yún)?shù)驗證
• 用正則表達式約束字符串輸入
• 定義適當?shù)恼埱蟠笮∠拗疲⒕芙^HTTP響應(yīng)狀態(tài)為413的請求實體太大而超過該限制的請求

2. DoS 攻擊

在拒絕服務(wù)(DoS)攻擊中，攻擊者在大多數(shù)情況下會推送大量請求服務(wù)器或網(wǎng)絡(luò)的消息，以建立由無效返回地址組成的請求。如果不采取適當?shù)陌踩A(yù)防措施，這種攻擊能夠?qū)ESTful API呈現(xiàn)為拒絕使用的情況。最近，無論您的API是否公開，其他人(包括攻擊者)都可能訪問它。

隨著這些API DoS攻擊變得越來越普遍，隨著組織越來越多地依賴于API來滿足業(yè)務(wù)需求，安全專家應(yīng)該積極地計劃處理此類攻擊。即使禁用了用于應(yīng)用程序身份驗證的API密鑰(或訪問令牌)，也可以通過標準瀏覽器請求輕松地重新獲取密鑰。因此，使當前的訪問令牌無效不是一個長期的解決方案。如果DoS攻擊可以追溯到特定的IP地址，那么將該IP地址列入黑名單也不是一個長期的解決方案，因為攻擊者可以很容易地獲得一個新的IP地址。

這就是為什么需要多種訪問控制方法。對于非敏感信息，使用API鍵可能就足夠了。但是，為了更好地防止DoS攻擊，需要使用HTTPS和更健壯的身份驗證機制，包括OAuth、相互(雙向)TLS(傳輸層安全)身份驗證或SAML(安全斷言標記語言)令牌。

為了防止大量API請求導(dǎo)致DDoS攻擊或API服務(wù)的其他誤用，對每個API在給定時間間隔內(nèi)的請求數(shù)量進行限制(也稱為峰值停止)。當超過速率時，至少暫時阻塞API鍵的訪問，并返回429(太多請求)HTTP錯誤代碼。

如果您開始構(gòu)建新的REST API，請檢查具有許多面向安全特性的web服務(wù)器。

3. 打破身份驗證

這些特定的問題可能使攻擊者繞過或控制web程序使用的身份驗證方法。缺少或不充分的身份驗證可能導(dǎo)致攻擊，從而危及JSON web令牌、API密鑰、密碼等。攻擊的目的通常是控制多個帳戶，更不用說攻擊者獲得與被攻擊用戶相同的特權(quán)了。應(yīng)該只允許經(jīng)過身份驗證的用戶訪問api。

使用OpenId/OAuth令牌、PKI和API密鑰可以很好地滿足API的授權(quán)和身份驗證需求。永遠不要通過未封裝的連接發(fā)送憑證，也不要在Web URL中顯示會話ID。

4. 暴露敏感數(shù)據(jù)

在傳輸過程中或靜止狀態(tài)下由于缺乏加密而導(dǎo)致的敏感數(shù)據(jù)的暴露可能導(dǎo)致攻擊。當應(yīng)用程序無法正確保護敏感數(shù)據(jù)時，就會發(fā)生敏感數(shù)據(jù)公開。這些信息可能不同于私人健康信息、信用卡信息、會話令牌、密碼等，而且更容易受到攻擊。敏感數(shù)據(jù)要求很高的安全性，除了與瀏覽器交換時非常安全的做法外，還包括在靜止或傳輸時進行加密。

為了避免暴露敏感數(shù)據(jù)，必須使用SSL。

今天，您可以使用Let's Encrypt獲得免費證書。SSL和TLS在以幾乎最小的努力消除基本API漏洞方面大有作為。

要獲得關(guān)于實現(xiàn)有多好的優(yōu)秀報告，請針對Qualys SSL服務(wù)器測試運行URL。

5. 打破訪問控制

訪問控制，在某些情況下稱為授權(quán)，是web軟件允許某些人而不是每個人訪問功能和內(nèi)容的方式。缺少或不充分的訪問控制可以使攻擊者獲得對其他用戶帳戶的控制、更改訪問權(quán)限、更改數(shù)據(jù)等。

當開發(fā)人員沒有正確配置操作級可訪問性，從而導(dǎo)致訪問漏洞時，公司應(yīng)用程序訪問往往會受到攻擊。訪問中斷是訪問控制中斷的最著名后果，而訪問控制的利用是攻擊者的主要手段。

訪問控制可以通過使用手動方法來檢測，甚至可以通過某些框架中缺乏訪問控制的自動化來檢測。如果在可靠的服務(wù)器端或服務(wù)器端API中實現(xiàn)訪問控制，則訪問控制通常是有效的，攻擊者將無法更改訪問控制元數(shù)據(jù)。

6. 參數(shù)篡改

攻擊,是基于客戶機和服務(wù)器之間交換操作的參數(shù)來修改應(yīng)用程序數(shù)據(jù),如用戶憑證和權(quán)限,價格和數(shù)量的產(chǎn)品,等。通常,這些信息存儲在cookie中,隱藏的表單字段,或URL查詢字符串,用于增加應(yīng)用程序的功能和控制。

當一個有害的網(wǎng)站、程序、即時消息、博客或電子郵件使用戶的internet瀏覽器在一個授權(quán)站點上執(zhí)行不必要的操作時，就會發(fā)生這種情況。它允許攻擊者使用目標的web瀏覽器使目標系統(tǒng)執(zhí)行某個功能，而被攻擊的用戶可能在未執(zhí)行授權(quán)事務(wù)之前并不知情。

攻擊的成功依賴于完整性和邏輯驗證機制錯誤，其利用可能導(dǎo)致其他后果，包括XSS、SQL注入、文件包含和路徑公開攻擊。

您應(yīng)該仔細驗證接收到的URL參數(shù)，以確保數(shù)據(jù)表示來自用戶的有效請求。無效的請求可以用來直接攻擊API，或者針對API背后的應(yīng)用程序和系統(tǒng)。將驗證器放在應(yīng)用程序上，并嘗試對發(fā)送到REST API的請求使用API簽名。為您的API創(chuàng)建自動安全測試也很好，這樣可以看到?jīng)]有參數(shù)篡改影響您的REST API。

7. 中間人攻擊( Man-In-The-Middle-Attack)

它是指攻擊者在兩個交互系統(tǒng)之間秘密地更改、截取或中繼通信，并截取它們之間傳遞的私有和機密數(shù)據(jù)。MITM攻擊發(fā)生在兩個階段:攔截和解密。

HTTP和缺乏TLS

在API中缺少傳輸層安全(TLS)實際上相當于向黑客發(fā)出公開邀請。傳輸層加密是安全API中最基本的“必備功能”之一。除非使用TLS，否則相當常見的“中間人”攻擊的風險仍然很高。在api中同時使用SSL和TLS，特別是在API公開的情況下。

結(jié)論

在開發(fā)REST API時，您必須從一開始就注意安全性?？紤]使用具有許多內(nèi)置安全特性的現(xiàn)有API框架。我們使用的是SugoiJS API框架，我們還對其代碼庫以及測試和安全指導(dǎo)做出了貢獻。通過這種方式，安全性被統(tǒng)一地內(nèi)置，開發(fā)人員可以專注于應(yīng)用程序邏輯。

在這之后，不要忽略分配資源來測試API的安全性。確保測試本文中提到的所有安全威脅。