Развитие цифровых мобильных приложений предполагает взаимодействие компании и ее клиентов, а также партнеров на основе удаленных служб с применением общеизвестных процедур обеспечения безопасности: аутентификации и авторизации, формирующие общую архитектуру мобильных приложений.
Почему этому вопросу при оценке безопасности необходимо уделять время? Несмотря на то, что значительная часть логики указанных двух процедур реализуется в конечных точках, существует ряд вопросов, возникающих на стороне мобильного приложения.
Так, при работе мобильного приложения часто используются токены аутентификации, которые позволяют обеспечивать для юзера возможность логирования на длительном промежутке времени и разблокировку при помощи различных средств биометрии (без использования сложных паролей), упрощающих использование приложений, но одновременно это и создает проблемы и приводит к ошибкам.
Необходимо также отметить, что при тестировании МП важным моментом является наличие в архитектуре приложений инфраструктуры авторизации. Так называемых протоколов авторизации (OAuth 2.0, поверхностный или дополнительный к OAuth 2.0 — OpenID Connect, WebAuthn, S AML 2.0, Credential Management API), позволяющие предоставлять права на доступ к ресурсам пользователя на другом сервисе.
Многие из указанных протоколов исключают необходимость доверять приложениям логин и пароль, а также позволяют предоставлять минимальный или необходимый набор прав.
Пользователи в своей жизнедеятельности используют мобильные устройства, систематически осуществляют подключения к другим ресурсам (включая сети Wi-Fi), которые используются другими юзерами, а их устройства могут быть заражены потенциальными вредоносными программами, что позволяет осуществлять воздействие на мобильные приложения, персональные данные и т.д.
В связи с этим, на первый план выходят действия, направленные на обеспечение конфиденциальности и целостности этих данных, которые пересылают между собой мобильные приложения, включая конечные точки сервисов. Поэтому мобильные приложения должны это осуществлять через безопасные каналы передачи данных с использованием протоколов безопасности типа SSL (Secure Sockets Layer — уровень защищённых сокетов) или TLS (Transport Layer Security — Протокол защиты транспортного уровня).
Важным вопросом при тестировании безопасности мобильного приложения является архитектура его операционной системы, которая имеет существенные отличия от ОС Android или iOS стационарных устройств.
Абсолютно все МП ОС реализуют системы разрешений приложений, которые регулируют доступы к определенным API (Application Programming Interface, представляющий набор методов (функций). Разработчики могут их использовать для организации доступа к функциональности программного компонента мобильного приложения (модуль, библиотека, хранилище).
Проще говоря, API определяет функциональность, которую предоставляет программа (модуль, библиотека и т.д.). При этом API позволяет не задавать таких вопросов, как именно эта функциональность реализована, т.е. фактически, это есть интерфейс, доступный юзеру, которые он может использовать и получать услуги. В рамках получения данного функционала и использования опций осуществляется межпроцессное взаимодействие (IPC), которое позволяет приложениям обмениваться сигналами и данными. В ходе данного процесса возникают свои айсберги и пороги, связанные с неправильным использованием IPC API, в результате чего, конфиденциальные данные или функции могут быть доступны иным приложениям, работающим в рамках конкретной платформы ОС. На это и должен быть направлен взор тестировщика безопасности МП.
Еще один из важных моментов безопасности МП являются недостатки исходного кода и ограничение использование вредоносных программ. По статистике обычно сложно встретить недостатки исходного кода, которые бы в массовом порядке могли оказать существенное влияние на безопасность (с учетом периметра для воздействия в контексте мобильного приложения). МБ (как правило) взаимодействуют с доверенными серверными службами и пользовательскими интерфейсами, в связи с этим наличие уязвимостей (например, как Buffer Overflow) не позволят осуществить воздействие с неким профитом для лица, его осуществляющего. Такое умозаключение уместно и в отношении эксплойтов браузера, таким как Cross-Site Scripting (тип воздействия на веб-системы, заключающийся во внедрении в страницу этой системы вредоносного кода, скриптов (которые могут быть выполнены мобильным устройством при открытии страницы). Вместе с тем всегда есть ситуации, которые развиваются не стандартно. Это же касается в указанной ситуации. Более подробно на теме тестирования исходного кода остановимся позднее.
В завершении можно сказать, что оценка (тестирование) безопасности мобильных приложений должна быть стандартной процедурой, осуществляемой разработчиками (если заказчики идут на повышенный риск, доверяя возможность проведения тестирования или оценки создателю) или заказчиками, путем осуществления независимой оценки или тестирования мобильных приложений, снижая уровень риска и устраняя конфликт интересов.
Тестирование может осуществляться (в зависимости от цели и условий использования МП) на основании международных методик (таких как OWASP (MASVS) либо национального стандарта (ТТП ИБ 8.1 – 2021, ТТП 2.1 – 2020), которые определяют различные модель безопасности мобильного приложения и содержат общие требования безопасности для мобильных приложений.
У национальной и международных практик имеется (примерный) алгоритм тестирования или оценки безопасности, согласно которому работает и наша компания:
