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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Далее отслеживаем и исключаем критические баги (проблемы безопасности, зависания системы, неправильно работающая бизнес-логика или временные падения приложения).

3. Затем анализируем проблемы Medium-уровня – выявляем ошибки, которые не влияют на использование приложения, но не совпадают с ожидаемой работой функционала (например, недочеты дизайна).

4. Наконец, устраняем последние недостатки: избавляемся от мелких багов, вносим корректировки по интерфейсу, убираем опечатки.

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

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

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