检测从 Postman 发送的请求

Posted 2023-03-15

【中文标题】检测从 Postman 发送的请求

【英文标题】：Detect Request sent from Postman

【发布时间】：2020-09-12 19:02:18

【问题描述】：

我想请求使用 laravel 验证人们的 ID。由于它非常具有凭据，因此我只想在他们通过手机验证时才可以使用它。 因此，必须防止从邮递员请求中验证 ID。 有没有办法检测到邮递员是否发送了请求？

任何想法都会非常感激:)。 之前谢谢你

【参考方案1】：

Postman 倾向于发送名为 postman-token 之类的标头，因此如果存在此类标头，您可以阻止请求。

编辑注意这个header可以在postman设置中关闭

正如@EdwardChew 所写，这并不妨碍人们使用 postman/curl/python/其他任何东西。向端点添加身份验证是最好的方法。

邮递员请求示例：

GET /api/car HTTP/1.1
Host: localhost:8080
Content-Type: application/json
cache-control: no-cache
Postman-Token: 05f5c492-3697-41b1-be0f-fb9bc4499b96

由于邮递员具有“代码”功能，如果请求被阻止，很容易将其复制为 curl 命令：

curl -X GET \
  http://localhost:8080/api/car \
  -H 'Content-Type: application/json' \
  -H 'Postman-Token: e37790ea-a3a5-40cf-ac4c-b80184801f94' \
  -H 'cache-control: no-cache'

并删除带有Postman-Token 标头的行。我通常在试验 API 时这样做。

如果你查看 Laravel 文档，有一节关于授权：https://laravel.com/docs/5.8/api-authentication 这将强制用户添加类似这样的标头令牌：Authorization: Bearer 8fyew8f9yefo7o9yg98gyr，然后您就可以验证调用者

【讨论】：

postman-token 是一个可选令牌，可以通过设置菜单禁用，因此我不会在您的任何工作流中依赖该属性。

好点，我认为共识是认证是最好的方法

【参考方案2】：

因此必须防止通过邮递员请求验证 ID。 有没有办法检测到邮递员是否发送了请求？

对于从 Postman 发送的请求，检查它是否来自 Postman 很容易，其中选中了 Postman-Token 和/或 User-Agent 的框：

因此，您可以在后端添加对它们的检查，但攻击者不会发送 Postman-Token 标头，而对于 User-Agent，我们只会发送与您的移动应用程序/浏览器发送的完全相同的标头，因此很容易绕过你的支票。顺便说一句，Postman 不是唯一的工具，还有其他工具，例如 Insomnia，然后您还需要记住，请求也可能来自 mitmproxy、burp、zap、charlie 等许多代理。你明白了吗...依靠标头来识别什么正在执行请求是不可行的。

我突出显示了 what 这个词，因为 谁 在请求您的 API 后端与 what 正在做的不同。

访问 API 服务器的对象和对象的区别

在我写的一篇题为 Why Does Your Mobile App Need An Api Key? 的文章中，您可以阅读更多关于 谁 和 what 访问您的 API 服务器之间的区别，但我将引用从它开始：

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

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

所以 谁 是您的 API 服务器的用户，您将能够验证和授权对数据的访问，而 什么 是发出该请求的软件代表用户、您的真正网络/移动应用程序、被篡改的应用程序、自动脚本或通过 cURL、Postman 或其他类似工具手动使用您的 API 的人。

到目前为止，我希望您有足够的知识来理解为什么用户（who）身份验证与应用（what）身份验证/证明不同。

可能的解决方案

我想请求使用 laravel 验证人们的 ID。由于它非常具有凭据，因此我只想在他们通过手机验证时才提供它。

不清楚您是指来自移动浏览器还是移动应用，但我会为两者提供可能的解决方案。

对于移动应用

要了解如何将 API 服务器锁定到您的移动应用程序，我建议您阅读 my answer 问题如何保护移动应用程序的 API REST？ 以了解保护 API 服务器和可能的更好解决方案。

对于网络应用程序

由于 Web 构建方式的性质，您只需按 F12 或检查页面源代码，然后从其他工具搜索访问 API 服务器所需的任何内容。

要学习一些有用的技术来尝试让您的 API 服务器只响应来自您所期望的什么的请求，您的真正网络应用程序，我邀请您阅读my answer 问题保护 api 数据免受应用外调用的影响，特别是专门用于保护 API 服务器的部分。

您想加倍努力吗？

我不知道您是否已经阅读了我将要链接的一些 OWASP 资源，但在任何安全问题的回复中，我喜欢参考 OWASP 基金会的出色工作；)

对于网络应用程序

OWASP Web Top 10 Risks

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

The Web Security Testing Guide:

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

对于移动应用

OWASP Mobile Security Project - Top 10 risks

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

OWASP - Mobile Security Testing Guide:

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

对于 APIS

OWASP API Security Top 10

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

【参考方案3】：

我认为与其检测请求是否来自 Postman，不如通过身份验证保护端点。 这样，即使用户通过邮递员提交了请求，您仍然可以确保是用户自己提出了请求。

如果还有其他问题困扰您，请务必告诉我。干杯:)

【讨论】：

我真正的意思是如何确保验证请求仅从应用程序端点发送（直接从他们的智能手机上的应用程序）所以如果这个特定请求是从 Postman 或任何其他 REST 发送的API 工具而不是智能手机，这将导致失败或未经授权的请求。有可能吗？

如果你真的想实现这一点，我建议在你的应用程序中添加一个密钥。当您提出任何请求时，请使用密钥加密您的正文并在您的服务器上解密正文。这会增加发送模仿请求的难度，但仍然可以进行逆向工程并获取您的应用程序密钥，但要困难得多。

@Ardi Tan 您应该更新您的问题，说明您的目标是检测到该请求确实来自移动应用程序，因为这完全改变了您问题的范围。