The*_*ner 1 security authentication frontend backend
如何保护我的后端不被其他未经授权的前端应用程序访问？我用谷歌搜索，找不到提供完整解决方案的解决方案。Instagram、Facebook 等公司如何阻止未经授权的请求？我读到 SSL 密钥可以通过对前端进行逆向工程找到。我是一个菜鸟，正在为一个项目构建一个社交网络。请指导我。
\n\n如何保护我的后端不被其他未经授权的前端应用程序访问？
\n
对于前端应用程序，我假设您指的是移动应用程序和网络应用程序，一旦我的专业知识更多地集中在移动应用程序和 API 安全性上，我将专注于移动应用程序，但我会给您一些关于网络应用程序的指导。
\n\n\n我用谷歌搜索，找不到提供完整解决方案的解决方案。
\n
让我告诉你一个残酷的事实，那是因为它不存在。存在的就是深度防御，您可以应用尽可能多的层来保护您的后端。
\n开发人员普遍认为，将 https 与用户身份验证结合使用（无论是与 OAUTH 提供商、您自己的 JWT 实现还是与传统会话和 cookie 结合使用）足以保护后端免受未经授权的访问，但这还远远不够。从 100% 有效开始，因为首先，用户身份验证仅识别谁正在访问后端，即用户，而不是识别什么正在访问它。
\n您可以想到什么，因为您的真正应用程序代表您认为的人执行请求，即使提供有效的令牌也是如此？或者是来自带有被盗令牌的自动化脚本的请求，或者来自 Postman 等工具的请求？您可以在我写的有关 API 密钥的文章的这一部分中阅读更多信息。
\n\n\n我读到 SSL 密钥可以通过对前端进行逆向工程找到。
\n
如果前端是一个 Web 应用程序，那么找到其中的任何秘密都很简单，只需按 F12 访问浏览器中的开发人员工具或右键单击以检查页面源代码即可。
\n如果前端是移动应用程序，那么一些开发人员可能会认为他们是安全的，因为移动应用程序是作为二进制文件发布的，但这是一种错误的安全感，因为存在很多工具对它们执行静态二进制分析，您可以阅读我写的另一篇文章，了解如何使用移动安全框架从移动应用程序二进制文件中提取 API 密钥。
\n如果静态二进制分析还不够，那么在攻击者无法控制的设备中，他可以执行 MitM（中间人）攻击，拦截应用程序和后端之间的所有通信。我有一篇关于移动应用程序上下文中的 MitM 的文章，您可以在此处阅读更多相关信息，您将在其中学习如何使用开源工具mitmproxy窃取 API 密钥，或者他们可以采用更高级的方法在运行时挂钩仪器框架，例如Frida：
\n\n\n将您自己的脚本注入黑盒进程。挂钩任何函数、监视加密 API 或跟踪私有应用程序代码，无需源代码。编辑，点击保存，然后立即看到结果。全部无需编译步骤或程序重新启动。
\n
\n\nInstagram、Facebook 等公司如何阻止未经授权的请求？
\n
他们将使用某种短期令牌或其他机制来识别用户，但正如我已经提到的，这只是为了识别请求中的人员。为了让他们知道什么在执行请求，他们可以诉诸机器学习和人工智能对传入请求执行用户行为分析（UBA），以检测异常的人类行为并阻止它们，您可以在维基百科中阅读更多内容：
\n\n\nGartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些表明潜在威胁的模式\xe2\x80\x94 异常中检测有意义的异常。[1] UBA 不跟踪设备或安全事件，而是跟踪系统的用户。
\n
正如您所看到的，UBA 追踪人类，换句话说就是请求中的WHO 。他们这样做是为了区分谁和什么正在执行请求，正如您可能想的那样，这很容易出现误报，因此此类系统中应用的策略规则需要考虑到这一点。
\n\n\n我是一个菜鸟，正在为一个项目构建一个社交网络。请指导我。
\n
虽然 UBA 解决方案容易出现误报，但它们可能是为 Web 应用程序提供服务的后端的最佳选择。要推出自己的 UBA 解决方案将非常昂贵，因为它需要大量资源、专业知识和时间，而购买商业解决方案可能会超出预算，因此您最好的选择可能是 Google reCAPTCHA V3：
\n\n\nreCAPTCHA v3 可帮助您检测网站上的滥用流量，而无需用户交互。reCAPTCHA v3 不显示验证码质询，而是返回分数，以便您可以为您的网站选择最合适的操作。
\n
为了保护为移动应用程序提供服务的 API 后端，我建议您阅读有关移动 API 安全性的一系列博客文章，您将在其中了解如何实施和绕过多种防御措施，例如 OAUTH JWT 令牌，并且您可以阅读其他系列的文章博客文章将向您展示一个虚构的应用程序和一个虚构的攻击者击败 API 密钥、OAUTH JWT 令牌以及使用 HMAC 签名的请求。
\n对于移动应用程序的后端，防御未经授权请求的最佳方法是使用移动应用程序证明解决方案，简而言之，该解决方案将允许后端识别正在执行请求的内容，而无需提供任何类型的秘密。就像传统的 API 密钥一样，在应用程序中提供，我在有关证书固定的文章的这一部分中更详细地介绍了移动应用程序证明的作用，您可以在其中阅读：
\n\n\n移动应用程序证明服务的作用是对发送请求的内容进行身份验证，从而仅响应来自真实移动应用程序实例的请求，并拒绝来自未经授权的来源的所有其他请求。
\n为了了解向 API 服务器发送请求的内容，移动应用程序证明服务将在运行时高度确信您的移动应用程序存在、未被篡改/重新打包、未在 root 中运行。设备，尚未被仪器框架（Frida、xPosed、Cydia 等）挂钩，并且不是中间人攻击 (MitM) 的对象。这是通过在后台运行 SDK 来实现的，该 SDK 将与云中运行的服务进行通信，以证明移动应用程序及其运行设备的完整性。
\n成功证明移动应用程序完整性后，将颁发一个短期 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名。如果证明失败，JWT 令牌将使用不正确的密钥进行签名。由于移动应用程序证明服务使用的秘密对于移动应用程序来说是未知的，因此即使应用程序已被篡改、在已取得 root 权限的设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程这是中间人攻击的目标。
\n移动应用程序必须在每个 API 请求的标头中发送 JWT 令牌。这允许 API 服务器仅在可以验证 JWT 令牌是使用共享密钥签名且尚未过期时才处理请求。所有其他请求都将被拒绝。换句话说，有效的 JWT 令牌告诉 API 服务器发出请求的是上传到 Google 或 Apple 商店的正版移动应用程序，而无效或丢失的 JWT 令牌意味着发出请求的内容未经授权。 ，因为它可能是机器人、重新打包的应用程序或进行 MitM 攻击的攻击者。
\n使用移动应用程序认证服务的一大好处是其主动且积极的身份验证模型，不会产生误报，因此不会阻止合法用户，同时将坏人拒之门外。
\n
在安全问题中，我总是喜欢通过推荐 OWASP 的出色工作来结束：
\n\n\n\n\nOWASP Web 安全测试指南包括用户可以在自己的组织中实施的“最佳实践”渗透测试框架和描述测试最常见 Web 应用程序和 Web 服务安全问题的技术的“低级”渗透测试指南。
\n
\n\n移动安全测试指南 (MSTG) 是移动应用安全开发、测试和逆向工程的综合手册。
\n