1

我正在构建一个应用程序,我需要在客户端前端应用程序中向外部 API 发出请求,而我对如何最大限度地保证这一点感到有点茫然,以便只能转发有效的请求到这个外部 API,而不是任何人想要的。

作为安全性的第一步,我已经做到了,客户端应用程序不能直接与外部 API 对话,而是必须访问我们自己的服务器端 API,然后将请求代理到外部 API,以便访问外部 API 的凭据至少单独存储在服务器端而不是客户端。

然而,这导致了同样的基本问题——我如何保护我用来验证从客户端应用程序向我们自己的服务器端应用程序发出的请求的任何凭证/身份验证系统?

问题是这是一个在线餐厅订购服务,因此我们不希望用户在能够下订单之前使用用户名和密码进行身份验证,因此触发外部 API 调用的下订单不是t 封闭在任何用户名/密码方案之后,并且必须可供前端应用程序的所有消费者使用。

这里的最佳安全实践是什么?我已启用 CORS 白名单作为最低限度的做法,这样理论上我们的服务器端 API 端点只允许来自我们自己域的请求,但如果有人选择欺骗原始 URL,CORS 会被轻易绕过。

还有哪些其他选择?我确定我一定是遗漏了一些琐碎的事情,因为这对于已建立的最佳实践来说一定是一个非常普遍的问题,但我只是不知何故找不到它。

谢谢!

4

2 回答 2

2

作为 API 和移动安全的开发者倡导者,看到真正关心其应用程序安全性的开发人员总是让我微笑,尤其是当他们已经表现出为保护它做出了一些努力时,因此接受我对您的努力表示祝贺。

我的答案上下文

我正在构建一个应用程序,我需要在客户端前端应用程序中向外部 API 发出请求,而我对如何最大限度地保证这一点感到有点茫然,以便只能转发有效的请求到这个外部 API,而不是任何人想要的。

因此,您没有详细说明它是 Web 应用程序还是移动应用程序,一旦我的专业知识依赖于移动和 API 安全性,我将假设是移动应用程序来回答。

挑战

问题是这是一个在线餐厅订购服务,因此我们不希望用户在能够下订单之前使用用户名和密码进行身份验证,因此触发外部 API 调用的下订单不是t 封闭在任何用户名/密码方案之后,并且必须可供前端应用程序的所有消费者使用。

你有一个复杂的挑战需要解决,因为你有一个向公众开放的应用程序,没有任何类型的用户身份验证/识别,但这需要访问下划线资源的规则,就好像它在用户身份验证和授权之后一样,但即使是这样,它仍然容易被滥用。

要理解为什么我需要澄清一个通常在任何资历的开发人员中发现的误解,那就是访问 API 服务器的人员和对象之间的区别。

访问 API 服务器的 WHO 和 WHAT 之间的区别

我写了一系列关于 API 和移动安全的文章,在文章为什么你的移动应用需要 Api Key?您可以详细阅读访问 API 服务器的人员访问者之间的区别,但我将在此处提取其中的主要内容:

向 API 服务器发出请求的内容是什么。它真的是您的移动应用程序的真实实例,还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器?

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

想想是您的 API 服务器将能够验证和授权对数据的访问的用户,并想想代表用户发出请求的软件是什么。

因此,在您的情况下,您无法确定在请求中,因此您需要一个能够让 API 后端高度确信请求确实来自其预期的解决方案一个真实且未经修改的实例你的应用程序。

可能的解决方案

我正在构建一个应用程序,我需要在客户端前端应用程序中向外部 API 发出请求,而我对如何最大限度地保证这一点感到有点茫然,以便只能转发有效的请求到这个外部 API,而不是任何人想要的。

这需要非常先进的解决方案才能正确保护,因此您可能认为实现这一目标并非易事:

我确定我一定是遗漏了一些琐碎的事情,因为这对于已建立的最佳实践来说一定是一个非常普遍的问题,但我只是不知何故找不到它。

是的,这是一个经常被忽视或没有正确解决的常见问题,解决它的第一步是清楚地了解请求中的内容之间的区别,否则设计的解决方案将无法解决正确发出。

对于移动应用

在这里,我建议您仔细阅读我对如何保护移动应用程序的 API REST问题的答案?,特别是强化和屏蔽移动应用程序保护 API 服务器可能的更好解决方案等部分。

此答案将向您展示几种解决方案,例如 WAF 和 UBA,但最后建议使用移动应用程序证明概念。

简而言之,移动应用程序认证将允许 API 后端高度确信请求确实来自它所期望的,即移动应用程序的真实和修改实例。

对于网络应用

您可以学习一些有用的技术来帮助您的 API 后端尝试仅响应来自所期望的、真正的 Web 应用程序的请求,为此,我邀请您阅读我对安全 api data from calls out of call问题的回答应用程序,尤其是专用于保护 API 服务器的部分。

你想加倍努力吗?

在回答安全问题时,我总是喜欢参考 OWASP 基金会的出色工作。

对于 APIS

OWASP API 安全前 10 名

OWASP API 安全项目旨在通过强调不安全 API 中的潜在风险并说明如何减轻这些风险,为软件开发人员和安全评估人员提供价值。为了促进实现这一目标,OWASP API 安全项目将创建和维护一个 Top 10 API 安全风险文档,以及一个文档门户,用于在创建或评估 API 时提供最佳实践。

对于移动应用

OWASP 移动安全项目 - 十大风险

OWASP 移动安全项目是一个集中资源,旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目,我们的目标是对移动安全风险进行分类并提供开发控制以减少其影响或被利用的可能性。

OWASP - 移动安全测试指南

移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。

对于网络应用

网络安全测试指南

OWASP Web 安全测试指南包括一个“最佳实践”渗透测试框架,用户可以在他们自己的组织中实施它和一个“低级”渗透测试指南,描述了测试最常见的 Web 应用程序和 Web 服务安全问题的技术。

于 2021-03-29T10:47:37.457 回答
1

最终,您的客户需要对 3rd 方 API 执行一些操作。

所以我们知道应该允许一些操作,根据你的描述我们也知道不是每个操作都应该被允许。

所以你的安全应该基于这个前提。不要创建一个转发每个请求的哑代理,但您的中间 API 应该只根据您设置的规则专门允许您希望它允许的操作。

如果您没有用户名和密码,您可能还有一些其他类型的规则来识别一个人(电子邮件/电话号码?),这意味着您可以创建一个身份验证系统。

或者,您的 3rd 方服务可能只应在用户使用信用卡完成订单后调用,该逻辑需要存在于您的 API 中。

于 2021-03-29T04:34:23.237 回答