如何保护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服务器的解决方案。