提问人:Intenex 提问时间:3/29/2021 更新时间:3/30/2021 访问量:3080
保护对 API 端点的客户端调用的最佳实践
Best practice for securing a client side call to an API endpoint
问:
我正在构建一个应用程序,我需要在客户端前端应用程序中向外部 API 发出请求,我有点不知所措,不知道如何使其最大安全,以便只有有效的请求才能转发到这个外部 API,而不是任何人想要的。
作为安全性的第一步,我这样做是为了让客户端应用程序不能直接与外部 API 通信,而必须访问我们自己的服务器端 API,然后服务器端 API 将请求代理到外部 API,以便用于访问外部 API 的凭据至少仅存储在服务器端,而不是客户端。
然而,这导致了同样的根本问题 - 我如何保护我用于验证从客户端应用程序到我们自己的服务器端应用程序发出的请求的任何凭据/身份验证系统?
问题在于,这是一项在线餐厅订购服务,因此我们不希望用户在能够下订单之前使用用户名和密码进行身份验证,因此触发外部 API 调用的订单下达不受任何用户名/密码方案的约束,并且必须可供前端应用程序的所有消费者使用。
这里的安全最佳实践是什么?我已将 CORS 白名单作为最低限度的做法,这样我们的服务器端 API 端点理论上只允许来自我们自己域的请求,但如果有人选择只欺骗源 URL,则很容易绕过 CORS。
还有哪些其他选项?我敢肯定,我一定只是遗漏了一些微不足道的东西,因为这一定是一个非常普遍的问题,具有既定的最佳实践,但我只是不知何故没有找到它。
谢谢!
答:
最终,您的客户端需要在第三方 API 上执行一些操作。
所以我们知道应该允许某些操作,并且根据您的描述,我们也知道不是每个操作都应该被允许。
所以你的安全应该基于这个前提。不要创建一个转发每个请求的哑代理,但您的中间 API 应该根据您设置的规则,仅明确允许您希望它允许的操作。
如果你没有用户名和密码,你可能仍然有一些其他类型的规则来识别一个人(电子邮件/电话号码?),这意味着你可以创建一个身份验证系统。
或者,也许只有在用户使用信用卡完成订单后才能调用您的第三方服务,该逻辑需要存在于您的 API 中。
作为 API 和移动安全的开发者倡导者,看到一个真正关心他们的应用程序安全的开发者总是让我微笑,尤其是当他们已经表现出为保护它付出了一些努力时,因此请接受我对你的努力的祝贺。
我的答案背景
我正在构建一个应用程序,我需要在客户端前端应用程序中向外部 API 发出请求,我有点不知所措,不知道如何使其最大安全,以便只有有效的请求才能转发到这个外部 API,而不是任何人想要的。
因此,您还没有详细说明它是 Web 应用程序还是移动应用程序,一旦我的专业知识依赖于移动应用程序和 API 安全性,我将假设它是移动应用程序。
挑战
问题在于,这是一项在线餐厅订购服务,因此我们不希望用户在能够下订单之前使用用户名和密码进行身份验证,因此触发外部 API 调用的订单下达不受任何用户名/密码方案的约束,并且必须可供前端应用程序的所有消费者使用。
你在这里有一个复杂的挑战需要解决,因为你有一个向公众开放的应用程序,没有任何形式的用户身份验证/识别,但它需要访问下划线资源的规则,就好像它落后于用户身份验证和授权一样,但即使有,它仍然容易被滥用。
为了理解为什么我需要澄清一个误解,我通常会在任何资历的开发人员中发现这种误解,那就是访问API服务器的人和内容之间的区别。
WHO 和 WHAT 之间的区别是访问 API 服务器
我写了一系列关于 API 和移动安全的文章,在文章中为什么您的移动应用程序需要 API 密钥? 您可以详细阅读访问您的 API 服务器的人和内容之间的区别,但我将在这里摘录其中的主要内容:
向 API 服务器发出请求的事物是什么。它真的是您的移动应用程序的真实实例,还是机器人、自动脚本或攻击者使用 Postman 等工具手动绕过您的 API 服务器?
谁是移动应用程序的用户,我们可以通过多种方式对其进行身份验证、授权和识别,例如使用 OpenID Connect 或 OAUTH2 流。
考虑谁作为用户,您的 API 服务器将能够对数据进行身份验证和授权访问,并考虑代表用户发出该请求的软件。
因此,在你的情况下,你无法识别谁在请求中,因此你需要一个解决方案,能够给 API 后端提供非常高的信心,即请求确实来自它所期望的,一个真实的、未经修改的应用实例。
可能的解决方案
我正在构建一个应用程序,我需要在客户端前端应用程序中向外部 API 发出请求,我有点不知所措,不知道如何使其最大安全,以便只有有效的请求才能转发到这个外部 API,而不是任何人想要的。
这需要非常先进的解决方案来正确保护,因此要实现并非易事,正如您想象的那样:
我敢肯定,我一定只是遗漏了一些微不足道的东西,因为这一定是一个非常普遍的问题,具有既定的最佳实践,但我只是不知何故没有找到它。
是的,这是一个经常被忽视或没有正确解决的常见问题,解决它的第一步是清楚地了解请求中的人与内容之间的区别,否则设计的解决方案将无法正确解决问题。
对于移动应用程序
在这里,我建议你仔细阅读我对如何保护移动应用程序的API REST问题给出的答案,特别是“强化和屏蔽移动应用程序”、“保护API服务器”和“可能的更好解决方案”部分。
此答案将向你展示几种解决方案,例如 WAF 和 UBA,但最后建议使用移动应用证明概念。
简而言之,移动应用证明将允许 API 后端具有非常高的信心,即请求确实来自它所期望的,即移动应用的真实和修改实例。
对于 Web 应用
你可以学习一些有用的技术来帮助你的 API 后端尝试只响应来自你所期望的、你的正版 Web 应用程序的请求,为此,我邀请你阅读我对问题的回答 保护 API 数据免受应用程序调用,尤其是专门用于保护 API 服务器的部分。
你想走得更远吗?
在回答安全问题时,我总是喜欢引用OWASP基金会的出色工作。
对于 API
OWASP API 安全项目旨在通过强调不安全 API 的潜在风险,并说明如何减轻这些风险,为软件开发人员和安全评估人员提供价值。为了实现这一目标,OWASP API 安全项目将创建和维护 10 大 API 安全风险文档,以及创建或评估 API 时最佳实践的文档门户。
对于移动应用程序
OWASP移动安全项目是一个集中式资源,旨在为开发人员和安全团队提供构建和维护安全移动应用程序所需的资源。通过该项目,我们的目标是对移动安全风险进行分类,并提供发展控制,以减少其影响或被利用的可能性。
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
对于 Web 应用
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
评论