Тестирование на проникновение и защита приложений


Тестирование на проникновение и защита приложений

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

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

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

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

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

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

Деньги сами привлекают киберпреступников

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

Кражи криптовалют

Вот суммы ущерба, причиненного криптовалютным компаниям и их клиентам за 2019–2020 годы:

Название криптобиржиДатаОбъект кражиУщерб в долларовом эквиваленте
Cryptopia14.01.201998 видов криптовалют$16 000 000
DragonEx24.03.201920 видов криптовалют$7 090 000
Bithumb30.03.2019Монеты EOS и XRP$18 700 000
Binance07.05.2019Монеты BTC$40 000 000
Bitrue27.06.2019Монеты ADA и XRP$4 230 000
BitPoint12.07.20195 видов криптовалют$32 000 000
VinDAX05.11.201923 вида криптовалют$500 000
LocalBitcoins26.11.2019Монеты BTC$27 000
UPbit27.11.2019Монеты ETH$49 116 000
Итого за 2019 год:$167 663 000
Altsbit06.02.20205 видов криптовалют$285 000
Bisq07.04.2020Монеты BTC и XMR$252 000
Пока за 2020 год:$537 000

Кроме бирж в 2019 году от хакеров пострадали онлайн-кошелек GateHub (украли $9 600 000) и криптоброкер Coinmama (украли 450 000 имейлов и паролей пользователей). А в 2020 году дважды обокрали DeFi-платформу bzx (на $350 000 и $645 000).

Кражи фиатных денег

В 2019 году у компаний сферы финансовых услуг оказались самые высокие издержки от киберпреступности — $18,3 миллиона. А у тех, кто сталкивался с утечкой финансовых данных, акции падали в цене в среднем на 7,27% после инцидента. По этой причине, а еще из-за репутационных рисков большинство кибератак не предается огласке.

Данные тоже пригодятся киберпреступникам

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

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

Самой затратной на последствия после утечки данных оказалась отрасль здравоохранения — средние издержки больниц составили $6,45 миллиона за 2019 год.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DoS/DDoS-атаки

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

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

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

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

Подмена DNS

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

Client-side контроль

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

Как лучше защитить веб или мобильное приложение

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

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

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

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

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

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

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

Как проводится тестирование на проникновение

Наши специалисты по безопасности проводят тестирование на проникновение в 5 этапов.

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

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

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

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

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

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

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

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

Анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование и защита: миссия выполнима

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

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

Стоимость тестирования на проникновение — от 350 000 рублей. Это в разы ниже тех потерь, которые может понести любая компания из-за действий злоумышленников или претензий регуляторов, если ее деятельность связана с финансами или обработкой и хранением персональных данных. Мы не сгущаем краски, об этом предупреждают аналитики: в 2021 году глобальные издержки из-за киберпреступности вырастут до 6 триллионов долларов.

Защитите свое приложение от взломов и атак, обезопасьте себя от репутационных рисков, пока не стало слишком поздно. Обратитесь в Polygant — ИТ-компанию, которая на протяжении 7 лет занимается поиском уязвимостей, проверкой сценариев взлома приложений и устранением угроз безопасности.

Ваше сообщение было успешно отправлено. Мы скоро с Вами свяжемся!