Мобильное приложение для интернет-магазина: кто атакует и как защищать?

Для понимания ценности мобильного приложения для интернет-магазина стоит взглянуть на некоторые открытые в сети факты:

1. В этом году китайский ритейлер-гигант JD.COM провел в своей стране онлайн-распродажу и получил за один день более 100 миллионов заказов. Причем 85% из них были сделаны с мобильных устройств.

2. Один из лидирующих интернет-магазинов России – WB.RU – получает около 65% своих заказов посредством мобильного приложения. Тенденции продаж говорят о росте этого числа (график роста заказов с мобильных приложений показан на рисунке).

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

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

Неправильное использование возможностей платформы

Согласно исследованиям, которые проводятся на базе мирового лидера в области изучения Web-уязвимостей (OWASP), на первом месте среди уязвимостей находится ошибка разработчиков – неправильное использование возможностей платформы. Будь то IOS, Android или Windows Phone.

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

Для наглядности можно рассмотреть IOS Keychain – защищенное место для хранения секретных данных приложений, ровно как и самой ОС. Данные о сессиях, паролях и т.п., хранящиеся вне IOS Keychain, к примеру в локальном хранилище, доступны злоумышленнику.

Небезопасное хранение данных

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

В процессе своей жизнедеятельности приложение так или иначе формирует и сохраняет информацию:

• Базы данных SQL;
• Cookie-файлы;
• LOG-файлы;
• XML манифест-файлы.

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

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

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

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

Небезопасный канал передачи данных

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

Пока приложение передает информацию по незащищенным каналам связи – данные можно подменить, украсть и перенаправить. К примеру, вы рассчитывали оплатить молоко, а по факту оплатили чей то счет на телефон. Такая неприятность становится возможной за счет того, что есть тип атаки Man in the middle. Это когда приложение устанавливает связь с сервером через, к примеру, прокси-сервер (установили связь через бесплатный Wi-Fi на улице), который подконтролен злоумышленнику. И по сути – атакующий от имени вашего приложения общается с сервером. Такой вид атаки возможен и через защищенные каналы, но только в тех случаях, когда приложение не проверяет сертификат. Приложению требуется убедиться в подлинности пришедшего сертификата.

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

Небезопасная авторизация

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

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

Защитой в данном случае служит проверка привилегий авторизованного пользователя на серверной стороне.

Фальсификация кода

Сюда же можно отнести еще одну угрозу – фальсификацию кода. Дело в том, что серверная сторона всегда должна с опаской относиться к запросам своей второй половинки – мобильного приложения, ведь логику работы установленного мобильного приложения можно скорректировать в интересах злоумышленника. Более того, есть случаи, когда оригинальные приложения модифицируются силами "плохих ребят" и выкладываются в места "раздачи" – в частности, в Google Play и AppStore. Вред от подобных атак начинается как минимум с того, что сервер будет работать с запросами от нелицензированного приложения (а был расчет на заработок от лицензий), и заканчиваться тем (с учетом вышеописанных угроз), что авторизационные данные пользователей будут уходить к злоумышленникам.

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

Реверс-инжиниринг

Подход, посредством которого исходный код приложения становится доступен не только разработчикам приложения, но еще и киберпреступникам. Так или иначе – часть ценных для бизнеса алгоритмов находится в мобильном приложении, и попадание их в руки к конкурентам может нанести урон предприятию. Исследуя исходные коды, можно найти явные огрехи или слабые места – даже на серверной стороне. Отсюда же вытекает одна из дорог в сторону угрозы фальсификации кода. Все это становится легко доступным, когда не используется защитный подход – obfuscating (запутывание). Подход заключается в преобразовании исходного кода в непонятный вид посредством специального программного обеспечения.

Посторонний функционал

В заключение хочется сказать о том, что в десятку общемировых уязвимостей вошел так называемый посторонний функционал. Часто разработчики оставляют для себя "лазейки" с благими намерениями – быстро проверить тот или иной функционал, посмотреть, что доступно самому привилегированному пользователю без авторизации, либо волшебная кнопка отключения двухфакторной авторизации – дабы не тратить время на вход в приложение по полному циклу. И весь этот арсенал может стать доступным человеку, способному на атаку через приложение!

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

Защита – административное воздействие на разработчиков.