Обнаружить запрос, отправленный от почтальона

Question

Я хочу сделать запрос на проверку личности людей с помощью laravel. Поскольку это очень учетные данные, я хочу сделать его доступным только в том случае, если они проверят его со своих мобильных телефонов.
Поэтому необходимо предотвратить проверку идентификаторов из запроса почтальона.
Есть ли способ определить, что запрос отправлено почтальоном или нет?

Любая идея была бы очень оценена :)

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

Я думаю, вместо того, чтобы определять, исходит ли запрос от Почтальона, вам лучше защитить конечную точку с помощью аутентификации. При этом, даже если пользователь отправил запрос через почтальона, вы все равно можете убедиться, что запрос сделал сам пользователь.

Пожалуйста, дайте мне знать, если вас действительно беспокоят другие проблемы. Ура :)

Answer 3

Таким образом, необходимо предотвратить проверку идентификаторов по запросу почтальона. Есть ли способ определить, отправлено ли запрос от почтальона или нет?

Проверить, что он исходит от почтальона, легко для запросов, отправленных от почтальона, где флажки отмечены на Postman-Token и / или User-Agent:

So you would add a check for them in your backend, but then the attacker would not send the Postman-Token header and for the User-Agent we will just send exactly the same one your mobile app/browser sends, thus easily bypassing your checks. By the way Postman is not the only tool, others exist like Insomnia, and then you also need to remember that requests may also come from a Proxy like mitmproxy, burp, zap, charlie, and many others. Do you get the point... it's not feasible to rely on headers to identify what is doing the request.

I highlighted the word what because who is in the request for your API backend is not the same as what is doing it.

The Difference Between WHO and WHAT is Accessing the API Server

In an article I wrote, entitled Зачем вашему мобильному приложению нужен ключ Api? вы можете узнать больше о разнице между who и what is доступ к вашему серверу API, но я процитирую из него следующее:

what - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем сервере API с помощью такого инструмента, как Postman?

who is пользователь мобильного приложения, которого мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя потоки OpenID Connect или OAUTH2.

Итак, who является пользователем вашего API сервер, на котором вы сможете аутентифицировать и авторизовать доступ к данным, и what - это программное обеспечение, выполняющее этот запрос от имени пользователя, ваше подлинное веб-приложение / мобильное приложение, подделанное, автоматизированный сценарий или кто-то вручную ковыряется в вашем API через cURL, Postman или другие подобные инструменты.

К настоящему моменту я надеюсь, что у вас достаточно знаний, чтобы понять, почему пользователь ( who ) аутентификация - это не то же самое, что аутентификация / аттестация app ( what ).

ВОЗМОЖНЫЕ РЕШЕНИЯ

Я хочу сделать запрос на ve Идентификационный номер рижского человека с использованием laravel. Поскольку это очень учетные данные, я хочу сделать его доступным только в том случае, если они проверит его со своих мобильных телефонов.

Не ясно, имеете ли вы в виду мобильный браузер или мобильное приложение, но я предоставлю возможные решения для оба.

Для мобильных приложений

Чтобы узнать, как можно заблокировать сервер API для мобильного приложения, я рекомендую вам прочитать мой ответ на вопрос Как чтобы защитить API REST для мобильного приложения? для разделов Защита сервера API и Возможное лучшее решение .

Для веб-приложений

Из-за того, как был построен Интернет, все, что вам нужно, - это нажать F12 или проверить источник страницы, а затем найти все, что вам нужно для доступа к серверу API из другого инструмента.

Чтобы изучите некоторые полезные методы, чтобы попробовать, чтобы ваш сервер API отвечал только на запросы, исходящие от What , которое вы ожидаете, вашего подлинного веб-приложения, я предлагаю вам прочитать мой ответ на вопрос Безопасный AP i данные о звонках из приложения , особенно раздел, посвященный Защите сервера API .

ХОТИТЕ GO ДОПОЛНИТЕЛЬНУЮ МИЛЬ?

Не знаю, читали ли вы уже некоторые ресурсы OW ASP, на которые я собираюсь сослаться, но в любом ответе на секретный вопрос я хотел бы сослаться на потрясающую работу от OW ASP foundation;)

Для веб-приложений

OW ASP 10 самых популярных рисков в Интернете

OW ASP 10 лучших веб-сайтов безопасность приложений. Он представляет собой широкий консенсус в отношении наиболее серьезных угроз безопасности веб-приложений. В состав участников проекта входят различные эксперты по безопасности со всего мира, которые поделились своим опытом при составлении этого списка.

The Web Security Testing Guide :

OW ASP Руководство по тестированию веб-безопасности включает в себя «передовую» структуру тестирования на проникновение, которую пользователи могут реализовать в своих организациях, и «низкоуровневое» руководство по тестированию на проникновение, в котором описаны методы тестирования наиболее распространенных веб-приложений и безопасности веб-сервисов

Для мобильных приложений

OW ASP Mobile Security Project - 10 основных рисков

The OW ASP Mobile Security Project - это централизованный ресурс, предназначенный для предоставления разработчикам и командам безопасности ресурсов, необходимых им для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель - классифицировать риски мобильной безопасности и предоставить средства управления разработкой, чтобы уменьшить их влияние или вероятность использования.

OW ASP - Руководство по тестированию мобильной безопасности :

Руководство по тестированию мобильной безопасности (MSTG) - это подробное руководство по разработке, тестированию и обратному проектированию безопасности мобильных приложений.

Для APIS

OW ASP Топ 10 по безопасности API

Проект обеспечения безопасности API OW ASP стремится предоставить ценность разработчикам программного обеспечения и специалистам по оценке безопасности, подчеркивая потенциальные риски небезопасных API-интерфейсов и иллюстрируя, как можно уменьшить эти риски. Чтобы способствовать достижению этой цели, OW ASP API Security Project создаст и будет поддерживать документ «10 основных рисков безопасности API», а также портал документации для передовых практик при создании или оценке API.