Техника информационной безопасности в разработке мобильных приложений

Павел Кузнецов, руководитель мобильной разработки DD Planet
Источник: Информационная безопасность

Только ленивый сегодня не настроил тач-пароль на своем мобильном устройстве и не подключил миллион верификаций, продолжая при этом бесстрашно загружать приложения из неофициальных источников и устанавливать чудо-расширения. Нередко такие истории завершаются взломанными аккаунтами и утечкой персональных данных. Реально оценивая ситуацию, мы все понимаем, что мир интернет-технологий слишком подвижен, чтобы давать пользователям громкие обещания и гарантировать стопроцентную защищенность. Так где же находится та самая золотая середина? В этой статье разберемся, как организовать процесс разработки безопасных мобильных приложений, чтобы завоевать пользовательское доверие.

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

Приведу пример DD Planet. Сейчас мы занимаемся разработкой и поддержкой мобильного приложения Живу.рф. Сервис представляет собой электронную систему самоуправления граждан, включающую в себя приватную социальную сеть, мессенджер, механизмы подтверждения личности и принадлежности к адресу. Безопасность огромного массива персональных данных пользователей мы обеспечиваем следующим образом: на стороне мобильного клиента авторизация и предоставление личных данных происходит с помощью OAuth2. Профиль пользователя подтверждается посредством сайта "Госуслуги", а право собственности – выпиской ЕГРН из Росреестра, после чего данные передаются в ИСПДн (Информационную систему персональных данных), где хранятся в изолированной виртуальной сети с защищенной ИТ-инфраструктурой.

Шаг 1. Определить возможные виды уязвимостей

На практике соблюдение информационной безопасности – это своевременная реакция на возможные недочеты.

В среднем на одно приложение может приходиться более 30 уязвимостей, шесть из которых критически опасны. Самое опасное следствие уязвимостей – утечка данных.

Ее причины обычно кроются в недостатках администрирования и разграничения доступа к различным устройствам. Чувствительные данные не должны храниться в открытом доступе. Для их защиты следует использовать надежные криптографические алгоритмы.

Отсутствие обязательной аутентификации и некорректное управление сессиями также могут способствовать краже конфиденциальной информации. Чтобы этого избежать, нужно применять исключительно многофакторную аутентификацию, проверять пользовательские сессии и хранить авторизационные токены в наиболее безопасных областях ОС.

Безопасная и корректная работа с данными особенно важна, когда речь идет о приложениях, использующих большой объем персональной информации.

Еще одна серьезная уязвимость – небезопасная передача данных, которая характеризуется недостаточным подтверждением достоверности источников связи, неверными версиями SSL и неполной проверкой согласования. Использование сертификатов, подписанных доверенными центрами, и применение Web-сниффера для контроля передачи данных только в зашифрованном виде обеспечат безопасный обмен.

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

Уязвимость методов авторизации может обеспечить доступ к закрытой информации или функциям приложения, поэтому нужно позаботиться о корректном распределении прав доступа.

Кроме того, довольно часто в коде приложения присутствуют скрытые функциональные возможности: информация для тестировщиков, "невидимые" настройки и даже некоторые ключи. Необходимо внимательно проверять идентификаторы девайсов и открывать доступ к скрытым разделам только на устройствах разработчиков или тестировщиков.

Шаг 2. Оценить уровень защищенности приложения

Для того чтобы выявить потенциальные факторы риска и обеспечить информационную безопасность, следует проводить обязательное тестирование приложений. Преимущественно используют два вида тестов на преодоление защиты, так называемые белый и черный ящики.

Метод белого ящика, или статистическое тестирование безопасности (SAST), включает в себя оценку со стороны разработчика. Иными словами, специалист получает доступ к исходному коду и проверяет работу всех алгоритмов.

Метод черного ящика заключается в том, что тестировщик не обладает никакой информацией о системе и анализирует приложение на функциональность с позиции обычного пользователя.

Кроме того, существуют сервисы, которые выявляют уязвимости мобильных приложений в автоматическом режиме: Ostorlab, Appvigil, Quixxi, Andro-Total, Akana, NVISO, SandDroid и др.

Профессиональные лайфхаки

В завершение несколько рекомендаций для достижения максимальной безопасности продукта:

• использовать параметризованные запросы к базе данных;
• избавляться от конструирования запросов внутри приложения, чтобы избежать SQL-инъекций;
• подключаться к базе данных лишь под специальной заведенной учетной записью с минимально необходимым набором прав;
• регулярно вести журналы безопасности.

Для выявления уязвимостей мы в DD Planet в основном используем ручное тестирование. Данный метод исключает применение программных средств и базируется на экспертном анализе. Приложение исследует опытный инженер-тестировщик, который выполняет роль конечного пользователя и имитирует возможные поведенческие сценарии. Ручное тестирование требует значительно больше времени, нежели автоматическое, но считается наиболее эффективным в отношении полноты охвата данных и оперативной реакции: устранять баги и корректировать функционал можно сразу же.

Шаг 3. Расставить приоритеты в устранении уязвимостей

При разработке приложений важно не только вовремя выпускать релизы, но и оперативно устранять баги для гарантии пользовательской безопасности. Удовлетворить все заданные требования помогает метод оценивания задач по приоритету, используемый при тестировании. Найденные баги, которые надо устранить, распределяются по степени негативного воздействия на продукт.

1. Первым делом обнаруживаем и устраняем блокеры или ошибки, из-за которых дальнейшая работа приложения невозможна (отсутствует возможность регистрации или входа в аккаунт, нельзя получить доступ к информации в приложении или к его разделам).
2. Далее отслеживаем и исключаем критические баги (проблемы безопасности, зависания системы, неправильно работающая бизнес-логика или временные падения приложения).
3. Затем анализируем проблемы Medium-уровня – выявляем ошибки, которые не влияют на использование приложения, но не совпадают с ожидаемой работой функционала (например, недочеты дизайна).
4. Наконец, устраняем последние недостатки: избавляемся от мелких багов, вносим корректировки по интерфейсу, убираем опечатки.

Выпуск продукта происходит в несколько этапов: сначала публикуем его на тестовом окружении для выявления багов. После этого проводим багфиксинг приоритетов 1-го и 2-го уровня серьезности (Severity). Далее мы делаем релиз на продакшн, после которого часть команды занимается устранением багов с уровнем 3 и 4, и через несколько дней происходит еще одно обновление.

И самое главное – не доверять пользовательскому вводу.

Любые данные от клиента должны проверяться на сервере, что позволит предотвратить прохождение скриптов или злонамеренных шестнадцатеричных кодов. Пользовательские данные часто передаются в качестве параметров для вызова другого кода на сервере. Важно подвергать все входные данные строгой проверке на корректность. Оставив их без проверки, можно серьезно нарушить безопасность системы.