Компания Digital Security выпустила отчёт, в котором привела результаты своего исследования мобильных клиентов российских банков. Причём исследовались только бесплатные клиенты, которые работают под управлением операционных систем iOS и Android. Таких клиентов набралось 40, и для них были реализации для обоих операционных систем. Хотелось бы несколько слов сказать о используемой в отчёте терминологии - она, по моему мнению, не соответствует тому, что специалисты компании сделали.

В пояснении сказано, что проводился статистически анализ методом чёрного ящика. Этот термин нужно пояснить, поскольку в практике исследования метод исследования чёрного ящика предусматривает, что на вход изучаемого объекта подаются определённые сигналы, а по полученным реакциям делается вывод о свойствах объекта. Понятно, что такой анализ может быть только динамическим - исследуемый объект должен отреагировать на воздействие. В то же время в практике пентестов исследование методом чёрного ящика означает, что исследователь ни чего заранее не знает о объекте тестирования - все данные получаются в процессе тестирования. Конечно, для специалистов по проведению пентестов такой термин кажется вполне понятным, но для ИТ-специалистов в "статистическом анализе методом чёрного ящика" есть определенные противоречия.

Интереснее другой аспект - методика тестирования, приведенная в отчёте, подразумевает следующее: приложение изучили на предмет наличия в нём небезопасных компонент, и за каждую небезопасную библиотеку назначали штрафные очки. При этом совсем не сказано о том, проводилось ли реальное исследование возможности эксплуатации этой уязвимости. Наиболее показательным примером является наличие в клиенте встроенной базы SQLite. В отчёте явно предполагается, что если эта база используется, то приложение уязвимо для SQL-инъекций, хотя для того, чтобы внедрить свой код злоумышленник должен как минимум перехватить сессию связи и навязать клиентскому приложению свои данные. Понятно, что такая атака блокируется, например, использованием SSL с взаимной аутентификацией или хотя бы контролем целостности передаваемых сервером данных. В отчёте же совершенно нет сведений о том, какой процент из использующих SQLite не использует при этом SSL. В то же время указывается, что по меньшей мере 26 продукта шифруют канал связи.

Те же претензии можно предъявить к уязвимости доступа к файлам - если хранятся локальные данные, то получить к ним доступ может другое приложение. Однако не говорится о том насколько критичные данные хранятся в этих файлах. К тому же данные в них вполне могут шифроваться - исследования на этот счёт также явно не проводилось. Аналогично, и защита SSL - в отчёте явно предполагается, что если этот протокол не используется, то злоумышленник может вмешаться в работу системы, однако вполне возможно, что данные по открытому каналу передаются в шифрованном виде с криптографическим контролем целостности - вмешаться в такой сеанс не намного проще, чем в стандартный SSL. Такая же ситуация с уязвимостью XXE - внедрение посторонних XML-объектов в сеанс. Создаётся ощущение, что любое мобильное приложение, которое использует для обмена с сервером формат XML уже уязвимо, хотя обмен данными, вполне возможно, также был прикрыт SSL или другим механизмом контроля целостности - у злоумышленника просто не было возможности встроить свой XML в сеанс общения сайта с сервером.

Тем не менее, отчёт в целом полезен для отрасли. Хотя он и не выясняет конкретных уязвимостей, но только указывает разработчикам на отклонение от лучших практик: правильное использование SSL, контроль целостности передаваемой информации, использование правильных методов межпроцессорного взаимодействия, проверка на взлом защиты устройства, фильтрация посторонней информации в XML и ответах сервера. Хотя конкретных уязвимостей там не опубликовано, но есть стимул для разработчиков подобных мобильных клиентов позаботиться о использовании лучших практик по защите своего мобильного банкинга до того, как им заинтересуются профессиональные мошенники - тогда это будет делать уже поздно.