检测邮递员发送的请求

Question

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

任何想法都会很感激:)。
谢谢你

Answer 1

邮递员倾向于发送诸如postman-token之类的标头，因此如果存在这样的标头，则可以阻止该请求。

编辑请注意，可以在邮递员设置中关闭此标头

正如@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，然后您就可以验证呼叫者

Answer 2

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

请告知我是否还有其他困扰您的问题。干杯：）

Answer 3

因此，必须防止从邮递员的请求中验证ID。 有没有办法检测邮递员是否发送了请求？

对于来自Postman的请求，检查来自Postman-Token和/或User-Agent的框，很容易检查它是否来自Postman：

因此，您将在后端添加对它们的检查，但是攻击者将不会发送Postman-Token标头，而对于User-Agent，我们将只发送与您的移动应用/浏览器相同的标头发送，从而轻松绕过您的支票。顺便说一下，Postman并不是唯一的工具，还有其他类似失眠的工具存在，然后您还需要记住，请求也可能来自Proxy，例如mitmproxy，burp，zap，charlie等。您明白了吗...依靠标头识别正在做什么正在执行请求是不可行的。

我突出显示what一词是因为请求您的API后端的谁与正在做什么。

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

在我写的名为Why Does Your Mobile App Need An Api Key?的文章中，您可以详细了解谁和什么正在访问您的API服务器之间的区别，但我会引用以下内容：

什么是向API服务器发出请求的东西。它确实是您的移动应用程序的真正实例，还是机器人，自动脚本还是攻击者使用诸如Postman之类的工具手动在您的API服务器上闲逛？

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

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

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

可能的解决方案

我想请求使用laravel验证用户的ID。由于它是非常有凭据的，因此我只想让他们在手机上对其进行验证即可。

尚不清楚您是从移动浏览器还是从移动应用程序访问，但是我将为这两种方法提供可能的解决方案。

对于移动应用

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

对于网络应用程序

由于网络构建方式的本质，您所需要做的只是点击F12或检查页面源，然后搜索通过其他工具访问API服务器所需的内容。

要学习一些有用的技术，以尝试使您的API服务器仅响应来自您期望的什么（真正的网络应用）的请求，我邀请您阅读问题my answer < strong>从应用程序外的调用中保护api数据，尤其是专门用于防御API服务器的部分。

您想参加额外的战斗吗？

我不知道您是否已经阅读了一些我将要链接的OWASP资源，但是在对安全性问题的任何答复中，我都希望引用OWASP基金会的出色工作；）

对于Web Apps

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安全风险”文档，以及用于创建或评估API的最佳实践的文档门户。