Предположения
Как защитить мой бэкэнд от доступа других неавторизованных интерфейсных приложений?
Под интерфейсными приложениями я предполагаю, что вы имеете в виду как мобильные, так и веб-приложений, и как только я разбираюсь в мобильных приложениях и безопасности API, я сосредоточусь на мобильных приложениях, но я дам вам несколько указателей на веб-приложения.
ИСТИНА О КРУПЕ
Я погуглил и не смог найти решение, которое дало бы полное решение.
Позвольте мне сказать вам жестокую правду, потому что она не существует. То, что существует, это глубокая защита, когда вы наносите столько слоев, сколько можете себе позволить, чтобы защитить свой бэкэнд.
РАЗНИЦА МЕЖДУ КТО И ЧТО ДОСТУПАЕТ К ВАШЕМУ ОБРАТНОМУ
Это распространенное мнение среди Разработчикам, которые используют https в сочетании с аутентификацией пользователя, будь то с поставщиками OAUTH, вашими собственными реализациями JWT или с традиционными сеансами и файлами cookie, достаточно для защиты серверной части от несанкционированного доступа, но это далеко не на 100% эффективно, потому что Начнем с того, что аутентификация пользователя определяет только WHO , который обращается к бэкэнду, а пользователь, а не WHAT , обращается к нему.
Вы можете думать о WHAT как ваше подлинное приложение выполняет запрос от имени ВОЗ , как вы думаете, даже если вы предоставляете действительный токен? Или это запрос от автоматического скрипта с украденным токеном или от такого инструмента, как Почтальон? Вы можете прочитать больше о этом разделе статьи, которую я написал о ключах API.
ОБРАТНАЯ ИНЖИНИРИНГ МОЖЕТ БЫТЬ ЛЕГКО, ЧЕМ ВЫ ХОТИТЕ
Я прочитал, что ключи SSL можно найти путем обратного инжиниринга интерфейса.
Если front-end - это веб-приложение, поэтому найти какой-либо секрет в нем просто, просто нажмите F12, чтобы получить доступ к инструментам разработчика в браузере, или щелкните правой кнопкой мыши, чтобы просмотреть исходный код страницы.
Если front-end мобильное приложение, тогда некоторые разработчики могут подумать, что они в безопасности, потому что мобильное приложение выпущено в виде двоичного файла, но это ложное чувство безопасности, потому что существует множество инструментов для выполнения бинарного анализа stati c их, и вы можете прочитать эту другую статью Я написал, чтобы понять, как использовать Mobile Security Framework для извлечения ключа API из двоичного файла мобильного приложения.
Если stati c двоичного анализа недостаточно, чем в устройствах, у которых злоумышленник имеет контроль, он может выполнить атаку MitM (Человек посередине), где он перехватывает все коммуникации между приложение и серверная часть. У меня есть статья о MitM в контексте мобильного приложения, о которой вы можете прочитать больше о здесь , где вы узнаете, как украсть ключ API с помощью инструмента с открытым исходным кодом mitmproxy или они могут прибегнуть к более продвинутому подходу, подключив инструментарий инструментария во время выполнения, например Frida :
Внедрить свои собственные сценарии в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите Сохранить и мгновенно увидите результаты. Все без шагов компиляции или перезапусков программы.
КАК БОЛЬШИЕ ЗАЩИЩАЮТ СВОИ ОБРАТЫ
Как такие компании, как Instagram и Facebook блокируют несанкционированные запросы?
Они будут использовать какие-то краткосрочный токен или другой механизм для идентификации пользователя, но, как я уже упоминал, это только для идентификации WHO в запросе. Чтобы они знали, ЧТО выполняет запрос, они могут прибегнуть к машинному обучению и искусственному интеллекту для выполнения пользовательской аналитики поведения (UBA) для входящих запросов, чтобы обнаружить необычное поведение человека и заблокировать его, и вы можете подробнее в Википедии :
Анализ поведения пользователей (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества. Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы. [1] Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.
Поскольку вы можете читать UBA, отслеживает людей, другими словами, WHO в запрос. Они делают это, пытаясь различить guish между WHO и WHAT выполняет запрос, и, как вы, возможно, думаете, это склонно к ложным срабатываниям, тем самым правила в политиках, применяемых в этих типах систем, должны учитывать это.
ВОЗМОЖНЫЕ РЕШЕНИЯ
Я новичок и создаю социальную сеть для проекта. Пожалуйста, помогите мне .
Для веб-приложений
Хотя решения UBA склонны к ложным срабатываниям, они могут быть лучшими для серверной части, обслуживающей веб-приложение. Разрабатывать собственное решение UBA будет очень дорого, потому что оно требует много ресурсов, опыта и времени, а купить коммерческое решение может быть не по бюджету, поэтому лучшая ставка может быть Google reCAPTCHA V3 :
reCAPTCHA v3 поможет вам обнаружить злоупотребления траффиком c на вашем сайте без вмешательства пользователя. Вместо того, чтобы показывать вызов CAPTCHA, reCAPTCHA v3 возвращает оценку, чтобы вы могли выбрать наиболее подходящее действие для вашего веб-сайта.
Для мобильных приложений
Для защиты бэкэнда API, обслуживающего мобильный телефон Приложение Я бы порекомендовал вам прочитать серию постов в блоге о Mobile API Security , где вы увидите, как можно реализовать и обойти несколько защит, например токены OAUTH JWT, и прочитать эту другую серию. постов в блоге, которые покажут вам вымышленное приложение и вымышленного злоумышленника, побеждающего ключи API, токены OAUTH JWT и запросы, подписанные с помощью HMA C.
Для серверной части мобильного приложения лучший подход защитить его от неавторизованных запросов - это использовать решение для аттестации мобильных приложений, которое вкратце позволит бэкэнду идентифицировать ЧТО выполняет запрос без необходимости отправки какого-либо секрета в приложение. , как традиционные ключи API, и я go более подробно о роли мобильного телефона p Аттестация в этом разделе статьи о закреплении сертификата, где вы можете прочитать:
Роль службы аттестации мобильных приложений заключается в аутентификации what отправляет запросы, таким образом, только отвечая на запросы, исходящие от подлинных экземпляров мобильного приложения, и отклоняя все остальные запросы от неавторизованных источников.
Для того, чтобы узнать что отправляет запросы на сервер API служба аттестации мобильных приложений во время выполнения с высокой степенью уверенности определит, что ваше мобильное приложение присутствует, не было взломано / переупаковано, не запущено на корневом устройстве, не было подключено инструментарием (Frida). , xPposed, Cydia, et c.), и не является объектом «Человек в средней атаке» (MitM). Это достигается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, для подтверждения целостности мобильного приложения и устройства, на котором оно работает.
При успешной проверке целостности мобильного приложения выдан кратковременный токен JWT, подписанный секретом, который известен только облачному API-серверу и службе аттестации мобильных приложений в облаке. В случае неудачной аттестации токен JWT подписывается с неверным секретом. Поскольку секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно выполнить обратный инжиниринг его во время выполнения, даже если приложение было взломано, запущено на корневом устройстве или обменивается данными через соединение это цель атаки MitM.
Мобильное приложение должно отправлять токен JWT в заголовке каждого запроса API. Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить, что токен JWT был подписан общим секретом и срок его действия не истек. Все остальные запросы будут отклонены. Другими словами, действительный токен JWT сообщает серверу API, что то, что делает запрос, является подлинным мобильным приложением, загруженным в магазин Google или Apple, в то время как неверный или отсутствующий токен JWT означает, что what делает запрос не авторизованным, потому что это может быть бот, переупакованное приложение или злоумышленник, выполняющий атаку MitM.
Большим преимуществом использования службы аттестации мобильных приложений является ее проактивная и модель положительной аутентификации, которая не создает ложных срабатываний и, таким образом, не блокирует легитимных пользователей, в то же время удерживая плохих парней на расстоянии
ПОЛУЧЕНИЕ ДОПОЛНИТЕЛЬНОЙ МИЛИ
В вопросах безопасности я всегда хотел бы закончить, порекомендовав отличную работу от OW ASP:
Web Security Руководство по тестированию
Руководство по тестированию веб-безопасности OW ASP включает в себя инфраструктуру тестирования на проникновение «передовой опыт», которую пользователи могут внедрить в своих организациях, и руководство по тестированию на проникновение «низкого уровня», которое описывает методы тестирования наиболее распространенных проблем безопасности веб-приложений и веб-служб.
Руководство по тестированию безопасности мобильных устройств
Руководство по тестированию безопасности мобильных устройств (MSTG ) представляет собой всеобъемлющее руководство по разработке, тестированию и реверс-инжинирингу безопасности мобильных приложений.