Я понимаю, что помещать строки подключения к БД с учетными данными, ключами API и т. Д. Действительно плохо, так как вы можете декомпилировать его, чтобы увидеть значения ...
ДА, это очень плохо в любом приложении, не важно, мобильное ли это, веб-приложение или приложение IOT.
Итак, все ли должно быть за API?
ДА, ваше приложение должно быть максимально тупым. Другими словами, код в вашем приложении должен быть максимально связан с представлением, любая бизнес-логика должна быть делегирована серверу API. Этот подход имеет огромное преимущество: в любое время, когда у вас есть ошибка, вам нужно только обновить сервер API, а не само приложение, и ждать, пока все клиенты обновят их на своих мобильных устройствах. В случае веб-приложений вы не хотите раскрывать свою бизнес-логику кому-либо, кто нажимает клавишу F12 в браузере и начинает отладку кода на панели инструментов разработчика.
Нужно ли размещать SQL-запрос за веб-службой или мы можем выполнить параметризованный запрос к хранимым процедурам, и это будет нормально?
Как я уже говорил ранее, приложение должно быть настолько глупым, насколько это возможно, и НИКОГДА не выполнять SQL-запросы от клиента к любому типу бэкэнда, в противном случае вы открываете огромную дыру в безопасности своей службы.
Все, что поступает со стороны клиента на ваш бэкэнд, должно рассматриваться как потенциально вредоносное, потому что даже если вы думаете, что WHO делает запрос, вы можете не знать ЧТО делает это. Для лучшего понимания разницы между WHO и WHAT обращается к вашему серверу, прочитайте эту статью в разделе, где вы видите эту картинку:
Короче говоря, WHO означает пользователя, а WHAT означает приложение / устройство, выполняющее запрос, и, как показывает изображение, злоумышленник может изменить его. Человек в середине атаки.
Я предполагаю, что это также должно быть за веб-службой и просто возвращать что-то вроде массива JSON и т. Д.
Json является наиболее используемым форматом для возврата ответов от API, потому что он легко читается людьми и машинами, но существуют и другие форматы.
На самом деле я не видел ни одного контрольного списка того, что не стоит оставлять за веб-сервисом для мобильного приложения.
Хотя запрашиваемый вами список может не существовать, поскольку он слишком широк, вы можете начать с избегания OWASP Mobile Security Project - 10 основных рисков в вашем мобильном приложении.
Я пришел с позиции веб-разработки, так что до сих пор это не было проблемой.
Хотя вы можете не использовать ключи API в своем веб-приложении, если вы выполняете SQL-запросы от них, вы рискуете ввести SQL-код, наиболее распространенный риск, который присутствует в любом приложении, работающем в Интернете, что продолжает оставаться на первой позиции в OWASP Top 10 - 2017 (pdf).
Нужно ли нам запускать наши приложения через веб-сервис
ДА, вам нужно запускать мобильные приложения через сервер API.
и если да, то как мы можем тогда интегрировать веб-сервис с приложением, поскольку мы не можем сначала жестко закодировать ключ для веб-сервиса?
Как показано в статье Как извлечь ключ API из мобильного приложения с помощью статического двоичного анализа его можно извлечь с помощью нескольких инструментов с открытым исходным кодом, например, с помощью Mobile Security Framework , но вы также можете получить ключ API с помощью атаки MitM, как я покажу в статье Украсть этот ключ API с атакой Man in Middle , использующей инструмент с открытым исходным кодом MiTM Proxy .
Так что теперь ... Если я использую ключ API, его можно извлечь, но если я его не использую, я не смогу определить ЧТО делает запрос.
Теперь можно прибегнуть к использованию нескольких уровней защиты, начиная с reCaptcha V3 , затем Брандмауэр веб-приложений (WAF) и, наконец, если вы можете себе это позволить Решение для анализа поведения пользователей (UBA).
Google reCAPTCHA V3 :
reCAPTCHA - это бесплатная служба, которая защищает ваш сайт от спама и злоупотреблений.reCAPTCHA использует усовершенствованный механизм анализа рисков и адаптивные задачи, чтобы автоматизированное программное обеспечение не использовалось для злоупотреблений на вашем сайте.Он делает это, позволяя вашим действительным пользователям легко проходить через него.
... помогает вам обнаруживать оскорбительный трафик на вашем сайте без каких-либо проблем со стороны пользователей.Он возвращает оценку, основанную на взаимодействиях с вашим веб-сайтом, и предоставляет вам больше возможностей для принятия соответствующих действий.
WAF - брандмауэр веб-приложений :
Брандмауэр веб-приложений (или WAF) фильтрует, отслеживает и блокирует HTTP-трафик в веб-приложение и из него.WAF отличается от обычного брандмауэра тем, что WAF может фильтровать содержимое определенных веб-приложений, в то время как обычные брандмауэры служат в качестве шлюза безопасности между серверами.Проверяя HTTP-трафик, он может предотвратить атаки, связанные с недостатками безопасности веб-приложений, такими как внедрение SQL, межсайтовый скриптинг (XSS), включение файлов и неправильная конфигурация безопасности.
UBA -Аналитика поведения пользователя :
Аналитика поведения пользователя (UBA), как определено Gartner, представляет собой процесс кибербезопасности, связанный с обнаружением внутренних угроз, целевых атак и финансового мошенничества.Решения UBA рассматривают модели поведения людей, а затем применяют алгоритмы и статистический анализ для выявления значимых аномалий из этих моделей - аномалий, которые указывают на потенциальные угрозы.Вместо отслеживания устройств или событий безопасности, UBA отслеживает пользователей системы.Платформы больших данных, такие как Apache Hadoop, расширяют функциональность UBA, позволяя им анализировать данные объемом в петабайты для обнаружения внутренних угроз и расширенных постоянных угроз.
Все эти решения работают на основе модели отрицательной идентификации, другимислова, которые они стараются отличить плохое от хорошего, определяя, что плохо, а не что хорошо, поэтому они склонны к ложным срабатываниям, несмотря на передовые технологии, используемые некоторыми из них, такие как машинное обучение и искусственный интеллект.
Таким образом, вы можете чаще испытывать необходимость ослабить блокировку доступа к API-серверу, чтобы не влиять на хороших пользователей.Это также означает, что этим решениям требуется постоянный мониторинг для проверки того, что ложные срабатывания не блокируют ваших законных пользователей и в то же время они должным образом защищают неавторизованных пользователей.
В отношении API, обслуживающих мобильные приложения, положительная идентификацияМодель можно использовать с помощью решения для аттестации мобильных приложений, которое гарантирует серверу API, что запросы можно доверять без возможности ложных срабатываний.
Аттестация мобильных приложений
Использование аттестации мобильных приложенийРешение, позволяющее серверу API узнать, получает только запросы от подлинного мобильного приложения.
Роль службы аттестации мобильных приложений заключается в том, чтобы во время выполнения гарантировать, что ваше мобильное приложение не было взломано или не запущено.в рутированном устройстве, запустив SDK в фоновом режиме, который свяжется со службой, работающей в облаке, чтобы подтвердить целостность мобильного приложения и работающего устройства.
При успешной аттестации mobiДля обеспечения целостности приложения на короткий срок выдается токен JWT, который подписывается с секретом, о котором знают только сервер API и служба аттестации мобильных приложений в облаке.В случае сбоя при аттестации мобильного приложения токен JWT подписывается секретом, которого сервер API не знает.
Теперь приложение должно отправляться при каждом вызове API токеном JWT в заголовках запроса.Это позволит серверу API обслуживать запросы только тогда, когда он может проверить подпись и время истечения срока действия в токене JWT и отклонить их, если он не прошел проверку.
Как только секрет, используемый службой аттестации мобильных приложений, не являетсяизвестное мобильному приложению, невозможно выполнить его реинжиниринг во время выполнения, даже когда приложение подделано, работает на рутированном устройстве или осуществляет связь через соединение, являющееся целью для человека в средней атаке.
Сервис аттестации мобильных приложений уже существует в виде решения SAAS на Approov (я работаю здесь), который предоставляет SDK для нескольких платформ, включая iOS, Android, React Native и другие.Для интеграции также потребуется небольшая проверка кода сервера API для проверки токена JWT, выпущенного облачной службой.Эта проверка необходима для того, чтобы сервер API мог решать, какие запросы обслуживать, а какие отклонять.
Ответ на ваше резюме
Нужно ли нам создавать всевключающий веб-сервис с целью обмена между базой данных и клиентом приложения для Android, то же самое для любого стороннего API?
ДА, и вы всегда должны делегировать доступ к сторонним сервисам в любомкакое-либо приложение, мобильное, веб-приложение или приложение IOT, в противном случае у вас возникнут проблемы, когда злоумышленник получит учетные данные для доступа к ним и начнет использовать их от вашего имени, в то время как вы будете тем, кто оплачивает счет.
Кроме того, как мы разрешаем приложению для Android взаимодействовать с нашим веб-сервисом, поскольку целью этого веб-сервиса было прежде всего предотвращение жесткого кодирования ключей?
Здесь лучше всего подходит решение для аттестации мобильных приложений.
В заключение
Все, что работает на стороне клиента и нуждается в секрете для доступа к API, может быть использовано по-разному, ивы должны делегировать доступ ко всем сторонним API-интерфейсам подконтрольному бэкэнду, чтобы уменьшить поверхность атаки и одновременно защитить их секреты от посторонних глаз.
В конце концов, решениеиспользование для защиты вашего API-сервера должно быть выбрано в соответствии со значением того, что вы пытаетесь защитить, и с юридическими требованиями к данным такого типа, например, с правилами GDPR в Европе.