В связи с тем, что компании все чаще используют мобильные технологии, которые призваны повысить производительность труда сотрудников, упростить внутренние процессы и, в конечном итоге, увеличить прибыльность, хакеры находят новые способы инфильтрации и получения доступа к конфиденциальной информации через мобильные приложения. Gartner Research прогнозирует, что к 2017 г. целых 75% нарушений безопасности мобильных устройств будут результатом неправильной конфигурации мобильных приложений. Речь идет о множестве пробелов в защите, существенно превышающем ожидания большинства экспертов по ИТ-безопасности. Вот что может произойти, когда так много мобильных приложений выходит на рынок без полной проверки кода и конфигурации на безопасность.
Поэтому разработчикам важно знать о наиболее распространенных уязвимостях мобильных устройств и наиболее совершенных способах повседневной борьбы с ними. Приведенные далее рекомендации базируются на оценке перспектив отрасли, сделанной Аароном Брайсоном, главным архитектором безопасности и менеджером по безопасности продуктов провайдера корпоративных мобильных сервисов Kony.
1. Слабый контроль серверных компонентов
Рекомендации. В серверной части мобильного приложения должны применяться безопасные практики написания программного кода и конфигурирования. В частности, API-интерфейс должен надежно проверять идентификацию и полномочия лица, его вызывающего.
2. Незащищенное хранение данных
Рекомендации. Если возможно, не храните конфиденциальные данные на устройстве или внутри исходного кода его ПО. Если же бизнес требует хранения конфиденциальной информации на мобильном устройстве, шире используйте шифрование, не полагаясь лишь на соответствующие возможности мобильной ОС.
3. Недостаточная защита на транспортном уровне
Рекомендации. Используйте привязку сертификата или публичного ключа (HPKP) к клиенту для предотвращения атак типа «человек посередине» или взаимную аутентификацию, чтобы и сервер, и клиент проходили аутентификацию и не могли отрицать свою идентичность. Убедитесь, что все подключения к вашим серверам шифруются (если это возможно) с использованием самых передовых конфигураций (т. е. на сегодняшний день TLS 1.2). Не доверяйте пользовательским сертификатам и убедитесь, что ваши SSL-сертификаты актуальны и подписаны доверенным центром сертификации.
4. Непредумышленная утечка данных
Рекомендации. Учтите, что операционные системы, разработанные для соответствующих мобильных устройств, часто позволяют пользователям копировать и вставлять данные, делать снимки экрана, создавать резервные копии данных, подсоединять любые клавиатуры и производить анализ с помощью приложений сторонних компаний. Учитывайте сопряженный с подобными сценариями риск и решайте, приемлем ли он для ваших мобильных приложений. Если нет, вы должны в явном виде запретить такие действия мобильных приложений либо контролировать устройства с помощью решения для управления мобильными устройствами (mobile-device management, MDM) или мобильными приложениями (mobile-application management, MAM).
5. Слабые механизмы аутентификации и авторизации
Рекомендации. Периодически, а также перед выполнением каких-либо рискованных действий производите аутентификацию и повторную аутентификацию пользователей. Каждый раз авторизуйте любой запрос.
6. Взломанная криптография
Рекомендации. Позаботьтесь о том, чтобы то, как вы применяете криптографию, было проанализировано знающими специалистами по безопасности.
7. Инъекция на стороне клиента
Рекомендации. Защитите приложения от взлома как в статичном состоянии, так и во время исполнения. Производите проверку входных данных приложений и API-интерфейсов, проверяйте целостность конфиденциальной информации и будьте осторожны при использовании WebView, поскольку это может создать уязвимости вроде межсайтового скриптинга (XSS).
8. Не заслуживающие доверия входные данные
Рекомендации. Никогда не исходите из того, что этим источникам данных можно доверять, и должным образом защитите их от фальсификаций и злоупотреблений, в т. ч. с использованием аутентификации, авторизации, проверок целостности, шифрования или других механизмов.
9. Ненадлежащая обработка сеанса
Рекомендации. Применяйте механизм ограничения времени действия cookie для сессий как на сервере, так и на клиенте. В общем случае рекомендуется ограничить время одним часом или менее. Проследите, чтобы ваш сервер открывал новую сессию для каждого пользователя всякий раз, когда требуется аутентификация. Убедитесь, что на сервере прежние сессии уничтожаются/объявляются недействительными для предотвращения повторного использования.
10. Отсутствие защиты двоичного кода
Рекомендации. Особенности защиты приложений зависят от характера угроз и от мобильной платформы. Но вы захотите, чтобы ваши приложения были защищены в процессе исполнения от анализа, мониторинга и внедрения кода и чтобы исходный код был зашифрован и запутан. Проверки целостности могут помочь предотвратить модификацию ресурсов и исходного кода.