OAUTH TOKENS ДЕЙСТВИТЕЛЬНО ОНИ ДОСТАТОЧНО ЗАЩИЩАЮТ ВАШЕ ОБРАТНО? , Позволяет получить доступ к любому запросу, который представляет действительный токен OAuth, не только авторизованным пользователям. Это обычное заблуждение среди разработчиков, потому что токен OAuth представляет только , кто находится в запросе, а не , что делает запрос, и я обсудил это более подробно в эта статья , где вы можете прочитать: Что - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряет ваш сервер API с помощью такого инструмента, как Postman? who пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2. Статья написана в контексте мобильного приложения, но концепция то же самое для mobile app и web app с точки зрения разницы между , кто и , что делает запрос к внутреннему серверу. НЕСАНКЦИОНИРОВАННО ИСПОЛЬЗОВАНИЕ BACKEND
Но я могу получить доступ к API бэкэнда для несанкционированного использования, например
Я надеюсь, что теперь вы поняли, что это не только ваши маршруты к /register и /login, которым грозит насилие, потому что в данный момент вы знаете только , кто делает запрос, а не что делает его.
Маршруты : (/ register) или (/ login) без какого-либо ключа API.
Даже если у вас есть ключ API на этих маршрутах, это не предотвратит злоупотребление им для атак с использованием наполнения учетными данными.
Почему вы можете спросить?
Что ж, в веб-приложении все, что нужно для извлечения ключа API, - это нажать F12, чтобы открыть вкладку инструментов разработчика и найти ее, или просмотреть Источник страницы.
Теперь вы можете подумать, о, но в моем мобильном приложении это было бы невозможно, потому что это бинарный файл, и я даже использую запутывание. Хотя быть немного сложнее, не сложно, потому что существует множество инструментов с открытым исходным кодом, чтобы помочь с задачей.
Обратное проектирование
Вы можете использовать такой инструмент, как MobSF провести обратный инжиниринг любого двоичного файла мобильного приложения и извлечь из него ключ API или любой секретный ключ. Я написал статью Как извлечь ключ API из мобильного приложения от Stati c Двоичный анализ , за которым вы можете следовать на практическом примере, а также демонстрирует несколько способов скрыть API введите мобильное приложение с помощью Android Hide Secrets репозитория от Github.
MobSF :
Mobile Security Framework (MobSF ) - это автоматизированное универсальное мобильное приложение (Android / iOS / Windows), предназначенное для тестирования пера, анализа вредоносных программ и оценки безопасности, способное выполнять статический c и динамический c анализ.
Если вы не можете извлечь ключ API с помощью анализа stati c, тогда вы можете прибегнуть к динамическому анализу c с инструментами с открытым исходным кодом, например Frida :
Внедрение собственных сценариев в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите Сохранить и мгновенно увидите результаты. Все без шагов компиляции или перезапусков программы.
Frida позволит во время выполнения украсть ваши токены OAuth и отправить их на управляющие серверы злоумышленников, откуда они могут затем повторно использовать его для запуска автоматических атак на ваш бэкэнд, которые будут доверять им git, потому что who в запросе действителен.
Другой способ украсть ключ API или даже токены OAuth - выполнить атаку Man in the Middle (MitM) с помощью других инструментов с открытым исходным кодом, таких как mitmproxy :
Интерактивный перехватывающий HTTP-прокси с поддержкой TLS для тестировщиков проникновения и разработчиков программного обеспечения.
Поэтому, когда злоумышленник использует mitmproxy для перехвата запроса, выполняемого бэкэнду, он увидит что-то вроде этого:
Изображение взято из статьи: Украсть этот ключ API у Атаки Человек в середине
Вы заметили, что URL-адрес находится в https и содержит ключ API?
Итак, до сих пор вы думали, что https было достаточно для защиты связи между клиентами и сервером?
ЧТО ВЫ ХОТИТЕ
Что я хочу:
У меня есть два приложения веб-интерфейса.
Android Собственное мобильное приложение. Приложение внешнего интерфейса Nuxt SPA
Мой API должен работать только с этими интерфейсами. Никакой другой запрос почтальона или браузера не должен проходить и, вероятно, должен отображать неподдерживаемые платформы json msg.
Веб-приложения
Из-за характера того, как Веб был построен, но бэкэнд не может с высокой степенью достоверности определить, что делает запрос для любого типа веб-приложения, будь то SPA или традиционные.
Лучшее, что вы можете сделать, - это применить User Behavior Analytics (UBA) , чтобы сообщить appart , кто и , что такое доступ к вашему бэкэнду:
Анализ поведения пользователей (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества. Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы. [1] Вместо отслеживания устройств или событий безопасности UBA отслеживает пользователей системы.
Хорошим примером использования решения UBA является использование Google Recaptcha V3 :
reCAPTCHA - это бесплатный сервис, который защищает ваш сайт от спама и злоупотреблений. Он использует передовые методы анализа рисков, чтобы отличать людей и ботов друг от друга.
Это склонно к ложным срабатываниям, поэтому вы должны быть осторожны при принятии решения принять или нет запрос на основе оценки возвращается reCPATCHA V3 для каждого запроса:
reCAPTCHA v3 возвращает оценку для каждого запроса без трения пользователя. Оценка основана на взаимодействиях с вашим сайтом и позволяет вам предпринять соответствующие действия для вашего сайта.
Для мобильных приложений
К настоящему времени вы уже знаете, что токен OAuth для идентификации вашего пользователя не настолько «безопасен», как вы делали изначально, поскольку он только идентифицирует who в запросе, а не , что делает, и, как вы также видели по множеству инструментов, доступных для обратного инжиниринга мобильных приложений, токен OAuth всегда с угрозой кражи и злоупотребления со стороны неавторизованных клиентов.
Мобильное приложение, которое может позволить вашему бэкэнду быть уверенным в том, что запрос действительно поступил из того же мобильного приложения, которое было загружено в магазин Google Play. Решение для аттестации, и это концепция, которая представляет новый подход к обеспечению безопасности для вашего мобильного приложения и серверной части унифицированным способом.
Обычные решения ориентированы в основном на само мобильное приложение, но в первую очередь данные, которые вы хотите защитить, находятся на вашем внутреннем сервере, и именно здесь вы хотите иметь механизм, который знает, что
Концепция аттестации мобильных приложений описана в этом разделе другой статьи, которую я написал, откуда делает запрос - это действительно то, что вы ожидаете. Я процитирую следующий текст:
Роль службы аттестации мобильных приложений состоит в том, чтобы аутентифицировать то, что отправляет запросы, таким образом, только отвечая на запросы, исходящие из подлинных экземпляров мобильного приложения, и отклоняя все другие запросы из неавторизованных источников.
Для того, чтобы узнать Что касается отправки запросов на сервер API, служба аттестации мобильных приложений во время выполнения идентифицирует с высокой степенью уверенности в том, что ваше мобильное приложение присутствует, не было подделано / переупаковано, не запущено на корневом устройстве, не имеет был зацеплен инструментарием (Frida, xPposed, Cydia и др. c.) и не является объектом «Человек в средней атаке» (MitM). Это достигается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, для подтверждения целостности мобильного приложения и устройства, на котором оно работает.
При успешном подтверждении целостности мобильного приложения выдан кратковременный токен JWT, подписанный секретом, который известен только облачному API-серверу и службе аттестации мобильных приложений в облаке. В случае неудачной аттестации токен JWT подписывается с неверным секретом. Поскольку секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно выполнить обратный инжиниринг его во время выполнения, даже если приложение было взломано, запущено на корневом устройстве или обменивается данными через соединение это цель атаки MitM.
Мобильное приложение должно отправлять токен JWT в заголовке каждого запроса API. Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить, что токен JWT был подписан общим секретом и срок его действия не истек. Все остальные запросы будут отклонены. Другими словами, действительный токен JWT сообщает серверу API, что запрос выполняет подлинное мобильное приложение, загруженное в магазин Google или Apple, в то время как недействительный или отсутствующий токен JWT означает, что то, что делает запрос, не авторизовано для этого. потому что это может быть бот, переупакованное приложение или злоумышленник, выполняющий MitM-атаку.
При таком подходе ваш сервер будет знать с очень высокой степенью достоверности что делает запрос, то же самое мобильное приложение, которое вы загрузили в Google Play, при условии, что токен JWT имеет действительную подпись и время истечения, и отклоняет все другие запросы как ненадежные.
РЕЗЮМЕ
Для веб-приложений ваша защита более ограничена, и, на мой взгляд, аналитика поведения пользователя в серверной части может быть лучшим вариантом для вас.
Для мобильных приложений существует огромное количество решений, но они сосредоточены на само мобильное приложение, оставляя сервер уязвимым для доверия запросам, которые имитируют * 12 30 * мобильное приложение, но с помощью решения для аттестации мобильных приложений бэкэнд может отличать запросы от подлинных мобильных и от поддельных.
ИДТИ НА ДОПОЛНИТЕЛЬНУЮ МИЛЮ
Теперь я хотел бы рекомендую отличную работу основания OW ASP:
Руководство по тестированию веб-безопасности :
Руководство по тестированию веб-безопасности OW ASP включает инфраструктура тестирования на проникновение «передовой опыт», которую пользователи могут внедрять в своих организациях, и руководство по тестированию на проникновение «низкого уровня», в котором описаны методы тестирования наиболее распространенных проблем безопасности веб-приложений и веб-служб.
Руководство по тестированию безопасности мобильных устройств :
Руководство по тестированию безопасности мобильных устройств (MSTG) - это всеобъемлющее руководство по разработке, тестированию и реверс-инжинирингу безопасности мобильных приложений.