【问题标题】：How do I secure rest api?如何保护休息 api？
【发布时间】：2019-11-04 05:48:51
【问题描述】：

我正在使用 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 连接的简单安全方法。

【问题讨论】：

你可以使用 JWT。 toptal.com/angular/angular-6-jwt-authentication
@DhavalChaudhary 这是登录/注册系统。我不想要这个。

标签： node.js rest express security oauth

【解决方案1】：

保护您的 API 的最佳方式是开始使用 Nginx 等反向代理。 Javascript 框架在安全性方面基本相同。它们都有一个基本的路由器处理程序、调度程序（基于本机 Node.js HTTP 库）和一些基本的辅助方法，他们给它起了一个好听的名字，就是这样。我检查了几乎所有主要框架的源代码。现在，Nginx 的一些基本配置参数是：client_body_buffer_sizeproxy_buffers 等。你所有的指令也应该正则表达式输入数据。一般来说，任何可以“过滤”恶意代码的东西都是有用的。 Cloudflare 可以以某种方式帮助和其他一些可以保护您的应用程序的公司，但它们很昂贵。另一个很好的例子是使用 Docker 将您的应用程序容器化。
如果您在 Node.js 中有一段基本代码，那么破解它的最简单方法是通过您的应用程序的逻辑。您应该使用反 XSS 模块，例如 xss 或 express-sanitizer。如果您使用的是 SQL 数据库，则应始终对查询值进行转义。

【讨论】：

【解决方案2】：

假设

我正在使用 Angular 开发一个应用程序。

我假设您正在开发一个 Web 应用程序，而不是使用 NativeScript 之类的移动应用程序。

我想从 rest api 中获取要列出的数据。但是，我不希望用户访问资源

我在这里假设您希望只有网络应用可以访问 API，而不是其他任何人。

让我们解决您的问题

我可以使用哪种语言、库或框架来保护它？

问题不在于编程语言或框架，而在于您想要实现的目标，老实说，我不得不告诉您一个残酷的事实……在网络环境中，不可能将 API 锁定为Web 应用程序，这仅仅是因为 Web 的构建方式，你知道你按下 F12 并且你可以看到在浏览器中运行的所有代码，因此你放在那里的任何秘密来识别你的 Web 应用程序在它所做的每个请求中API 将可供任何想要复制您的网络应用程序的人获取和重用，并且您的 API 将无法区分谁正在执行请求和 WHAT 正在执行请求。

用户在没有会员资格的情况下使用该应用。

与许多开发人员的想法相反，经过身份验证的用户不会将 Web 应用或移动应用锁定到 API 服务器，因为用户只是等式的一部分，他代表 WHO 正在访问 API，但您仍需要说明什么正在访问它。

等一下，等一下……你一直在说WHO和WHAT，你愿意详细解释一下吗？

很高兴你问；）

访问 API 服务器的对象和对象的区别

因此，让我们澄清一个在开发人员中关于WHO 和WHAT 访问 API 服务器的常见误解。

为了更好地理解 WHO 和 WHAT 访问 API 服务器之间的区别，让我们使用这张图片：

因此，将移动应用替换为网络应用，并继续围绕这张图片进行类比。

Intended Communication Channel 表示 Web 应用程序正按您的预期被合法用户使用，没有任何恶意，从浏览器与 API 服务器通信，不使用 Postman 或使用任何其他工具来执行中间人(MitM) 攻击。

实际通道可能代表几种不同的场景，例如具有恶意意图的合法用户可能正在使用 Curl 或 Postman 之类的工具来执行请求，黑客使用 MitM 攻击工具（例如 MitmProxy）来了解通信是如何进行的Web 应用程序和 API 服务器之间正在完成，以便能够重放请求，甚至自动攻击 API 服务器。许多其他情况也是可能的，但我们不会在这里一一列举。

我希望现在您可能已经知道为什么 WHO 和 WHAT 不一样，但如果不一样，一会儿就会清楚。

WHO 是网络应用的用户，我们可以通过多种方式进行身份验证、授权和识别，例如使用 OpenID Connect 或 OAUTH2 流。

OAUTH

通常，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。 OAuth 专为与超文本传输协议 (HTTP) 一起使用而设计，本质上允许授权服务器在资源所有者的批准下将访问令牌颁发给第三方客户端。然后第三方使用访问令牌访问资源服务器托管的受保护资源。

OpenID Connect

OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。

虽然用户身份验证可能会让 API 服务器知道谁正在使用 API，但它不能保证请求源自您所期望的 WHAT，浏览器是您的网络应用程序应该由真实用户运行。

现在我们需要一种方法来识别什么正在调用 API 服务器，而这里的事情变得比大多数开发人员想象的要棘手。 WHAT 是向 API 服务器发出请求的事物。它真的是 Web 应用程序的真正实例，还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动探索 API 服务器？

令您惊讶的是，您最终可能会发现它可能是手动操作请求的合法用户之一，也可能是试图游戏化并利用网络应用提供的服务的自动脚本。

好吧，为了识别 WHAT，开发人员倾向于使用通常在 Web 应用程序标头中发送的 API 密钥。一些开发人员加倍努力并在运行时在 Web 应用程序中计算密钥，在混淆的 javascript 中，因此它成为运行时机密，可以通过反混淆工具进行逆向工程，并通过检查 Web 应用程序和 API 之间的流量使用 F12 或 MitM 工具的服务器。

以上文章摘自我写的一篇文章，题为为什么您的移动应用程序需要 API 密钥？。虽然在移动应用程序的上下文中，整体想法在 Web 应用程序的上下文中仍然有效。你希望你能完整阅读这篇文章here，这是关于 API 密钥的系列文章中的第一篇。

现在您可能会问...

保护 API 服务器

要从网络应用程序甚至移动设备开始，应仅与您控制的 API 服务器进行通信，并且对第三方 API 服务的任何访问都必须由您控制的同一 API 服务器完成。通过这种方式，您可以将攻击面限制在一个地方，在那里您将使用尽可能多的防御层来保护您所保护的东西。

因此，任何在客户端运行并需要一些秘密才能访问 API 的东西都可能以不同的方式被滥用，您可以在 this series 有关移动 API 安全技术的文章中了解更多信息。虽然本文是在为移动应用提供服务的 API 的上下文中，但其中一些内容适用于为 Web 应用提供服务的 API，并且将帮助您了解 API 在与 区分开来时的脆弱程度谁 和 WHAT 正在访问它。所以本系列文章将教你如何使用 API Keys、User Access Tokens、HMAC 和 TLS Pinning 来保护 API 以及如何绕过它们。

现在您已经更加了解保护 API 服务器的痛苦，让我们看看可以采取哪些措施来减轻 Web 应用程序环境中面临的安全风险。对于服务于 Web 应用程序的 API，您可以使用多个密集层，从 reCaptcha V3 开始，然后是 Web Application Firewall(WAF)，最后如果您负担得起，则可以使用 User Behavior Analytics(UBA) 解决方案。

谷歌reCAPTCHA V3：

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。 reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它在让您的有效用户轻松通过的同时做到这一点。

...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦。它会根据与您的网站的互动返回一个分数，并让您更灵活地采取适当的行动。

WAF - Web Application Firewall:

Web 应用程序防火墙（或 WAF）过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于，WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量，它可以防止源自 Web 应用程序安全漏洞的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。

UBA - User Behavior Analytics:

Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、有针对性的攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。 UBA 不是跟踪设备或安全事件，而是跟踪系统的用户。 Apache Hadoop 等大数据平台通过分析 PB 级数据以检测内部威胁和高级持续性威胁，正在增加 UBA 功能。

所有这些解决方案都基于否定识别模型工作，换句话说，它们尽力通过识别什么是坏的而不是什么来区分好与坏，因此它们很容易出现误报，尽管先进的其中一些人使用的技术，例如机器学习和人工智能。

因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户。这也意味着这些解决方案需要持续监控，以验证误报不会阻止您的合法用户，同时它们正确地阻止了未经授权的用户。

结论

我想要一种可以与 Angular 连接的简单安全方法。

正如您可能已经意识到的那样，您无法实现一种简单的安全方法来使用 API 服务器锁定您的 Angular 应用程序。就是这样，简单的安全方法并不能解决问题，相反，您需要采取多种解决方案，这将减少攻击面，但不会消除攻击面。

因此，最后，必须根据您要保护的内容的价值以及该类型数据的法律要求（例如欧洲的 GDPR 法规）来选择用于保护您的 API 服务器的解决方案.

【讨论】：