В рубрику "Защита информации и каналов связи" | К списку рубрик | К списку авторов | К списку публикаций
Для понимания ценности мобильного приложения для интернет-магазина стоит взглянуть на некоторые открытые в сети факты:
1. В этом году китайский ритейлер-гигант JD.COM провел в своей стране онлайн-распродажу и получил за один день более 100 миллионов заказов. Причем 85% из них были сделаны с мобильных устройств.
2. Один из лидирующих интернет-магазинов России – WB.RU – получает около 65% своих заказов посредством мобильного приложения. Тенденции продаж говорят о росте этого числа (график роста заказов с мобильных приложений показан на рисунке).
Что ни говори, но при увеличении числа пользователей мобильных приложений увеличиваются и риски компаний – за счет отсутствия должной политики информационной безопасности в первую очередь. Главным образом это касается ритейл-сегмента. Ведь зачастую именно в нем скорость разработки главенствует над безопасностью.
Осознав ценность мобильных приложений для интернет-магазинов, рассмотрим виды атак, под действие которых они попадают.
Согласно исследованиям, которые проводятся на базе мирового лидера в области изучения Web-уязвимостей (OWASP), на первом месте среди уязвимостей находится ошибка разработчиков – неправильное использование возможностей платформы. Будь то IOS, Android или Windows Phone.
Так уж сложилось, что есть несколько популярных платформ, и в идеале под каждую требуется держать свою команду программистов. Это позволит погрузиться в особенности платформы. Но по факту, в целях экономии разработки на одних и тех же разработчиков могут быть наложены обязанности ведения проектов на двух, а то и на трех платформах. Кроме того, нередко прибегают к использованию универсальных решений, благодаря которым становится возможным написание единого кода, который в дальнейшем будет преобразован к проекту на требуемой платформе. Все это ведет к тому, что особенности той или иной платформы, включая набор средств безопасности, – разработанный конкретно для той или иной операционной системы (далее ОС), а также рекомендации производителей учитываются слабо или же и вовсе игнорируются.
Для наглядности можно рассмотреть IOS Keychain – защищенное место для хранения секретных данных приложений, ровно как и самой ОС. Данные о сессиях, паролях и т.п., хранящиеся вне IOS Keychain, к примеру в локальном хранилище, доступны злоумышленнику.
Следующей угрозой, посредством которой становятся возможными атаки на мобильные приложения, является небезопасное хранение данных.
В процессе своей жизнедеятельности приложение так или иначе формирует и сохраняет информацию:
Общемировая практика атак на мобильные приложения показывает, что нередко "нападающий" получает такую возможность за счет добытой информации из, в частности, указанных мест, которые хранят ее в открытом виде.
В LOG-файлах могут сохраняться ошибки, содержащие информацию о типах используемого ПО на серверной стороне, кроме того, есть случаи, когда в описаниях ошибок есть логин и пароль для подключения к базе данных.
Попавшие в руки злоумышленника авторизационные Cookie-файлы будут проанализированы. В лучшем случае пострадает один пользователь. В худшем может получиться так, что атакующий сможет понять механизм авторизации и при помощи подмен получить доступ к большинству личных кабинетов пользователей, где могут храниться персональные данные или, к примеру, возможность оплаты с личного счета.
Шифрование криптостойкими алгоритмами и детальная проработка потоков сохраняемой информации в данном случае позволит минимизировать угрозы атак либо свести их на ноль.
Защитив данные на стороне мобильного приложения, не стоит забывать об угрозе, которая появляется на пути передачи данных – от приложения к серверу. Наша следующая атака – это небезопасный канал передачи данных.
Пока приложение передает информацию по незащищенным каналам связи – данные можно подменить, украсть и перенаправить. К примеру, вы рассчитывали оплатить молоко, а по факту оплатили чей то счет на телефон. Такая неприятность становится возможной за счет того, что есть тип атаки Man in the middle. Это когда приложение устанавливает связь с сервером через, к примеру, прокси-сервер (установили связь через бесплатный Wi-Fi на улице), который подконтролен злоумышленнику. И по сути – атакующий от имени вашего приложения общается с сервером. Такой вид атаки возможен и через защищенные каналы, но только в тех случаях, когда приложение не проверяет сертификат. Приложению требуется убедиться в подлинности пришедшего сертификата.
Важно понимать, что защищенные каналы могут работать с рядом криптоалгоритмов. Нельзя защитить приложение, передавая информацию с использованием некриптостойких алгоритмов, и не стоит верить информации, которая передается без контрольного значения.
В мировой практике использования мобильных приложений нередки случаи, когда решение об авторизации принимает приложение, и серверная часть доверяет этому решению. Таким образом, разработчики открывают двери злоумышленникам – подвергая систему атаке, которая обозначается как небезопасная авторизация.
Серверная сторона может быть богата на различные методы – от предоставления данных для отчетов до редактирования прав доступа. Авторизовавшись в приложении с самыми простыми правами, для которых само же приложение и ограничивает набор серверных методов, атакующему остается подобрать вызов методов.
Защитой в данном случае служит проверка привилегий авторизованного пользователя на серверной стороне.
Сюда же можно отнести еще одну угрозу – фальсификацию кода. Дело в том, что серверная сторона всегда должна с опаской относиться к запросам своей второй половинки – мобильного приложения, ведь логику работы установленного мобильного приложения можно скорректировать в интересах злоумышленника. Более того, есть случаи, когда оригинальные приложения модифицируются силами "плохих ребят" и выкладываются в места "раздачи" – в частности, в Google Play и AppStore. Вред от подобных атак начинается как минимум с того, что сервер будет работать с запросами от нелицензированного приложения (а был расчет на заработок от лицензий), и заканчиваться тем (с учетом вышеописанных угроз), что авторизационные данные пользователей будут уходить к злоумышленникам.
Помимо учета угроз от небезопасного хранения данных (включая использование криптостойких алгоритмов шифрования) и использования защищенных каналов передачи данных, стоит позаботиться и о проверке оригинальности приложения, было ли оно модифицировано или нет.
Подход, посредством которого исходный код приложения становится доступен не только разработчикам приложения, но еще и киберпреступникам. Так или иначе – часть ценных для бизнеса алгоритмов находится в мобильном приложении, и попадание их в руки к конкурентам может нанести урон предприятию. Исследуя исходные коды, можно найти явные огрехи или слабые места – даже на серверной стороне. Отсюда же вытекает одна из дорог в сторону угрозы фальсификации кода. Все это становится легко доступным, когда не используется защитный подход – obfuscating (запутывание). Подход заключается в преобразовании исходного кода в непонятный вид посредством специального программного обеспечения.
В заключение хочется сказать о том, что в десятку общемировых уязвимостей вошел так называемый посторонний функционал. Часто разработчики оставляют для себя "лазейки" с благими намерениями – быстро проверить тот или иной функционал, посмотреть, что доступно самому привилегированному пользователю без авторизации, либо волшебная кнопка отключения двухфакторной авторизации – дабы не тратить время на вход в приложение по полному циклу. И весь этот арсенал может стать доступным человеку, способному на атаку через приложение!
Простой пример. Человек зарегистрировался в мобильном приложении, в качестве средства связи указав номер телефона, который принадлежит человеку с приличной суммой на счете. Через оставленную разработчиками лазейку отключил подтверждение телефона (проверку на владение телефонным номером). Попросил систему восстановить логин и пароль по SMS. Угроза деньгам пользователей и репутации организации!
Защита – административное воздействие на разработчиков.
Опубликовано: Журнал "Information Security/ Информационная безопасность" #4, 2016