保护我的 Node.js 应用程序的 REST API？

Posted 2023-02-27

【中文标题】保护我的 Node.js 应用程序的 REST API？

【英文标题】：Securing my Node.js app's REST API?

【发布时间】：2012-02-25 12:56:53

【问题描述】：

我可以在我的 REST API 上获得一些帮助。我正在编写一个使用 Express、MongoDB 并在客户端具有 Backbone.js 的 Node.js 应用程序。在过去的两天里，我一直在努力解决所有这些问题，但运气不佳。我已经签出：

Securing a REST API Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth) http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ http://tesoriere.com/2011/10/10/node.js-getting-oauth-up-and-working-using-express.js-and-railway.js/

我想让我的后端和前端尽可能分开，所以我认为使用精心设计的 REST API 会很好。我的想法是，如果我有机会开发 iPhone 应用程序（或其他类似的东西），它可以使用 API 来访问数据。

但是，我希望这是安全的。用户登录了我的网络应用程序，我想确保我的 API 是安全的。我了解了 OAuth、OAuth 2.0、OpenID、Hmac、哈希等...我想避免使用外部登录（Facebook/Twitter/等）我希望注册和登录在我的应用程序/服务器上。

...但我仍然在这里感到困惑。也许是深夜，或者我的大脑只是被炒了，但我真的可以在这里做一些步骤。创建安全 API 的步骤是什么？

任何帮助、任何信息、任何示例、步骤或任何东西都会很棒。请帮忙！

【问题讨论】：

你最后做了什么？

【参考方案1】：

按照提高安全性/复杂性的顺序：

基本 HTTP 身份验证

许多 API 库可以让您在其中构建它（例如 Django 中的活塞），或者您可以让您的网络服务器处理它。 nginx 和 Apache 都可以使用服务器指令通过简单的 b64 编码密码来保护站点。这不是世界上最安全的东西，但它至少是一个用户名和密码！

如果您使用的是 Nginx，您可以像这样在主机配置中添加一个部分：

auth_basic "Restricted";
auth_basic_user_file /path/to/htpasswd;

（把它放在你的 location / 块中）

文档：http://wiki.nginx.org/HttpAuthBasicModule

您需要获取 python 脚本来生成该密码并将输出放入文件中：http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt

文件的位置无关紧要，只要 Nginx 可以访问它。

HTTPS

保护从您的服务器到应用程序的连接，这是最基本的，可以防止中间人攻击。

你可以用 Nginx 来做这件事，它的文档非常全面：http://wiki.nginx.org/HttpSslModule

为此提供自签名证书就可以了（而且免费！）。

API 密钥

这些可以是您喜欢的任何格式，但如果您需要，它们可以让您撤销访问权限。如果您正在开发连接的两端，则可能不是您的完美解决方案。当您有第三方使用 API（例如 Github）时，往往会使用它们。

OAuth

OAuth 2.0 是这里的首选。虽然我不知道该规范的基本工作原理，但它是现在大多数身份验证（Twitter、Facebook、Google 等）的事实上的标准，并且有大量的库和文档可以帮助您实现这些。话虽如此，它通常用于通过要求第三方服务进行身份验证来对用户进行身份验证。

鉴于您在两端都进行开发，将您的 API 置于 Basic HTTP Auth 之后并通过 HTTPS 提供服务可能就足够了，特别是如果您不想浪费时间搞乱 OAuth。

【讨论】：

很好的答案。我看到 OAuth 似乎是标准。但似乎有 2-legged OAuth 1.0、3-legged OAuth 1 然后是这个 OAuth 2 ......所以我应该研究 OAuth 2？ ...我在考虑 HTTPS/SSL，但我不确定 iPhone 应用程序之类的东西如何通过它传输（这甚至可能）？ ...关于 OAuth 的另一个问题，我可以既是提供者又是消费者，还是我需要 - 就像你说的 - 需要使用第三方进行身份验证？在这种情况下，使用第三方就不是那么可取了，它不是那种应用程序。感谢您的详细回复！

OAuth 2 是更新后的 OAuth。我相信 1.0 现在被认为是“坏的”。 iPhone 肯定会通过 HTTPS 工作（移动 Safari 中的 Github！）。

您可以两者兼而有之，但通常 OAuth 用于使用第三方进行身份验证。正如@mjtamlyn 在下面指出的那样，使用您当前的身份验证系统当然是可能的。我已经用一些步骤更新了我的答案。

感谢您的回答！这给了我很多需要处理的信息，因为所有这些身份验证内容对我来说都是非常新的 :)

我刚刚看到这篇文章，简要解释了 OAuth1 和 OAuth2 stormpath.com/blog/secure-your-rest-api-right-way

【参考方案2】：

这是一种不同的思考方式：

让我们暂时假设您没有使用 API。您的用户登录到应用程序，提供一些凭据，然后您向用户提供 cookie 或某种类似的令牌，用于识别该用户已登录。然后用户请求包含受限信息的页面（或创建/修改/删除它），因此您检查此令牌以确保允许用户查看该信息。

现在，在我看来，您在这里唯一要改变的是信息的传递方式。您不是以呈现的 html 形式提供信息，而是以 JSON 形式返回信息并在客户端呈现它。您对服务器的 AJAX 请求将携带与以前相同的登录令牌，因此我建议您只检查该令牌，并以相同的方式将信息限制为“允许用户知道的内容”。

您的 API 现在与您的登录一样安全 - 如果有人知道访问 api 所需的令牌，他们也将登录到该站点并访问所有信息。最好的一点是，如果您已经实现了登录，那么您实际上不必再做任何工作了。

OAuth 等系统的重点是提供这种“登录”方法，通常来自第三方应用程序并作为开发人员。对于 iPhone 应用程序或类似应用程序来说，这可能是一个很好的解决方案，但那是在未来。 API 接受不止一种身份验证方法并没有错！

【讨论】：

那我是不是想多了？我已经进行了“正常”身份验证...用户登录，为会话创建cookie，站点检查用户是否已登录各种“安全”部分。所以本质上，就是这样！？ ...我只是过度思考问题并尝试处理 OAuth 等，但实际上，它仍然只是基本的身份验证内容...现在，如果是这样，那很好！我想，如果有的话，我确实需要在我的服务器上对 SSL 进行排序，但除此之外，我可以使用我的正常身份验证程序吗？

这可能是我在这里遗漏了一些东西，但这不是违反 API 的资本规则吗？即：没有服务器端状态？如果服务器需要跟踪令牌，那么这意味着保持状态，这应该有点禁忌:-)

@Dieter 它是无状态的，因为状态没有在 http 中传递

@dieter 可以构造令牌，以便服务器不必维护已发行令牌的数据库来验证令牌。使用私钥对令牌进行签名，以便任何拥有匹配公钥的人都可以验证 a) 令牌是由受信任的服务器颁发的（真实性）和 b) 令牌没有被修改（保真度）。令牌是状态数据，因此服务器可以是无状态的。 OAuth2 没有定义令牌的内容，只是如何获取令牌。 JSON Web 令牌 (JWT) 定义了可与 OAuth2 一起使用的安全令牌格式。

@dthorpe 谢谢！这就说得通了。 TypoJohnson，为了记录，我很确定这不是 API 中无状态的含义。无状态 = API 可以处理任何请求，而无需记住任何内容。因此，服务器 2 是否处理一分钟前由服务器 1 服务的客户端并不重要。因此，在某些情况下，通过 http（由客户端）传递状态实际上是完全可以的。如果不可能，那么他们只需要在所有 API 服务器之间共享一个数据库或缓存

【参考方案3】：

到目前为止的答案在解释方面做得很好，但没有给出任何实际步骤。我看到这篇博文详细介绍了如何使用 Node + Passport 安全地创建和管理令牌。

http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/

【参考方案4】：

适用于保护任何 Web 应用程序的提示

如果您想保护您的应用程序，那么您绝对应该首先使用 HTTPS 而不是 HTTP，这样可以确保在您和用户之间创建一个安全通道防止嗅探来回发送给用户的数据，并有助于对交换的数据保密。

您可以使用 JWT（JSON Web Tokens）来保护 RESTful APIs，与服务器端会话相比，这有很多好处，好处主要是：

1- 更具可扩展性，因为您的 API 服务器不必为每个用户维护会话（当您有很多会话时，这可能是一个很大的负担）

2- JWT 是自包含的，并且具有定义用户角色的声明，例如，他可以访问的内容以及在日期和到期日发布的内容（在此之后 JWT 将无效）

3- 更容易跨负载均衡器处理，如果您有多个 API 服务器，因为您无需共享会话数据，也无需配置服务器以将会话路由到同一服务器，只要带有 JWT 的请求命中它的任何服务器可认证授权

4- 减少对数据库的压力，并且您不必为每个请求不断存储和检索会话 ID 和数据

5- 如果您使用强密钥对 JWT 进行签名，则 JWT 不会被篡改，因此您可以信任随请求发送的 JWT 中的声明，而无需检查用户会话以及他是否是授权与否，您只需检查 JWT，然后您就可以知道该用户可以做什么以及可以做什么。

用于实现 JWT 的 Node.js 特定库：

许多库提供了创建和验证 JWT 的简单方法，例如：在 node.js 中，最流行的方法之一是 jsonwebtoken，对于验证 JWT，您可以使用相同的库或使用 express-jwt 或 @987654323 @（如果你使用的是 express/koa）

由于 REST API 通常旨在保持服务器无状态，因此 JWT 更符合该概念，因为每个请求都使用自包含 (JWT) 的授权令牌发送，而无需服务器保持与使服务器有状态的会话相比，跟踪用户会话，以便它记住用户及其角色，但是，会话也被广泛使用并有其优点，您可以根据需要进行搜索。

需要注意的重要一点是，您必须使用 HTTPS 将 JWT 安全地传送到客户端并将其保存在安全的地方（例如本地存储中）。

您可以了解更多关于 JWT 的信息from this link