如何保護Rest API？

Question

我正在使用Angular開發一個應用程序。我想從rest api中列出數據。 但是，我不希望用戶訪問該資源。 我可以使用哪種語言，庫或框架進行保護？ 用戶正在使用沒有會員資格的應用程序。

我嘗試了jwt，但沒有得到想要的結果。 也許我做不到。

這是express.js

const app = require('express')()
const express = require('express')
const fs = require('fs')
const cors = require('cors')
const bodyParser = require('body-parser');
app.use(cors())
app.use(bodyParser.json())

app.get('/', (req, res) => {
  res.json({message: 'Rest API Work'})
})

app.get('/list', (req, res) => {
    fs.readFile('data1.json','utf-8',(err,data)=>{
    res.setHeader("Content-Type", "application/json; charset=utf-8")
        data = JSON.parse(data)
        console.log(data)
        res.end(JSON.stringify(data,null,4))
    })
})



app.listen(3002, function(){
  console.log('Server OK')  
})

我想要一種可以與Angular連接的簡單安全方法。

Answer 1

保護API的最佳方法是開始使用Nginx之類的反向代理。 就安全性而言，JavaScript框架基本上都是相同的。 它們都有一個基本的路由器處理程序，調度程序（基於本機Node.js HTTP庫）和一些基本的輔助方法，它們為它提供了一個不錯的上乘名稱。 我已經檢查了幾乎所有主要框架的源代碼。 現在，Nginx的一些基本配置參數是： client_body_buffer_size proxy_buffers等。您所有的指令也應該對輸入數據進行正則表達式。 通常，任何可以“過濾”惡意代碼的東西都是有用的。 Cloudflare可以以某種方式提供幫助，而其他一些公司則可以保護您的應用程序安全，但價格昂貴。 另一個很好的例子是使用Docker容器化您的應用程序。
如果您在Node.js中有一段基本的代碼，最簡單的破解方法是通過應用程序的邏輯。 您應該使用xss或express-sanitizer類的反XSS模塊。 如果您使用的是SQL數據庫，則應始終轉義查詢值。

Answer 2

的假設

我正在使用Angular開發一個應用程序。

我假設您正在使用Web應用程序，而不是使用NativeScript之類的移動應用程序。

我想從Rest API獲取要列出的數據。 但是，我不希望用戶訪問資源

我在這里假設您只希望Web應用程序有權訪問API，而其他任何人都不能。

解決您的問題

我可以使用哪種語言，庫或框架進行保護？

問題不是編程語言或框架，而是您要實現的目標，老實說，我必須告訴您一個殘酷的事實……在網絡環境中，無法將API鎖定到網絡應用程序，這僅僅是因為網絡的構建方式，您知道您按了F12鍵，並且可以看到瀏覽器中正在運行的所有代碼，因此，您在其中存儲的用於在對API進行的每個請求中標識您的Web應用的任何秘密，將爭奪和誰想要復制您的Web應用程序重復使用，和你的API將無法區分世衛組織正在開展從什么是做請求的請求。

用戶正在使用沒有會員資格的應用程序。

與許多開發人員可能認為的相反，經過身份驗證的用戶不會將Web應用程序或移動應用程序鎖定到API服務器，因為該用戶只是等式的一部分，他表示誰正在使用WHO ，但您仍然需要解決什么是訪問它。

等一下，等一下...您一直在指WHO和WHAT ，您是否願意詳細解釋？

很高興你問;）

WHO與訪問API服務器之間的區別

因此，讓我們清除一下開發人員之間關於WHO和WHAT正在訪問API服務器的常見誤解。

為了更好地了解WHO和WHAT訪問API服務器之間的區別，讓我們使用以下圖片：

因此，用Web應用程序代替移動應用程序，並繼續遵循我對這張圖片的類比。

預期的通信渠道表示合法用戶在沒有任何惡意意圖的情況下按預期使用的Web應用程序，通過瀏覽器與API服務器進行通信，而不使用Postman或使用任何其他工具來執行中間操作（MitM）攻擊。

實際渠道可能代表幾種不同的情況，例如具有惡意意圖的合法用戶可能正在使用Curl或Postman等工具來執行請求，黑客使用MitM攻擊工具（例如MitmProxy）來了解網絡之間的通信方式應用程序和API服務器已經完成，以便能夠重播請求，甚至自動對API服務器進行攻擊。 其他許多情況也是可能的，但在此我們將不逐一列舉。

我希望到現在為止您可能已經有了線索，為什么WHO和WHAT並不相同，但是如果不是這樣，那一會兒就會明白。

WHO是Web應用程序的用戶，我們可以通過多種方式來進行身份驗證，授權和標識，例如使用OpenID Connect或OAUTH2流。

OAUTH

通常，OAuth代表資源所有者向客戶端提供對服務器資源的“安全委派訪問”。 它為資源所有者指定了一個在不共享憑據的情況下授權第三方訪問其服務器資源的過程。 OAuth專為與超文本傳輸​​協議（HTTP）配合使用而設計，實質上允許在資源所有者的批准下，授權服務器將訪問令牌發布給第三方客戶端。 然后，第三方使用訪問令牌訪問資源服務器托管的受保護資源。

OpenID連接

OpenID Connect 1.0是基於OAuth 2.0協議的簡單身份層。 它允許客戶端基於授權服務器執行的身份驗證來驗證最終用戶的身份，並以可互操作且類似於REST的方式獲取有關最終​​用戶的基本配置文件信息。

雖然用戶認證可以讓API服務器知道誰在使用API，它不能保證請求源自你所期望的 ，瀏覽器是你的web應用程序應該運行，與真正的用戶。

現在，我們需要一種方法來確定哪些是調用API服務器，這里的事情變得比大多數開發人員可能會覺得更靠譜。 向API服務器發出請求的是什么 。 它是Web應用程序的真正實例，還是使用諸如Postman之類的工具通過API服務器手動訪問的機器人，自動腳本或攻擊者？

令您驚訝的是，您可能最終發現它可能是手動處理請求的合法用戶之一，或者是試圖游戲化並利用Web應用程序提供的服務的自動腳本。

好了，為了確定WHAT ，開發人員傾向於求助於通常在Web應用程序標頭中發送的API密鑰。 一些開發人員會加倍努力，並在運行時在混淆的javascript內的web應用程序中計算密鑰，因此它成為運行時的秘密，可以通過除臭工具以及檢查Web應用程序與API之間的流量進行逆向工程F12或MitM工具的服務器。

以上文章摘自我寫的一篇文章，標題為《 為什么您的移動應用程序需要API密鑰？ 。 在移動應用程序的上下文中，總體思想在Web應用程序的上下文中仍然有效。 您希望可以在此處閱讀全文，這是有關API密鑰的系列文章中的第一篇。

現在您可能會問...如果我不能僅將API服務器鎖定到我的Web應用程序，該如何保護它？

防御API服務器

要從Web應用程序甚至移動設備開始，只能與您控制下的API服務器進行通信，並且對第三方API服務的任何訪問都必須由您控制的同一API服務器來完成。 通過這種方式，您可以將攻擊面限制在一個地方，在那里您將采用防御所需要保護的多層防御。

因此，在客戶端運行的任何需要秘密訪問API的東西都可能以不同的方式被濫用，您可以在本系列有關移動API安全技術的文章中了解更多信息。 雖然本文是在為移動應用程序提供服務的API的上下文中，但其中一些內容適用於為網絡應用程序提供服務的API，並且將幫助您了解API與WHO和WHAT區別時的脆弱性正在訪問它。 因此，本系列文章將教您如何使用API​​密鑰，用戶訪問令牌，HMAC和TLS固定來保護API以及如何繞過它們。

現在，您已經更多地了解了捍衛API服務器的痛苦，讓我們看看可以采取什么措施來減輕Web應用程序環境中面臨的安全風險。 對於服務於Web應用程序的API，您可以采用多個密集層，從reCaptcha V3開始，然后是Web應用程序防火牆 （WAF），最后是您可以負擔得起的用戶行為分析 （UBA）解決方案。

Google reCAPTCHA V3 ：

reCAPTCHA是一項免費服務，可保護您的網站免受垃圾郵件和濫用的侵害。 reCAPTCHA使用高級風險分析引擎和適應性挑戰，以防止自動化軟件參與您網站上的濫用行為。 這樣做是為了讓您的有效用戶輕松通過。

...可幫助您檢測網站上的濫用流量，而不會引起用戶的摩擦。 它會根據與您網站的互動情況返回得分，並為您提供更大的靈活性以采取適當的措施。

WAF-Web應用程序防火牆 ：

Web應用程序防火牆（或WAF）篩選，監視和阻止與Web應用程序之間的HTTP通信。 WAF與常規防火牆的區別在於，WAF能夠過濾特定Web應用程序的內容，而常規防火牆充當服務器之間的安全門。 通過檢查HTTP流量，它可以防止Web應用程序安全漏洞（例如SQL注入，跨站點腳本（XSS），文件包含和安全性錯誤配置）引起的攻擊。

UBA-用戶行為分析 ：

Gartner定義的用戶行為分析（UBA）是一個有關檢測內部威脅，針對性攻擊和財務欺詐的網絡安全流程。 UBA解決方案着眼於人類行為模式，然后應用算法和統計分析從這些模式中檢測出有意義的異常，即表明潛在威脅的異常。 UBA不會跟蹤設備或安全事件，而是跟蹤系統的用戶。 像Apache Hadoop這樣的大數據平台通過允許它們分析PB級的數據來檢測內部威脅和高級持久威脅，正在增強UBA功能。

所有這些解決方案都基於否定性識別模型，換句話說，他們通過識別出什么是壞的而不是什么好，來盡最大的努力將好與壞區別開來，因此盡管使用了先進的技術，但它們還是容易產生誤報。其中一些，例如機器學習和人工智能。

因此，您可能經常會發現自己不必放松放松如何阻止對API服務器的訪問，以免影響良好的用戶。 這也意味着這些解決方案需要不斷監控，以確認誤報不會阻止您的合法用戶，同時又可以正確阻止未經授權的用戶。

結論

我想要一種可以與Angular連接的簡單安全方法。

就像已經意識到的那樣，您將無法實現一種簡單的安全方法來使用API​​服務器鎖定Angular應用。 就是這樣，簡單的安全方法無法解決問題，而是需要訴諸幾種解決方案，這將減少攻擊面，但不會消除攻擊面。

因此，最后，必須根據要保護的內容的價值以及此類數據的法律要求（例如歐洲的GDPR法規）來選擇用於保護API服務器的解決方案。