Как защитить запросы API publi c без аутентификации от зарегистрированных пользователей - PullRequest
0 голосов
/ 19 апреля 2020

Я разбираюсь с проблемой, когда не могу понять, как организация защищает свои публикации c apis от любого человека, который собирает данные. Я знаю, что мы используем паспорт и другие способы авторизации токенов, чтобы защитить личную информацию от неавторизованного пользователя. Но есть такие вещи, как publi c Поисковая система, которая не требует аутентификации пользователя, чтобы найти на Facebook человека с помощью поиска или доступа к странице информации о профиле. Это означает, что существуют открытые API-интерфейсы publi c, для которых не требуется аутентификация пользователя.

Но, пройдя через несколько организаций, мне не удалось получить ни один запрос publi c api, к которому я мог бы получить доступ через Postman или просто через url.

Так что мне интересно, как организация защищает свои publi c api от запросов. Как веб-интерфейс отправляет запросы этим publi c (своего рода приватным API), или даже если он имеет какой-то ключ API по умолчанию для всех видов вызовов API Publi c, как они защищают их от людей, если в нашем современном браузеры, к которым мы можем получить доступ к локальному хранилищу или файлам cookie, где мы можем извлечь эти публикации c api_token

Я запутался в MERN STACK и Laravel + SPA React приложении.

Разработка Publi c маршруты для вызовов API, все они доступны из URL браузера или почтальона, если только маршрут не является закрытым и требует auth_token из паспорта или jsonwebtoken, который уже требует регистрации пользователя. Но я пытаюсь добиться, чтобы в моем приложении пользователи могли искать и получать доступ к информации о продукте без аутентификации.

Но, очевидно, мне не хотелось бы, чтобы какой-либо инженер больших данных легко крал все публикации c данные из моего веб-приложения, если только он не ленится и не разбирает html для каждой публикуемой страницы c Сведения о продукте.

Итак, как мне защитить вышеописанные маршруты publi c api в моем бэкэнде применение. И как это делают крупные организации, такие как Facebook, Google, LinkedIn и др. c.

Причина, по которой я задаю этот вопрос, потому что так легко найти какой-нибудь курс MERN Stack, и они научат вас как обрабатывать аутентификацию для авторизованных пользователей и тд. Или даже технологии LAMP. Но никто не объясняет, как защитить эти данные, не требуя входа какого-либо пользователя.

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

Ответы [ 2 ]

0 голосов
/ 23 апреля 2020

Но есть такие вещи, как publi c Поисковая система, которой не требуется аутентификация пользователя, чтобы найти на Facebook человека с помощью поиска или доступа к странице информации о профиле.

Когда Я кодировал в PHP и работал с электронной коммерцией Prestashop. Я использовал Crawler / Bot, похожий на тот, что был в этом гисте , но это легко подделать, потому что он основан на HTTP_USER_AGENT , Лучшим подходом здесь является использование IP-адресов для поиска известных сканеров, таких как поисковые системы, такие как Google и Bing, но это не поможет удержать плохих сканеров и ботов. потому что они очень часто переключают IP-адреса.

Но, пройдя через несколько организаций, мне не удалось получить ни один publi c api-запрос, к которому я мог бы получить доступ через Postman или простой через url.

Такие компании, как Facebook или даже более мелкие компании, располагающие достаточным количеством ресурсов, используют Искусственный интеллект (ИИ), чтобы попытаться провести черту между Кто делает добро и плохо запросы, и этот тип программного обеспечения известен как Аналитика поведения пользователя (UBA) :

Аналитика поведения пользователя (UBA), как определено Gartner, представляет собой процесс кибербезопасности при обнаружении инсайдера. угрозы, целевые атаки и финансовое мошенничество. Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы. Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы. Платформы больших данных, такие как Apache Had oop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.

Так что, должно быть, именно поэтому Трудно получить доступ к API таких компаний, как Facebook, но это не значит, что это невозможно, потому что хакеры делают это, и количество утечек данных, происходящих каждый год в крупных компаниях, тому подтверждение.

Причина, по которой я задаю этот вопрос, потому что так легко найти какой-нибудь курс MERN Stack, и они научат вас, как обращаться с аутентификацией для авторизованных пользователей и так далее. Или даже технологии LAMP. Но никто не объясняет, как защитить эти данные, не требуя входа какого-либо пользователя.

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

Разница между ВОЗ и ЧТО получает доступ к серверу API

Я написал серия статей об API и безопасности для мобильных устройств, а также из статьи Зачем вашему мобильному приложению нужен ключ API? Я процитирую следующее:

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

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

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

Так что, на мой взгляд, многие Разработчики не знают об этой разнице между Кто и Что в запросе, поэтому они концентрируются на решениях для Кто .

Возможные решения

Итак, как мне защитить описанные выше маршруты publi c api в моем бэкэнд-приложении. И как это делают крупные организации, такие как Facebook, Google, LinkedIn и др. c.

В этих организациях используются очень сложные решения UBA, которые могут быть недоступны для каждой организации с точки зрения стоимости или из-за того, что они являются проприетарными, но существуют и другие решения, и вы можете прочитать раздел Защита сервер API на этот другой ответ Я задал вопрос secure api data from calls out of the app, чтобы понять, как можно постепенно повысить безопасность сервера API для веб-приложения.

Если вы Также необходимо защитить сервер API для запросов от мобильного приложения, затем вы можете заблокировать его с очень высокой степенью доверия к своему мобильному приложению, используя концепцию аттестации мобильных приложений, и вы можете прочитать больше об этом в этот ответ Я дал на вопрос Как обезопасить API REST для мобильного приложения? .

Хотите Go лишнюю милю?

Я не могу закончить sh любой ответ на секретный вопрос без ссылки на превосходную работу от фонда OW ASP.

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

OW ASP Топ 10 веб-рисков

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

Руководство по тестированию веб-безопасности :

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

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

OW ASP Проект Mobile Security - 10 основных рисков

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

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

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

Для APIS

OW ASP API Security Top 10

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

0 голосов
/ 19 апреля 2020

Большую часть времени я видел API, защищенные через Basi c Auth или OAuth. Когда вы используете Basi c Auth, вы отправляете заголовок авторизации с именем пользователя и паролем в кодировке base64. Заголовки зашифрованы при подключении по HTTPS / SSL.

OAuth немного задействован, но следует аналогичной идее. Ваш токен OAuth также отправляется через зашифрованные заголовки. Вы можете прочитать больше об OAuth здесь: https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

...