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

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

Важность защиты финтех-приложений

Согласно отчётам «X-Force Threat Intelligence Index 2020» от IBM и «Hi-Tech Crime Trends 2019/2020» от Group-IB, в 2019 году по количеству атак снова лидировал финансовый сектор, уже четвёртый год подряд. В ежегодной статистике Лаборатории Касперского он тоже удерживает первую позицию с 2015 года.

Всемирный экономический форум включил кибератаки в пятёрку глобальных рисков 2019 года. Банк Англии в своём рейтинге рисков для финансовой системы поставил их на третье место в середине 2019, а к концу года уже поднял на второе.

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

Взломы с кражей криптовалют

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

За 2019 год взломали 9 бирж и 1 многофункциональный сервис, при этом украли монеты и токены на сумму, эквивалентную 177 263 000 $. А вот инциденты уже 2020 года, в результате которых криптовалютные компании и проекты лишились своих и пользовательских активов:

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

Кражи традиционных денег и платёжных данных

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

462 тысячи у индийских банков;

397 тысяч у банков в Южной Корее и США;

235 тысяч у банков в Малайзии, Филиппинах и Сингапуре.

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

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

В феврале киберпреступники использовали интеграцию Paypal с Google Pay, чтобы оплачивать покупки в США со счетов пользователей из Германии. Представители Paypal признали проблему и компенсировали жертвам десятки тысяч евро.

В июле злоумышленники украли личные данные 7,5 миллиона пользователей Dave, приложения мобильного банкинга. Собрать такую базу они смогли из-за халатности Waydev, поставщика аналитических услуг для Dave. Так как финансовой и конфиденциальной информации там не было, то эту базу слили в открытый доступ.

Неавторизованные покупки за чужой счёт

С 2019 года хакеры начали активнее, чем в предыдущие годы, атаковать интернет-магазины и облачные сервисы. Причины очевидны: в электронной коммерции задействованы карты, у многих покупателей они привязаны к аккаунтам; облака хранят терабайты конфиденциальной информации и коммерческой тайны.

В июле 2019 как раз произошёл случай, иллюстрирующий, насколько беспечными бывают создатели приложений и какими профессионалами оказываются преступники. 1 июля японская сеть минимаркетов 7-Eleven порадовала покупателей функцией мобильных платежей, которую добавила в приложение 7pay. Обрадовались и хакеры, на следующий же день найдя в нём уязвимость, через которую получили доступ к 900 аккаунтов. За сутки они потратили с привязанных карт 55 миллионов иен (~510 тысяч долларов США). Компании пришлось отключить 7pay 3 июля и возместить пострадавшим ущерб.

А в марте и апреле 2020 хакеры использовали устаревшую, но ещё работающую авторизацию через NNID, чтобы входить в аккаунты пользователей Nintendo. За чужой счёт они покупали игры Nintendo и игровую валюту Fortnite, расплачиваясь привязанной к профилю картой или PayPal-ом. Пострадали 300 тысяч пользователей; компания уже сбросила им пароли и почти вернула растраченные деньги.

Необходимость защиты приложений с любыми данными

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

На персональные данные и конфиденциальную информацию всегда найдутся покупатели, например, конкуренты вашей компании и мошенники. В даркнете они могут купить украденную базу из тысяч клиентов за 300 $ и начать их обрабатывать. А вот взломанной компании каждая запись обходится в 152 $, согласно отчёту IBM Security. Исследователи провели опрос пострадавших компаний и вывели глобальные показатели: в среднем утекали 25 600 записей, что приводило к убытку на 3,9 миллиона долларов.

Последствия нарушения законов о данных

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

В Евросоюзе с мая 2018 действует Общий регламент защиты персональных данных (GDPR). За полтора года после принятия в 28 государствах ЕС зарегистрировали 160 тысяч уведомлений о нарушении данных. По ним местные регуляторы оштрафовали компании на общую сумму 114 миллионов евро (~134 миллиона долларов США). GDPR предусматривает два типа штрафов в зависимости от серьёзности нарушения:

За мелкое полагается штраф до 10 миллионов евро или 2% от годового оборота.

За крупное полагается штраф до 20 миллионов евро или 4% от годового оборота.

После Брексита в Великобритании всё ещё действует GDPR. В конце 2020 года ему на смену пришла совмещённая версия EU GDPR и старого DPA 2018, которую пока условно называют UK GDPR. Там те же два типа штрафов с эквивалентными размерами в фунтах стерлингов. В Великобритании соблюдение закона контролирует Управление комиссара по делам информации.

В России нарушение аналогичного закона — № 152-ФЗ «О персональных данных» — пока карается слишком мягко. За это полагается административный штраф до 75 тысяч рублей, причём это ужесточённая с июля 2017 ответственность. В РФ соблюдение закона контролирует Роскомнадзор.

К сожалению, штрафные санкции не вынуждают компании усиливать меры по обеспечению информационной безопасности. За 2019 год были скомпрометированы более 14 миллиардов записей (вдвое больше, чем за 2018-й). А уже в июне 2020 и этот рекорд побит, так что к концу года снова ожидается удвоение показателя в записях.

Угрозы мессенджерам

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

В течение 2019 года один только Facebook пополнил Национальную базу уязвимостей США 11-ю уязвимостями в WhatsApp, найденными багхантерами. А вот с какими проблемами столкнулись компании помельче и уже в 2020 году:

В марте WhisperText, создавшая приложение Whisper для анонимного общения и обмена секретами, узнала о проблеме безопасности. О ней через СМИ сообщили независимые специалисты, которые обнаружили незащищённую базу данных объёмом 75 ТБ с 900 миллионами записей. В базе, пополняемой с 2012 года, хранились пользовательские псевдонимы, анкетные данные профилей, ip-адреса и координаты местоположения. А ведь компания позиционировала своё приложение как самое безопасное место в Интернете.

В начале апреля Zoom Video Communications, создавшая платформу видеоконференций Zoom, получила отчёт от этичного хакера о наличии бага. Он подробно описал, как за 25 минут и 91 тысячу попыток подобрал пароль к чужой конференции методом брутфорса. Просто в веб-клиенте отсутствовало ограничение на количество попыток, а пароли представляли собой шестизначный числовой код (это максимум миллион комбинаций).

В середине апреля независимые исследователи обнаружили базу данных Zoom в продаже на даркнет-форумах. В дампе оказались учётные данные 530 тысяч пользователей (имейлы, пароли), идентификаторы конференций, имена и ключи хостов. Это уже не связано с багом подбора паролей.

Между прочим, установка пароля на конференцию появилась в Zoom из-за того, что с увеличением популярности и аудитории там возникло хулиганское движение — зумбомбинг. Скучающие во время пандемии тролли парсили ссылки на собрания, врывались туда и устраивали хаос с шок-контентом и непристойным поведением. Усиление пароля путём добавления символов не снизило их активность, потому что эти вредители не подбирают пароли. Они получают их из открытых источников или выпрашивают у приличных участников, а потом делятся ими в своих кругах, планирующих зумрейды.

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

Уязвимости приложений

Большинство мобильных приложений имеют клиент-серверную архитектуру. Клиентскую часть пользователи скачивают из магазина и устанавливают на свои устройства с мобильной ОС. А серверная часть представляет собой веб-приложение, которое взаимодействует с мобильным клиентом через программный интерфейс приложения (API).

Уязвимости встречаются как в клиентской, так и в серверной части, и даже между ними — в канале передачи данных. Если у вас не мобильное, а веб-приложение или сайт, то всё равно полезно знать о слабых местах на стороне сервера или на пути к нему.

Уязвимости мобильных приложений

Исследование популярных мобильных приложений, проведённое PT в июне 2019, показало: в 38% приложений для iOS и в 43% для Android обнаружились уязвимости высокого уровня риска; 74% приложений для iOS и 57% для Android содержали ошибки в механизмах защиты; 76% приложений хранили данные небезопасно. Рассказываем о самых распространённых уязвимостях, требующих устранения из мобильного приложения.

Незащищённый двоичный код

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

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

Соединение с внутренним сервером

Мобильное приложение, которое обращается к данным на сервере через вызовы API, становится уязвимым, когда не использует HTTPS для всех соединений. А методы SSL остаются без защиты, если позволяют использовать какой-либо сертификат, например, небезопасную версию SSLSocketFactory.

Кроме того, поскольку базовая HTTP-аутентификация уже считается небезопасной, приходится защищать REST API с помощью JWT. При доступе к данным учётной записи пользователя эти токены должны создаваться как часть безопасного интерактивного входа в систему с пользователями.

Место хранения данных

Если хранить данные пользователей в незащищённых местах, например, в файлах Plist, то кто-нибудь обязательно получит к ним несанкционированный доступ. Учётные записи и другие данные лучше хранить в соответствующей цепочке для ключей: «Связка ключей iCloud», «Брелок» (KeyChain) или KeyStore в Андроиде. Конфиденциальная информация, требующая локального хранения, всегда должна шифроваться.

Библиотеки с открытым кодом

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

Отсутствие 2FA

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

Уязвимости веб-приложений

Исследование популярных веб-приложений, проведённое PT в феврале 2020, показало: через 90% приложений можно было атаковать пользователей; на 39% сайтов был возможен несанкционированный доступ к приложению; в 68% приложений присутствовала угроза утечки данных. Разберём самые распространённые уязвимости, требующие устранения из веб-приложения.

Слабые места CMS

Если вы используете популярную систему управления содержимым, например, Joomla или WordPress, то учитывайте, что они не абсолютно безопасны. Сразу «из коробки» они имеют множество уязвимостей, которые приходится устранять самому владельцу-администратору.

Также уязвимы устанавливаемые в CMS плагины, как сторонние, так и официальные. Самые популярные и проверенные WordPress-плагины, например, Yoast SEO или WooCommerce, легко взламываются с помощью XSS, а плагин авторизации подвержен SQL-инъекциям.

Управление сессиями

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

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

Атаки и способы взлома приложений

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

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

Атака методом полного перебора

Эта атака также называется методом грубой силы. С её помощью взламывают приложения критического класса, чтобы перехватывать вызовы API и выполнять код авторизации, не оставляя следов. При этом код возвращается к своей первоначальной форме. Атака ещё предполагает изменение сопоставления таким образом, чтобы вызов API «А» фактически вызывал API «Б», а API «Б» мог сохранять информацию о банковских картах на другом сервере, собирать данные о клиенте и настраиваться для выполнения нежелательных операций.

Эксплуатация SQL-инъекций

Это наиболее распространённый способ взлома веб-приложений и сайтов. Большинство из них использует язык структурированных запросов (SQL) для взаимодействия с базами данных. Он позволяет создавать и изменять записи в базе.

Делая SQL-инъекции, хакеры могут взломать внутренние компоненты веб-приложения. Они состоят из SQL-запросов через ввод данных от клиента в веб-приложение. Так преступники могут считать информацию из базы данных и использовать её. Они также могут модифицировать запрос и выполнять функции и операции администрирования СУБД.

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

Межсайтовый скриптинг

Межсайтовый скриптинг (XSS) хакеры тоже часто используют для взлома сайтов. Для многих владельцев он стал серьёзной угрозой. Только крупнейшие сайты, например, принадлежащие Google и Microsoft, успешно отражают XSS-атаки.

Злоумышленники при XSS-атаках используют вредоносные сценарии JavaScript, встроенные в ссылки, которые они повсюду распространяют. Когда пользователь нажимает на ссылку, то невольно даёт возможность украсть информацию, перехватить веб-сеанс, захватить учётную запись и даже изменить рекламу на странице.

Чтобы избежать XSS-атак, владельцы сайтов должны фильтровать вводимые пользователем данные для своевременного удаления вредоносного кода.

DoS/DDoS-атаки

Атака ради отказа в обслуживании (DoS/DDos) нагружает сайт огромным объёмом трафика в виде запросов, в результате чего его серверы выходят из строя. Большинство DDoS-атак проводится с использованием компьютеров, которые были скомпрометированы вредоносным ПО. Владельцы заражённых компьютеров могут не знать, что их ПК отправляет запросы на чей-то сайт.

Подделка межсайтовых запросов

Подделка межсайтовых запросов (CSRF) подразумевает передачу неавторизованных команд от пользователя, которому доверяет веб-приложение. У хакеров есть много способов передачи поддельных команд, включая скрытые формы, AJAX и теги изображений. Пользователь не знает, что команда была отправлена, а сайт считает, что команда получена от аутентифицированного пользователя. Разница между атаками XSS и CSRF состоит в том, что пользователю надо войти в систему, а она должна опознать его как «доверенного».

Подмена DNS

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

Контроль клиентской части

Это популярный взлом веб-приложения, при котором хакеры манипулируют его данными, передающимися через клиента. Они взламывают клиентские элементы управления, а потом собирают пользовательские данные. Взломщики находят всё пригодное в самом веб-приложении, где есть скрытые поля форм, параметры URL и файлы cookie, используемые для передачи данных через клиента. Затем они пытаются определить роль, которую конкретный элемент играет в логине приложения.

Кто должен тестировать и защищать приложения

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

Чтобы созданное приложение кто-то проверил на ошибки и при наличии отправил на доработку, нужна команда из тестировщиков, QC и QA. Их можно временно нанять для проекта или воспользоваться аутсорсом. Команда тестирования займётся проверкой функциональности приложения и правильности отработки сценариев. При этом поиском уязвимостей аудиторы кода редко занимаются.

Исследование безопасности веб- и мобильных приложений — компетенция других профессионалов. Поэтому нужна ещё команда из специалистов по информационной безопасности, преимущественно инженеров ИБ. Имея опыт нападения и защиты, они протестируют приложение на проникновение и найдут возможные уязвимые места.

До их привлечения приложение остаётся открытым для злоумышленников, даже если разработчики не халтурили при создании, а тестировщики проверили его досконально. К специалистам по ИБ необходимо обращаться перед выпуском каждой стабильной версии. Желательно проводить проверку безопасности на протяжении всего цикла разработки, чтобы вовремя устранять уязвимости.

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

Тестирование на проникновение

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

Ручное тестирование включает в себя попытку взлома любого количества компонентов приложения для обнаружения уязвимостей. Объектами становятся, например, API, внешние и внутренние серверы.

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

Что входит в сервис тестирования приложений на проникновение

Наши специалисты по ИБ проводят тестирование безопасности веб-приложений и мобильных приложений в 5 этапов.

Планирование и разведка

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

Статический и динамический анализы

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

Получение доступа

Чтобы выявить возможные уязвимости цели, в ход идут такие атаки, как XSS, SQL-инъекция, бэкдоры. Затем пентестеры пытаются использовать эти уязвимости, устраивая повышение привилегий, кражу данных, перехват трафика и прочее. Это позволит определить ущерб, который могут нанести атаки.

Поддержание доступа

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

Отчёт о результатах

В итоге результаты теста на проникновение объединяются в отчёт, детализирующий:

уязвимости, которые были найдены и использованы;

данные, к которым был получен доступ;

время, в течение которого пентестер оставался в системе незамеченным.

Какие методы тестирования безопасности приложений используются

Внешнее тестирование

Внешние тесты на проникновение предназначены для ресурсов, которые размещены в Сети, например: веб-приложение, сайт, серверы электронной почты и доменных имён, даже мобильный клиент. Цель заключается в том, чтобы получить к ним доступ и извлечь ценные данные.

Внутреннее тестирование

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

Слепое тестирование

В слепом тесте пентестеру предоставляется только название приложения, на которое он нацелен. Это позволяет команде по безопасности проекта в реальном времени посмотреть, как будет происходить фактическое нападение.

Двойное слепое тестирование

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

Целевое тестирование

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

Услуги пентеста и защиты

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

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