Анализ защищенности проводят для выявления всевозможных уязвимостей, мошеннических схем, каналов утечки конфиденциальной информации и других ошибок, способных привести к несанкционированному доступу к административным функциям веб-приложений. По сути — это независимое исследование, с помощью которого можно оценить текущее состояние информационной безопасности системы.
Автор: Александр Герасимов, сооснователь Awillix
Что нужно для старта?
Чтобы начать проводить анализ, нужно оценить объем работы и определиться со способами ее проведения, поэтому работа начинается с брифа.
Нужно дать специалистам информацию о том, что из себя представляет приложение, какие у него технические и бизнес-процессы. Например, если это интернет-магазин, значит есть несколько пользовательских ролей: администратор, покупатель, служба поддержки и тд. У каждого свои процессы. Покупатель добавляет товар в корзину, пользуется личным кабинетом, вводит персональные данные для оформления покупки. Нужно кратко дать такую информацию о веб-приложении, верхнеуровнево описать его тип, функции, количество микросервисов и так далее.
Так, исполнитель сможет оценить фронт работ и выбрать методы тестирования. Бывают методы «черного ящика» — неизвестно ничего про приложение, кроме его адреса. «Серого ящика» — предоставляются учетные записи, документация и схемы. И «белого ящика» — известно все, включая исходный код.
Какие баги нужно искать?
Обычно у исполнителя есть стандартный список проверок и чек-лист того, что должно быть сделано. Работа начинается с покрытия приложения всевозможными автоматизированными средствами, сканерами. Важно сказать, что автосредства генерируют много трафика, из-за этого веб-ресурс может перегружаться и приносить неудобства пользователям. Чтобы так не случалось, делают, либо тестовый сегмент специально под эксперименты пентестеров, либо применяют ограничение на продовом сегменте, например, заказчик определяет — отправляйте не более 10 запросов в секунду на наш сервер, чтобы не навредить сервису.
После того как всё покрыли автосканами, начинается проверка в ручном режиме — она составляет бОльшую часть работ. В зависимости от функциональности сайта, применяются различные тесты. Например, если есть авторизация, проверяется ее механизм: есть ли парольная политика, есть ли возможность перебора паролей, есть ли возможность перечисление пользователей, есть ли уязвимости бизнес-логике. На каждый реализованный механизм со стороны заказчика применяются свои различные тесты.
Пример состава работ при анализе защищенности веб-приложений:
- Сбор информации о системе и используемых технологиях;
- Сканирование с помощью сканеров безопасности;
- Ручной поиск всевозможных уязвимостей и ошибок;
- Верификация и анализ выявленных уязвимостей;
- Эксплуатация выявленных уязвимостей;
- Оценка рисков и угроз информационной безопасности;
- Составление отчета.
Все зависит от того, что есть на сайте. Если есть формы отправки данных, то в них могут быть уязвимости, например, недостаточные фильтрации пользовательского ввода. Здесь можно попробовать найти уязвимость внедрения SQL-команд для получения информации из базы данных.
Если есть функциональность загрузки аватара, можно попробовать разные уязвимости, например, получение возможности исполнения команд (RCE), с помощью загрузки вредоносного файла, чтение локальных файлов (LFI/Traversal) в подключение удаленных файлов (RFI) на сервере и загрузка большого объема данных (DoS) с целью отказа в обслуживании.
Или, например, подделка запроса на стороне сервера (SSRF), так чтоб бэкенд отправил запрос к внутренним системам.
Еще один пример, сайт с формой обратной связи, где к каждому сообщению отправленному через нее, присваивается уникальный числовой идентификатор. Если нет механизма разграничения доступа, то изменяя число идентификатора, можно прочитать чужое обращение. Так злоумышленник может получить чувствительные или персональные данные клиента.
Пентестер с опытом примерно понимает, как реализована та или иная функциональность на сайте, и может смоделировать угрозы. Он знает, как приложение может себя повести и как можно нарушить логику его работы.
Поэтому работа выполняется, именно вручную.
Существует общая методология для всех веб-приложений, куда входят проверки из методологии OWASP Top 10. У нас, например, есть своя методология на основе PTES, OWASP и собственных наработок.
Популярные методологии:
- Open Web Application Security Project (OWASP)
- Web Application Security Consortium (WASC)
- Open Source Security Testing Methodology Manual (OSSTMM)
- EC-Council LPT
- Mobile App Security Verification Standard (MASVS)
- OWASP Mobile Security Testing Guide (MSTG)
- Penetration Testing Execution Standard
Как часто нужно проводить анализ защищенности?
Частота проверок зависит от типа приложения. Если это сайт-визитка с небольшой функциональностью, у нее есть только форма обратной связи, галерея, отзывы, мало логики и все стандартно, то можно проводить оценку раз в год или в полтора. Чаще не имеет смысла, потому что сайт не обновляется, разработчики просто написали его и поддерживают. Достаточно покрывать проверками автоматизированными средствами и проверять после обновлений.
Если это сайт с большой логикой, как интернет-магазин или сайт с личным кабинетом, где есть свое API, авторизация — то имеет смысл проверять почаще, например, раз в пол года. На таких сайтах часто выходит обновления, разработчики что-то «допиливают», добавляют новую функциональность или интеграцию. Желательно такие масштабные обновления каждый раз проверять или сделать проверку отдельных доработок и раз в год — масштабную общую проверку.
Что делать с полученной информацией?
1. Собрать все найденные уязвимости.
Мало найти уязвимость и описать ее на техническом уровне, важно приложить разные доказательства и команды в текстовом виде, чтобы заказчик мог их скопировать, повторить и подтвердить, что они существуют.
2. Описать риски и рекомендации по устранению.
Нужно описать риски, которые могут возникнуть при реализации уязвимости, например, получение чувствительных данных о пользователях. И сделать это на понятном языке для бизнеса — executive summary, которое поймет совет директоров и захочет пойти на встречу ИБ. Так же написать понятные рекомендации о том, как исправить уязвимости шаг за шагом, чтобы заказчик мог без труда сделать все по инструкции и реализовать патчи для уязвимостей.
3. Предусмотреть вариативность устранения баг.
Важно расписать различные варианты для устранения уязвимостей, например, надо в коде реализовать такую-то функцию и подключить такой-то модуль, тогда все будет безопасно. Но если у заказчика долгий цикл разработки и прямо сейчас он не может внести изменения, а уязвимость критичная и надо срочно исправлять, можно предложить альтернативные способы — сделать виртуальный патч на фаерволе или правило на прокси, сделать свое временное правило, чтобы эту уязвимость устранить и так далее.
Если вообще никак не могут устранить, то настроить логирование по правилам, которые могут определить есть ли эксплуатация этой уязвимости или нет. Чтобы заказчик был хотя бы в курсе, что кто-то пытается ее эксплуатировать и мог что-то предпринять.
4. Приоритизировать устранение.
В дополнение желательно сделать планирование по устранению найденных уязвимостей в зависимости от их степени критичности, например, эти устраняем срочно, эти в течение недели, а остальные, менее критичные, в течение месяца.
Что в итоге?
Перечень полученных после анализа результатов:
- Независимая оценка уровня информационной безопасности приложений;
- Полный отчет с описанием всех выявленных уязвимостей, сценариев эксплуатации и рекомендации по устранению каждой уязвимости и повышению уровня безопасности в целом;
- Отчет для высшего руководства с рекомендациями и описанием возможных бизнес-рисков;
- Устранение существующих угроз и рисков информационной безопасности.
По результатам анализа защищенности можно понять, какие процессы информационной безопасности нужно внедрить и какие средства защиты информации поставить, не только в качестве сиюминутного решения, но и в качестве улучшения общего уровня ИБ.
Так, например, чтобы больше не возникали уязвимости, связанные с отсутствием механизмов защиты от множественных запросов, применяют Anti-DDoS решения. Или внедрение WaF может позволить применить виртуальный патч для уязвимости сразу же, не дожидаясь нового релиза приложения, где устранение было сделано на уровне кода. Ведь мы знаем, что релиз может занимать долгое время, а критическую уязвимость могут эксплуатировать уже сейчас.
Актуальные вакансии по ИБ: https://cisoclub.ru/vacancy/. Отправить резюме во все популярные IT-компании: https://cisoclub.ru/jobmail/
Больше интересного материала на cisoclub.ru. Подписывайтесь на нас: VK | Twitter | Rutube | Telegram | Дзен | YouTube.