Я не прав? Это глупый вопрос?
Нет, вы не ошиблись, и это совсем не глупый вопрос, потому что действительно легко атаковать сервер API мобильного приложения, и вы будете удивлены Я знаю, сколько старших разработчиков не знают, как легко это сделать, и я заметил, что чаще всего это происходит из-за их неправильного представления о , что против , кто получает доступ к Сервер API.
Разница между чем и , кто обращается к серверу API.
Это более подробно обсуждается в this статью я написал, где мы можем прочитать:
what - это то, что делает запрос к серверу API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, который вручную ковыряет ваш сервер API с помощью такого инструмента, как Postman?
who - это пользователь мобильного приложения, которое мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
Так что, если цитируемого текста недостаточно для разъяснения вас, тогда, пожалуйста, go вперед и прочитайте весь раздел статьи.
Олицетворение мобильного приложения
В этом запросе я нашел много ключей авторизации, которые я могу использовать в других вызовах из консоли, без проблем симулируя приложение.
Если под auth keys вы подразумеваете те, которые предоставляют через вход пользователя, с его именем пользователя и паролем, то они просто идентифицируют who в запросе.
Для других ключей, таких как api-keys, acess-tokens или любых других соглашений, используемых для их имен, они имеют целью предоставить серверу API механизм только для авторизуйте запросы от подлинного мобильного приложения, они действительно пытаются позволить серверу API определить , что делает запрос, и вы уже обнаружили, что их легко извлечь с помощью прокси:
Несмотря на то, что вы используете SSL, «обычно легко» взломать мобильные приложения (я думаю, что в Android прямо сейчас: декомпиляция приложения, изменение манифеста, чтобы разрешить пользовательский SSL, повторная компиляция и сниффинф через прокси SSL все запросы).
Итак, в конце концов, все, что нужно атакующему, - это использовать прокси-сервер, чтобы узнать, как работает сервер API, и что необходимо для имитации вызова API, как если бы он был сделано из самого мобильного приложения.
Защита API-сервера
Итак, теперь я взломал некоторые API в мобильных приложениях, мой вопрос: есть ли способ защитить API в мобильном приложении?
Вы можете использовать решения Mobile Hardening and Shielding, которые попытаются помешать мобильному приложению работать на скомпрометированных / рутированных устройствах с мо различные / несанкционированные приложения и / или когда некоторая инструментальная среда используется во время выполнения, но у всех них есть недостаток в выполнении всех этих решений в мобильном приложении, поэтому они могут быть манипулированы или полностью обойдены инфраструктурой инструментария alreay dito И хороший пример того, что это Frida :
Внедрение собственных сценариев в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите Сохранить и мгновенно увидите результаты. Все без шагов компиляции или перезапусков программы.
Хотя лучше использовать внутриигровое решение, чем ничего не использовать, оно все же не идеальное решение, поскольку контроль решения о том, что делать, находится на стороне клиента, а не на стороне сервера. .
Возможное лучшее решение
Текущие реализации мобильного приложения и сервера API могут выглядеть следующим образом:
Этот подход что делает ключи API уязвимыми для извлечения злоумышленниками через перехват прокси (красная линия), как вы уже заметили, используя прокси для их перехвата.
Лучшим подходом было бы что-то вроде этого:
Подождите, но я не вижу больше ключа API в мобильном приложении:
Я что-то упустил?
Да, решение для аттестации мобильных приложений.
Чтобы быть в состоянии, когда вам не нужно передавать какие-либо секреты с вашим мобильным приложением затем вам нужно прибегнуть к концепции аттестации мобильных приложений, и из этого раздела статьи я процитирую соответствующие части, чтобы объяснить его роль:
Роль мобильного приложения Служба аттестации заключается в проверке подлинности того, что отправляет запросы, таким образом, только отвечая на запросы, поступающие из подлинных экземпляров мобильного приложения, и отклоняя все другие запросы из неавторизованных источников.
Для того, чтобы узнать что отправляет запросы на сервер API, служба аттестации мобильных приложений во время выполнения будет с высокой уверенностью определять, что ваше мобильное приложение присутствует, не было подделано / переупаковано, не работает в рутированном устройстве, не был подключен инструментальной средой (Frida, xPposed, Cydia и др. c.) и не является объектом Man in Middle Attack (MitM) . Это достигается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, чтобы подтвердить целостность мобильного приложения и устройства, на котором оно работает.
При успешном подтверждении целостности мобильного приложения выдан токен JWT с коротким сроком действия, который подписан с секретом, известным только API-серверу и службе аттестации мобильных приложений в облаке. В случае неудачной аттестации токен JWT подписывается с неверным секретом. Поскольку секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно выполнить обратный инжиниринг его во время выполнения, даже если приложение было взломано, запущено на корневом устройстве или обменивается данными через соединение это цель атаки MitM.
Мобильное приложение должно отправлять токен JWT в заголовке каждого запроса API. Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить, что токен JWT был подписан общим секретным ключом и срок его действия не истек. Все остальные запросы будут отклонены. Другими словами, действительный токен JWT сообщает серверу API, что то, что делает запрос, является подлинным мобильным приложением, загруженным в магазин Google или Apple, в то время как неверный или отсутствующий токен JWT означает, что what делает запрос не авторизованным, потому что это может быть бот, переупакованное приложение или злоумышленник, выполняющий атаку MitM.
Большим преимуществом использования службы аттестации мобильных приложений является ее проактивная и модель положительной аутентификации, которая не создает ложных срабатываний и, таким образом, не блокирует законных пользователей, в то время как она удерживает плохих парней в страхе.
Аттестация мобильных приложений освобождает ваше мобильное приложение от наличия встроенного секрета в своем коде вместо этого теперь ему нужно только перейти на обратный прокси-сервер или серверный токен JWT, который он получает от службы аттестации мобильных приложений. Теперь обратный прокси-сервер или серверная часть могут проверять токен JWT, и при успешной проверке они могут принимать запросы с очень высокой уверенностью, что они исходят из того, что они ожидают, истинного и подлинного экземпляра мобильного приложения, с дополнительным преимуществом не предоставления ключей API для доступа к вашему API-серверу или любым сторонним сервисам.
ПОЛУЧЕНИЕ ДОПОЛНИТЕЛЬНОЙ МИЛИ
Я не могу закончить sh без Рекомендую вам отличную работу, проделанную в OW ASP - Руководство по тестированию мобильной безопасности :
Руководство по тестированию мобильной безопасности (MSTG) - это всеобъемлющее руководство по разработке безопасности мобильных приложений , тестирование и реверс-инжиниринг.