Всем привет, меня зовут Юрий Шабалин, я один из основателей компании Stingray Technologies (входит в группу компаний Swordfish Security), мы занимаемся разработкой платформы анализа безопасности мобильных приложений iOS и Android. Этой статьей я хотел бы открыть серию материалов, посвященных мобильной безопасности.
И сегодня мы поговорим об уязвимостях, с которыми мы чаще всего сталкиваемся при автоматическом анализе.
Оглавление
Введение
Все написанное ниже во введении является личным мнением автора и может не совпадать с действительностью! Мобильные приложения, которые мы знаем и привыкли видеть, лично для меня начинают свою историю примерно с 2008 года, а именно с выходом iPhone 4, а позже и Android 4 (2012).Именно тогда появилась операционная система iOS (ее переименовали в iPhone OS).
По сравнению с веб-приложениями (я бы предположил, что начало современной сети относится к 1995 году, с появлением JavaScript), мобильная экосистема — довольно молодая технология.
Но он очень динамичен, развивается сумасшедшими темпами и завоевывает все большую популярность среди пользователей.
По сути, мобильный телефон или планшет — это практически полная замена ноутбука или компьютера (по крайней мере, для повседневных задач).
И, если посмотреть статистику использования мобильных банков в сравнении с их веб-версиями, то можно увидеть, что уже несколько лет назад количество активных пользователей мобильных клиентов превысило этот показатель для веб-версий и разрыв между ними становится все больше.
все шире и шире (по День стратегии Тинькофф 2018 ) 
Статистика активных пользователей мобильных и веб-банков по данным Тинькофф (2018).
И, на самом деле, я не помню, когда мне в последний раз приходилось заходить в личный кабинет с компьютера.
Да и зачем, если телефон всегда под рукой и то же самое (а иногда и больше) я могу сделать с помощью удобного мобильного приложения.
Тот факт, что иногда мобильные приложения превосходят по функциональности веб-версии, определяется их более динамичным развитием и особенностями процесса разработки.
Довольно часто мы сталкиваемся с тем, что мобильные приложения создаются немного в стороне от основной бэкенд- и фронтенд-разработки (а иногда даже вне инфраструктуры компании или даже на аутсорсе).
И это оправдано, ведь классическая цепочка CI/CD для обычного приложения выглядит примерно так:
- Разработчик фиксирует код
- Инструмент CI собирает новую версию дистрибутива и помещает ее в репозиторий.
- Инструмент CD берет этот дистрибутив и выкатывает его на стенд.
- Вот, собственно и всё — новая версия доступна всем тестировщикам для проведения автоматических и интеграционных тестов.
Как правило, тестировщики вручную тестируют приложения на реальных устройствах, а это значит, что приложение нужно каким-то образом доставить на эти телефоны.
Вот тут-то и приходят на помощь удобные системы дистрибуции, такие как Firebase, TestFlight, AppCenter и другие (кстати, интеграция с большинством этих систем поддерживается нашей системой ).
Все эти решения облачные, и работать с ними по обычной схеме гораздо удобнее, чем по закрытой (это актуально для компаний, где нет прямого доступа в Интернет).
Все эти нюансы и особенности делают разработку мобильных приложений независимой от цикла выпуска остальных компонентов системы (конечно, вплоть до появления нового функционала или изменений в API), и позволяют выпускать их так часто, как хотелось бы.
возможный.
По своему опыту скажу, что у крупных компаний может быть всего 4-5 релизов в год, особенно для крупных платформ, а для мобильных приложений удается выпускать 2-3 обновления в месяц.
В разных организациях эти цифры могут различаться, но, как правило, мобильные приложения все равно выпускаются чаще.
И, скорее всего, раз мобильные приложения такие молодые и быстро развивающиеся, то и с безопасностью все должно быть на одном уровне, а детские болезни давно позади? Давайте поговорим об этом немного подробнее.
Еще раз об OWASP Mobile
Чтобы систематизировать и систематизировать информацию об уязвимостях, их типах и классах, мы привыкли использовать различные стандарты и требования.Методика и классификация OWASP (а в нашем случае OWASP Mobile) — одна из самых популярных и общепринятых практик.
Для мобильных приложений OWASP имеет несколько основных документов, которые охватывают требования безопасности для мобильных приложений ( МАСВС - Стандарт проверки безопасности мобильных приложений).
Как проверить эти требования, описано в МСТГ - Руководство по тестированию мобильной безопасности.
Топ-10 мобильных устройств OWASP — десять самых распространенных проблем безопасности в мобильных приложениях.
О самом стандарте и связанных с ним материалах написано множество статей, на их основе составлено не один отчет, на них часто ссылаются в различных методологиях или отчетах.
Подробно рассматривать сам документ нет смысла, но важно обратить внимание на один момент. У OWASP Mobile Top 10 было всего 2 релиза, в 2014 и 2016 годах.
То есть мы все ссылаемся на классификацию, которой на момент написания статьи уже 6 лет! При этом OWASP Top 10 — аналогичный список проблем безопасности, но для веб-приложений — постоянно пополняется новыми типами атак, регулярно обновляется с точки зрения классификации и изменяется.
Последняя версия этой классификации датируется 2021 годом и в целом она пересматривается примерно раз в 2-3 года.
И здесь, с моей точки зрения, возникает некий парадокс: почему для более молодых технологий, для более динамичных и активно развивающихся мобильных приложений классификация остается нетронутой в течение шести лет, а для веб-приложений она меняется каждые несколько лет? Да, веб-приложения тоже развиваются, но, на мой взгляд, мобильная экосистема пока немного активнее.
Но, даже если предположить, что они меняются одновременно или Сеть меняется немного быстрее, то чем вызвана такая разница? Только проанализировав все свои выводы по анализу мобильных приложений, просмотрев десятки отчетов по различным инструментам и, конечно, проведя сотни приложений через Stingray, я понял, что все уязвимости из списка 2016 года по-прежнему актуальны.
И тут возникает следующий вопрос: так ли удачно компиляторы попали в точку со списком уязвимостей или все так плохо с безопасностью мобильных приложений? Однозначного ответа нет, но думаю такое положение дел является следствием нескольких вероятных причин:
- Во-первых, сегодня у многих магазинов, детских клубов, кафе и так далее есть мобильное приложение.
Соответственно, разработка идет очень активно, и выпустить свое приложение иногда гораздо проще и быстрее, чем, например, запустить веб-ресурс.
- Во-вторых, мобильные приложения появляются чаще, и их сложнее проверить.
Более того, проанализировать каждый релиз вручную без специальных инструментов практически невозможно.
- В-третьих, компании зачастую не уделяют должного внимания безопасности мобильных приложений, полагая, что финансовые потери в случае взлома будут незначительными.
Однако они забывают о репутационных рисках, возможных проблемах из-за нарушения требований законодательства, а также не думают, что мобильное приложение — это первая линия защиты перед тем, как данные попадут на бэкенд.
Наиболее распространенные категории уязвимостей
Небезопасное хранение данных
Одной из самых популярных проблем безопасности является небезопасное хранение конфиденциальных данных.
Под термином конфиденциальная информация или конфиденциальные данные я подразумеваю любую информацию, которая может позволить злоумышленнику построить вектор атаки против пользователя.Почему-то считается, что если данные сохраняются во внутренней песочнице (в каталоге, к которому имеет доступ только приложение), то они уже защищены.Это могут быть данные аутентификации пользователя (пароли, файлы cookie и т. д.), токены для доступа к сторонним ресурсам, личная информация (номер телефона, ФИО, паспортные/контактные данные) и т. д.
Но на самом деле это совершенно не так.
Существует большое количество способов получения этих данных, начиная от банальных локальных или облачных резервных копий приложения, ряда уязвимостей, позволяющих читать внутренние файлы приложения, и заканчивая попаданием в руки злоумышленников в результате потери или кражу устройства.
Чтобы было интереснее читать, я расскажу о реальных находках в приложениях, которые мы анализировали за последний год (конечно, не обо всех, так как их очень много).
Эту категорию я бы разделил на три больших направления — хранение учетных данных, хранение информации для авторизации на сторонних ресурсах, хранение другой конфиденциальной информации.
Сначала поговорим о первой категории — хранении учетных данных.
Хранение учетных данных
Иногда вы сталкиваетесь с чем-то, что заставляет ваш глаз дергаться.Например, в одном финтех-приложении, которое мы тестировали перед его выпуском в магазины приложений (и очень хорошо, что это произошло), был проверен ПИН-код пользователя, который он установил для аутентификации.
локально (то есть бэкенд приложения не участвовал в процессе проверки) и хранился в открытом виде в SharedPreferences (речь идет об Android-приложении).
Механизм хранения данных в SharedPreferences — это удобный способ работы с XML-файлами внутри каталога приложения.То есть ПИН-код фактически находился в каталоге приложения в открытом виде в обычном xml-файле.
Хранение пин-кода в открытом виде Как можно было сделать по-другому? Начнем с того, что не следует проводить проверки локально.
Если вообще этого избежать нельзя, то нужно это делать только с помощью биометрии (и обязательно не привязкой к событиям, а для доступа к ключам в Keystore/Security Enclave) для расшифровки значения в тех же общих настройках, например так :
- Генерируем ключ, доступный только через биометрию:
Теги: #информационная безопасность #iOS #Android #Разработка мобильных приложений #безопасность #Тестирование мобильных приложенийgenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, KEYSTORE); generator.init(new KeyGenParameterSpec.Builder (KEY_ALIAS,
-
Коллекция Gif: Каково Быть Предпринимателем
19 Oct, 24 -
Пользователи Twitter В Русской Википедии
19 Oct, 24 -
Нло: Вторжение Инопланетян
19 Oct, 24
