Журнал "Information Security/ Информационная безопасность" #5, 2019

Существуют сервисы, которые выявляют уязвимо- сти мобильных приложений в автоматическом режиме: Ostorlab, Appvigil, Quixxi, AndroTotal, Akana, NVISO, SandDroid и др. Любые данные от клиен- та должны проверяться на сервере, что позволит пред- отвратить прохождение скриптов или злонамерен- ных шестнадцатеричных кодов. Ваше мнение и вопросы присылайте по адресу is@groteck.ru ТЕХНОЛОГИИ 42 • ждением достоверности источ- ников связи, неверными вер- сиями 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, и через несколько дней происходит еще одно обновление. И самое главное – не дове- рять пользовательскому вводу. Любые данные от клиента должны проверяться на сер- вере, что позволит предотвра- тить прохождение скриптов или злонамеренных шестна- дцатеричных кодов. Пользо- вательские данные часто пере- даются в качестве параметров для вызова другого кода на сервере. Важно подвергать все входные данные строгой про- верке на корректность. Оста- вив их без проверки, можно серьезно нарушить безопас- ность системы. l Профессиональные лайфхаки В завершение несколько рекомендаций для достижения максимальной безопасности продукта: * использовать параметризованные запросы к базе данных; * избавляться от конструирования запросов внутри приложения, чтобы избежать SQL-инъекций; * подключаться к базе данных лишь под специальной заведенной учетной записью с минимально необходимым набором прав; * регулярно вести журналы безопасности.