В связи с тем, что компании все чаще используют мобильные технологии, чтобы повысить производительность труда сотрудников и упростить внутренние процессы, а в конечном итоге увеличить прибыльность, хакеры находят новые способы инфильтрации и получения доступа к конфиденциальной информации через мобильные приложения. Gartner Research прогнозирует, что к 2017 г. целых 75% нарушений безопасности мобильных устройств будут результатом неправильной конфигурации мобильных приложений. Речь идет о множестве пробелов в защите, существенно превышающем ожидания большинства экспертов по ИТ-безопасности. Вот что может произойти, когда так много мобильных приложений выходит на рынок без полной проверки кода и конфигурации на безопасность. Поэтому разработчикам важно знать о наиболее распространенных уязвимостях мобильных устройств и наиболее совершенных способах повседневной борьбы с ними. Приведенные далее рекомендации базируются на оценке перспектив отрасли, сделанной Аароном Брайсоном, главным архитектором безопасности и менеджером по безопасности продуктов провайдера корпоративных мобильных сервисов Kony.

1. Слабый контроль серверных компонентов

API-сервисы доступны в Интернете даже без мобильных приложений, для которых они были созданы. Хакеры могут прослушивать беспроводную сеть или произвести атаку с «человеком посередине», чтобы выявить вызовы API, модифицировать их и напрямую атаковать API.

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

2. Незащищенное хранение данных

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

Рекомендации. Если возможно, не храните конфиденциальные данные на устройстве или внутри исходного кода его ПО. Если же бизнес требует хранения конфиденциальной информации на мобильном устройстве, шире используйте шифрование, не полагаясь лишь на соответствующие возможности мобильной ОС.

3. Недостаточная защита на транспортном уровне

Распространено заблуждение, будто использование протокола SSL/TLS делает мобильное приложение защищенным.

Рекомендации. Используйте привязку сертификата или публичного ключа (HPKP) к клиенту для предотвращения атак типа «человек посередине» или взаимную аутентификацию, чтобы и сервер, и клиент проходили аутентификацию и не могли отрицать свою идентичность. Убедитесь, что все подключения к вашим серверам шифруются (если это возможно) с использованием самых передовых конфигураций (т. е. на сегодняшний день TLS 1.2). Не доверяйте пользовательским сертификатам и убедитесь, что ваши SSL-сертификаты актуальны и подписаны доверенным центром сертификации.

4. Непредумышленная утечка данных

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

Рекомендации. Учтите, что операционные системы, разработанные для соответствующих мобильных устройств, часто позволяют пользователям копировать и вставлять данные, делать снимки экрана, создавать резервные копии данных, подсоединять любые клавиатуры и производить анализ с помощью приложений сторонних компаний. Учитывайте сопряженный с подобными сценариями риск и решайте, приемлем ли он для ваших мобильных приложений. Если нет, вы должны в явном виде запретить такие действия мобильных приложений либо контролировать устройства с помощью решения для управления мобильными устройствами (mobile-device management, MDM) или мобильными приложениями (mobile-application management, MAM).

5. Слабые механизмы аутентификации и авторизации

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

Рекомендации. Периодически, а также перед выполнением каких-либо рискованных действий производите аутентификацию и повторную аутентификацию пользователей. Каждый раз авторизуйте любой запрос.

6. Взломанная криптография

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

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

7. Инъекция на стороне клиента

Широко распространено заблуждение, будто вредоносный код не может изменять мобильные приложения (например, подменять библиотеки или внедрять код в приложения).

Рекомендации. Защитите приложения от взлома как в статичном состоянии, так и во время исполнения. Производите проверку входных данных приложений и API-интерфейсов, проверяйте целостность конфиденциальной информации и будьте осторожны при использовании WebView, поскольку это может создать уязвимости вроде межсайтового скриптинга (XSS).

8. Не заслуживающие доверия входные данные

Скрытые поля, запросы на межпроцессное взаимодействие (IPC) и вызовы веб-сервисов не заслуживают доверия, поскольку все они легко поддаются манипуляции с использованием подходящих инструментов.

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

9. Ненадлежащая обработка сеанса

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

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

10. Отсутствие защиты двоичного кода

Ваши мобильные приложения подвергаются риску обратного инжиниринга, анализа или искажения.

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