АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЯ НЕ АУТЕНТИФИКАЦИЯ ПРИЛОЖЕНИЯ
Таким образом, все конечные точки, требующие аутентификации пользователей, защищены ...
Эти конечные точки защищены только для идентификации , аутентифицируйте и авторизуйте Кто его в запросе, но не для Что делает запрос, и это топика c, не очень хорошо понятная среди разработчиков, будь то юниоры или пожилые люди.
Разница между ВОЗ и ЧТО обеспечивает доступ к серверу API
В написанной мною статье под названием Зачем вашему мобильному приложению нужен ключ API? вы можете прочитайте более подробно разницу между Кто и Что обращается к вашему API-серверу, откуда я цитирую следующее:
что - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем API-сервере с помощью такого инструмента, как Postman?
who - это пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
Таким образом, Who является пользователем вашего API сервер, на котором вы сможете аутентифицировать и авторизовать доступ к данным, а What - это программное обеспечение, выполняющее этот запрос от имени пользователя, вашего подлинного приложения, подделанного, автоматического сценария или кого-то другого вручную. работа с API через cURL, Postman или аналогичные инструменты.
Теперь я надеюсь, что у вас достаточно знаний, чтобы понять, почему аутентификация пользователя ( who ) не совпадает с аутентификацией приложения (*) 1041 * что ) аутентификация.
БЛОКИРОВКА СЕРВЕРА API НА ПРИЛОЖЕНИЯХ
Как я могу ограничить свои конечные точки API publi c (login & regis в настоящее время), который не требует, чтобы пользователи проходили аутентификацию (поскольку существуют конечные точки, используемые для выполнения этой миссии ...), которые будут использоваться только в моих доверенных клиентских приложениях (веб-и мобильных)?
Я думаю, что к настоящему времени вам может быть ясно, что не только конечные точки входа и регистрации должны быть защищены от Что делает запрос.
Как я могу запретить другому конечному приложению использовать другое приложение, разработанное другим человеком? Я не хочу, чтобы кто-либо входил через мой API, если это не сделано в клиентских приложениях, которые я разрабатываю ... Я не хочу, чтобы кто-либо копировал мои приложения и успешно использовал мой API таким образом с нулевой защитой, не зная об этом. ..
Этого чрезвычайно трудно достичь для веб-приложений, но возможно с высокой степенью уверенности для мобильных приложений при реализации концепции аттестации мобильных приложений.
Для веб-приложений
Из-за особенностей построения сети все, что необходимо для проверки веб-приложения, - это нажать F12 или проверить исходный код страницы, а затем найти то, что вам нужно для доступа к серверу API из другого инструмента. .
Вы можете изучить некоторые полезные приемы, которые помогут вашему API-серверу пытаться отвечать только на запросы, поступающие от Что вы ожидаете , ваше подлинное веб-приложение, и для этого я приглашаю вас прочитайте мой ответ на вопрос Защитите данные API от вызовов из приложения , особенно раздел, посвященный Defendi нг сервер API .
Для мобильных приложений
Чтобы узнать, как заблокировать API-сервер для своего мобильного приложения, я рекомендую прочитать мой ответ на вопрос Как обезопасить API REST для мобильного приложения? для разделов Защита API-сервера и Возможное лучшее решение .
Конечные точки для защиты
Таким образом, все конечные точки, которые требуют аутентификации пользователей, защищены (если нет других рекомендаций по безопасности, о которых я не знаю?).
Вам решать, хотите ли вы только повысить безопасность своего логина и зарегистрировать конечные точки, но я советую вам повысить безопасность всех их в отношении обнаружения Что получает к ним доступ.
POSTMAN С HEROKU И ДРУГИМИ
Я вижу множество популярных сервисов с маршрутами API входа в систему (например, Heroku), которые не могут быть доступны в Postman с теми же параметрами (ошибка 403 код). Так что можно. Но как они это делают? На специализированных форумах нет ничего, что могло бы справиться с этим, или я что-то пропустил!
Я никогда не использовал Heroku, но когда я использую API, который не работает в Postman, но работает в других клиентах, давайте скажем из cURL, тогда я отключаю Postman от отправки его user-agent, и обычно API начинает принимать запросы.
Если нет, то они могут делать дактилоскопию устройства :
Отпечаток устройства или машинный отпечаток - это информация, собранная о программном и аппаратном обеспечении удаленного вычислительного устройства с целью идентификации. Информация обычно ассимилируется в краткий идентификатор с использованием алгоритма снятия отпечатков пальцев. Отпечаток пальца в браузере - это информация, собранная специально при взаимодействии с веб-браузером устройства.
Отпечатки пальцев можно выполнять в активном или пассивном режиме. В активном режиме некоторые Javascript выполняются на клиенте для сбора некоторых данных для отправки обратно на сервер API, в то время как в пассивном режиме он использует информацию, доступную из запроса на сервере, такую как заголовки http и параметры запроса.
Хотя это поднимает планку к фальсификации Что делает запрос, его можно обойти, посмотрев, как доверенный клиент отправляет запрос и mimi c. Для атакующего это всего лишь немного больше, чтобы перечислить все варианты и затем автоматизировать их.
ВЫ ХОТИТЕ GO ДОПОЛНИТЕЛЬНУЮ МИЛЮ?
Я действительно прочитал огромное количество тем и сообщений в блогах, посвященных защите REST API.
Прежде всего, я поздравляю вас с тем, что вы приложили столько усилий, чтобы научиться защищать свой API.
Не знаю, если вы уже прочитал некоторые ресурсы OW ASP, которые я собираюсь связать, но в любом ответе на секретный вопрос я всегда хотел бы сослаться на отличную работу из фонда OW ASP;)
для веб-приложений
OW ASP Топ 10 веб-рисков
OW ASP Top 10 - мощный информационный документ для безопасности веб-приложений. Он представляет широкий консенсус в отношении наиболее критических угроз безопасности для веб-приложений. В число участников проекта входят различные эксперты по безопасности со всего мира, которые поделились своими знаниями для составления этого списка.
Руководство по тестированию веб-безопасности :
Руководство по тестированию веб-безопасности OW ASP включает в себя инфраструктуру тестирования на проникновение «передовой опыт», которую пользователи могут внедрять в своих организациях, и руководство по тестированию на проникновение «низкого уровня», в котором описываются методы тестирования наиболее распространенных веб-приложений и безопасности веб-служб. проблемы.
для мобильных приложений
OW ASP Проект Mobile Security - 10 основных рисков
OW ASP Mobile Security Project - это централизованный ресурс, предназначенный для того, чтобы предоставить разработчикам и командам безопасности ресурсы, необходимые для создания и поддержки безопасных мобильных приложений. В рамках проекта наша цель состоит в том, чтобы классифицировать риски для безопасности мобильных устройств и обеспечить средства управления развитием, чтобы уменьшить их влияние или вероятность эксплуатации.
OW ASP - Руководство по тестированию мобильной безопасности :
Руководство по тестированию безопасности мобильных устройств (MSTG) - это всеобъемлющее руководство по разработке, тестированию и реверс-инжинирингу безопасности мобильных приложений.
Для APIS
OW ASP API Top 10
Проект безопасности API OW ASP стремится обеспечить ценность разработчикам программного обеспечения и оценщикам безопасности, подчеркивая потенциальные риски в небезопасных API и иллюстрируя, как эти риски могут быть смягчены. Для достижения этой цели проект безопасности API OW ASP создаст и будет поддерживать документ «Топ 10 угроз безопасности API», а также портал документации для рекомендаций по созданию и оценке API.