laravel - 如何在没有注册用户身份验证的情况下保护公共 API 请求

问题描述

我无法理解组织如何从收集数据的任何人那里保护他们的公共 API 的问题。我知道我们使用护照和其他方式的身份验证令牌来保护未经授权的用户的私人信息。但是有些东西，比如公共搜索引擎，不需要用户进行身份验证，就可以通过搜索或访问个人资料信息页面在 Facebook 上找到一个人。这意味着存在不需要用户身份验证的开放公共 api。

但是通过几个组织，我没有设法获得任何可以通过 Postman 访问或通过 url 访问的公共 api 请求。

所以我很感兴趣组织如何保护他们的公共 api 免受请求。前端如何向那些公共（有点私人的 api）发送请求，或者即使它有某种用于所有公共 api 调用的默认 api 密钥，如果在我们的现代浏览器中我们可以访问本地存储，它们是如何保护这些的或我们可以提取公共 api_token 的 Cookie

我对 MERN STACK 和 Laravel + SPA React 应用程序感到困惑。

为 api 调用开发公共路由，它们都可以从浏览器 url 或邮递员访问，除非该路由是私有的并且需要来自护照的 auth_token 或已经要求用户注册的 jsonwebtoken。但我试图在我的应用程序中实现用户无需身份验证即可搜索和访问产品详细信息。

但显然我不喜欢任何类型的大数据工程师会轻易地从我的 Web 应用程序中窃取所有公共数据，除非他不懒惰并且为每个公共产品详细信息页面进行 html 解析。

那么如何在我的后端应用程序中保护上述公共 api 路由。以及 Facebook、Google、LinkedIn 等大型组织的表现如何？

我之所以问这个问题，是因为很容易找到一些 MERN Stack 课程，他们会教你如何处理授权用户的身份验证等等。甚至是 LAMP 技术。但是没有人解释如何在不要求任何用户登录的情况下保护这些数据。

非常感谢您提前回答这个冗长且非常令人困惑的问题的任何人。

标签： laravelapisecuritybackendmern

解决方案

但是有些东西，比如公共搜索引擎，不需要用户进行身份验证，就可以通过搜索或访问个人资料信息页面在 Facebook 上找到一个人。

当我在 PHP 中编码并使用 Prestashop 电子商务时，我使用了一个类似于这个 gist中的 Crawler/Bot ，但这很容易被欺骗，因为它基于HTTP_USER_AGENT. 一个更好的方法是使用 IP 地址来查找熟悉的爬虫，也就是来自 Google 和 Bing 等搜索引擎的爬虫，但这对于阻止坏爬虫和机器人来说是无效的。因为他们非常频繁地切换 IP 地址。

但是通过几个组织，我没有设法获得任何可以通过 Postman 访问或通过 url 访问的公共 api 请求。

像 Facebook 甚至更小的公司，拥有大量资源可供使用，使用人工智能 (AI) 试图在谁在做好和坏请求之间划清界限，这种类型的软件被称为用户行为分析（UBA）：

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

所以这一定是你很难通过 Facebook 等公司的 API 的原因，但这并不意味着不可能，因为黑客一直在这样做，而且大公司每年发生的数据泄露事件的数量是一个证明。

我之所以问这个问题，是因为很容易找到一些 MERN Stack 课程，他们会教你如何处理授权用户的身份验证等等。甚至是 LAMP 技术。但是没有人解释如何在不要求任何用户登录的情况下保护这些数据。

嗯，这可能是因为开发人员之间存在一个普遍的误解，他们并不真正了解谁与向 API 服务器发出请求的对象之间的区别。

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

我写了一系列关于API 和移动安全的文章，来自文章Why Does Your Mobile App Need An Api Key? 我将引用以下内容：

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

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

将谁视为您的 API 服务器将能够验证和授权对数据的访问的用户，并将“什么”视为代表用户发出该请求的软件。

因此，在我看来，很多开发人员并没有意识到请求中Who和What之间的这种区别，因此他们专注于Who的解决方案。

可能的解决方案

那么如何在我的后端应用程序中保护上述公共 api 路由。以及 Facebook、Google、LinkedIn 等大型组织的表现如何？

这些组织正在使用非常复杂的 UBA 解决方案，可能不是每个组织都能够在成本方面或因为它们是专有解决方案，但存在其他解决方案，您可以阅读我给出的其他回复中的捍卫 API 服务器部分回答问题以了解如何逐步提高 Web 应用程序的 API 服务器的安全性。secure api data from calls out of the app

如果您还需要保护来自移动应用程序的请求的 API 服务器，那么您可以通过采用移动应用程序证明概念以非常高的信心将其锁定到您的移动应用程序，您可以在此阅读更多信息回复我给的问题如何保护移动应用程序的 API REST？.

你想加倍努力吗？

如果不参考 OWASP 基金会的出色工作，我无法完成对安全问题的任何回答。

对于网络应用

OWASP Web 十大风险

OWASP Top 10 是一个强大的 Web 应用程序安全意识文档。它代表了对 Web 应用程序最关键的安全风险的广泛共识。项目成员包括来自世界各地的各种安全专家，他们分享了他们的专业知识来制作此列表。

网络安全测试指南：

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

对于移动应用

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

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

OWASP - 移动安全测试指南：

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

对于 APIS

OWASP API 安全前 10 名

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