Перейти к основному содержимому

6.08. Тестирование безопасности

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Тестировщику Разработчику Аналитику

Тестирование безопасности​

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

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

Цели и принципы​

Основными целями тестирования безопасности являются:

  • выявление потенциальных точек несанкционированного доступа к данным и функциям;
  • оценка реальной эффективности механизмов аутентификации, авторизации и учёта;
  • проверка устойчивости к известным классам атак (например, инъекции, межсайтовый скриптинг, атаки по времени);
  • выявление недостатков в конфигурации среды исполнения — от веб-сервера до базы данных;
  • подтверждение соответствия требованиям регуляторных стандартов (PCI DSS, ISO/IEC 27001, ГОСТ Р ИСО/МЭК 27001 и др.);
  • формирование объективной картины рисков для информационной системы.

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

Категории подходов​

На практике тестирование безопасности осуществляется через два взаимодополняющих подхода: автоматизированное сканирование и ручной анализ.

Автоматизированное сканирование​

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

Преимущества автоматизированного сканирования:

  • высокая скорость охвата;
  • воспроизводимость результатов;
  • возможность интеграции в CI/CD-конвейеры для регулярной проверки;
  • снижение зависимости от человеческого фактора при выполнении рутинных задач.

Ограничения:

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

Автоматизация не заменяет эксперта, но создаёт для него «дорожную карту» — указывает на потенциально проблемные области, которые требуют углублённого ручного исследования.

Ручной анализ (пенетрационное тестирование)​

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

Пентест может проводиться в нескольких режимах, определяемых уровнем исходной информации:

  • Black box — тестировщик не имеет никакой информации о системе, кроме её публичного адреса; имитирует внешнюю атаку «с нуля»;
  • Gray box — предоставляется ограниченный доступ (например, учётная запись обычного пользователя, схема API, фрагмент документации); наиболее реалистичный сценарий, так как многие атаки начинаются с компрометации учётных данных конечного пользователя;
  • White box — тестировщик имеет полный доступ к исходному коду, архитектуре, конфигурациям; позволяет провести максимально глубокий аудит, но требует высокой квалификации и доверия.

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

Пентестеры и этические хакеры​

Пентестеры — это профессионалы, обладающие глубокими знаниями в области сетевых протоколов, веб-технологий, операционных систем, криптографии и методов атак. Их работа требует постоянного самообучения: новые уязвимости публикуются ежедневно, а методы эксплуатации быстро эволюционируют. Многие пентестеры начинают с изучения CTF (Capture The Flag) — соревнований по информационной безопасности, где отрабатываются практические навыки поиска и использования уязвимостей в контролируемых условиях.

Термин «белый хакер» (white-hat hacker) используется в публичном дискурсе для обозначения специалиста, который применяет хакерские техники в законных и этичных целях — с согласия владельца системы, в рамках чётко определённого задания и без причинения вреда. Это описание морального и профессионального статуса. Все легальные пентестеры — белые хакеры. Разница между «белым» и «чёрным» хакером — в намерении и правовом контексте.

Многие крупные технологические компании (Google, Microsoft, Apple, GitHub и др.) поддерживают программы bug bounty — вознаграждения за сообщение об уязвимостях. Эти программы легализуют взаимодействие с независимыми исследователями безопасности и превращают поиск уязвимостей в прозрачную, регулируемую деятельность. Размер вознаграждения зависит от критичности найденной проблемы: от нескольких сотен долларов за незначительную конфигурационную ошибку до сотен тысяч — за уязвимости, позволяющие выполнить код на сервере или обойти двухфакторную аутентификацию в массовом сервисе.

Характер уязвимостей и методы их обнаружения​

На первый взгляд, некоторые атаки могут казаться тривиальными — например, подбор пароля методом brute force. Однако на практике современные системы защищены от грубого перебора: используются ограничения по количеству попыток, задержки, CAPTCHA, геоблокировки. Поэтому пентестеры редко полагаются на прямой подбор. Вместо этого они ищут обходные пути:

  • восстановление пароля через уязвимость в механизме «Забыли пароль?» (например, предсказуемый токен сброса, возможность перехвата письма через XSS);
  • атака на сессию (предсказуемый идентификатор, отсутствие привязки к IP/User-Agent, отсутствие инвалидации после смены пароля);
  • инъекции в SQL и в командную строку ОС (command injection), в шаблоны (template injection), в сериализованные объекты (deserialization attacks);
  • обход авторизации через прямое указание идентификатора ресурса (IDOR — Insecure Direct Object Reference), когда система не проверяет, имеет ли текущий пользователь право на доступ к /api/user/123;
  • атаки по времени (timing attacks), позволяющие извлекать данные по косвенным признакам — например, по длительности ответа сервера при проверке пароля;
  • атаки на кэширование (cache poisoning), приводящие к подмене контента для других пользователей;
  • манипуляции с JWT-токенами — подмена алгоритма, использование none, эксплуатация слабых ключей.

Процесс поиска уязвимости часто включает несколько этапов:

  1. Разведка — сбор информации: версии ПО (из заголовков, robots.txt, /.well-known/), структура API (из OpenAPI/Swagger), имена параметров (из клиентского кода), имена пользователей (из ошибок, соцсетей, почтовых заголовков);
  2. Картирование поверхности атаки — определение всех входных точек: формы, API-эндпоинты, загрузки файлов, веб-сокеты, заголовки, куки;
  3. Тестирование векторов — подстановка специальных последовательностей (например, ' OR 1=1--, <script>alert(1)</script>, ../../../../etc/passwd) и анализ реакции: изменение статуса, тела ответа, времени обработки, логов;
  4. Подтверждение и эксплуатация — если признаки уязвимости обнаружены, строится рабочий вектор, позволяющий добиться конкретного эффекта (чтение файла, выполнение команды, кража сессии);
  5. Оценка воздействия — определяется, к каким последствиям может привести уязвимость: раскрытие данных, полный контроль над сервером, компрометация других пользователей.

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

Инструменты тестирования безопасности​

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

OWASP ZAP​

OWASP Zed Attack Proxy (ZAP) — это open-source инструмент динамического анализа безопасности веб-приложений (DAST), разрабатываемый под эгидой Open Web Application Security Project. Его главная цель — сделать тестирование безопасности доступным для широкого круга специалистов: от разработчиков, желающих проверить свой код на ранних этапах, до профессиональных аудиторов, проводящих комплексные проверки.

Архитектура ZAP строится вокруг прокси-сервера, через который проходит весь трафик между клиентом (браузером) и тестируемым приложением. Это позволяет инструменту перехватывать, модифицировать, логировать и анализировать HTTP/HTTPS-сообщения в реальном времени. Прокси является центральным элементом, к которому подключаются модули:

  • Passive Scanner работает ненавязчиво: он анализирует трафик, проходящий через прокси. Он ищет признаки уязвимостей по сигнатурам — например, отсутствие заголовка Content-Security-Policy, наличие X-Powered-By, использование небезопасных методов (TRACE, OPTIONS *), утечка стек-трейсов в теле ответа. Пассивное сканирование безопасно, не создаёт нагрузки и может применяться даже в production-средах при наличии соответствующего разрешения.

  • Active Scanner генерирует серию модифицированных запросов к каждому обнаруженному эндпоинту. Для каждого параметра (в URL, теле, заголовках, куках) он последовательно подставляет тестовые векторы — например, строки для проверки SQL-инъекций (', ", 1' OR '1'='1), XSS (<script>, javascript:), path traversal (../, %2e%2e%2f). Анализ ответов строится на сравнении: изменение HTTP-статуса, рост времени ответа, появление ключевых слов («error», «exception», «syntax»), несоответствие структуры тела. Активное сканирование требует осторожности: оно может вызывать побочные эффекты (создание записей, отправка писем, сброс сессий), поэтому его применяют преимущественно в staging-средах.

  • Fuzzer — инструмент для целенаправленной генерации и отправки множества вариаций одного и того же запроса с изменением одного или нескольких полей. В отличие от Active Scan, fuzzer настраивается вручную: пользователь задаёт список полезных нагрузок (payloads), правила их подстановки (позиция, кодирование), условия остановки. Это позволяет проверять сложные сценарии: например, перебор значений заголовка Host для проверки виртуальных хостов, или подстановка JWT-токенов с разными алгоритмами и ключами.

  • Scripting Engine поддерживает написание скриптов на JavaScript (Rhino/Nashorn), которые могут встраиваться в различные этапы обработки запроса/ответа: перед отправкой (pre-send), после получения (post-receive), при сканировании, при fuzzing. Через скрипты можно реализовать кастомные проверки — например, валидацию формата API-ответов, анализ временных задержек, генерацию динамических токенов аутентификации. Возможность автоматизации логики делает ZAP пригодным для интеграции в CI/CD.

  • CLI и API обеспечивают головless-режим работы: запуск сканирования из командной строки, получение отчётов в форматах XML, HTML, Markdown, JSON. Это критично для DevSecOps-практик, где безопасность должна проверяться на каждом коммите или сборке.

ZAP особенно ценен своей открытостью и расширяемостью. Сообщество регулярно добавляет новые правила, адаптеры для фреймворков, интеграции с Jenkins, GitLab CI, GitHub Actions. Однако его автоматический сканер уступает коммерческим аналогам в точности обнаружения сложных уязвимостей и глубине анализа бизнес-логики. Поэтому ZAP чаще используется как инструмент первого прохода, а также как платформа для обучения и прототипирования.

Burp Suite​

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

Центральный элемент Burp — это Proxy, но по функциональности и удобству он значительно превосходит прокси других инструментов. Он поддерживает перехват двунаправленного трафика с возможностью модификации как запросов, так и ответов до их отправки/отображения. Интерфейс Proxy позволяет фильтровать трафик по домену, методу, статусу, содержимому; выделять интересующие запросы цветом; группировать по сессиям. Встроенная поддержка TLS-расшифровки (через установку CA-сертификата в браузер) позволяет анализировать даже зашифрованный HTTPS-трафик без дополнительных настроек.

Вокруг Proxy строится экосистема специализированных инструментов:

  • Repeater — «лаборатория для гипотез». Выбрав любой запрос из истории Proxy, можно отправить его в Repeater и многократно редактировать, наблюдая за изменениями в ответе. Это используется для пошаговой проверки инъекций, подбора параметров, анализа логики авторизации. Repeater поддерживает работу с несколькими вкладками, сравнение ответов, подсветку различий.

  • Intruder — продвинутый фuzzer с гибкой настройкой позиций замены и типов атак. Поддерживаются четыре режима: Sniper (один payload в одном месте), Battering ram (один payload во всех местах), Pitchfork (параллельная подстановка разных списков), Cluster bomb (декартово произведение payload-списков). Intruder позволяет генерировать миллионы комбинаций, фильтровать ответы по статусу, размеру, содержимому, автоматически извлекать значения (например, токены из ответа для последующей подстановки).

  • Sequencer анализирует качество генераторов случайных значений: сессионных ID, токенов CSRF, паролей сброса. Он собирает тысячи значений, проводит статистические тесты (монобит, частота блоков, автокорреляция) и оценивает энтропию. Низкая энтропия означает предсказуемость — а значит, возможность подбора или восстановления предыдущих/будущих значений.

  • Scanner (Pro-версия) — автоматический модуль, отличающийся чрезвычайно низким уровнем ложных срабатываний. Он использует технологию контекстно-зависимого анализа: понимает структуру HTML, JSON, XML; отслеживает зависимости между запросами (например, получение токена → его использование в следующем запросе); строит модель приложения как граф состояний. Благодаря этому Scanner способен обнаруживать уязвимости, недоступные для сигнатурных сканеров: DOM-based XSS, сложные CSRF-цепочки, business-logic flaws.

  • Extensions — механизм расширения функциональности на Python, Java или через Burp API. Существуют тысячи community-расширений: от декодеров и валидаторов до интеграций с Shodan, VirusTotal, Jira. Разработчики могут писать свои плагины для специфичных задач — например, для автоматизации тестирования GraphQL-эндпоинтов или анализа WebSockets.

Burp Suite не является «установил и забыл» — он требует глубокого понимания веб-протоколов и методов атак. Но именно эта глубина делает его незаменимым при проведении серьёзных аудитов, особенно в gray- и white-box режимах.

SQLmap​

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

Основной принцип работы — адаптивное тестирование. SQLmap не просто отправляет список заранее заданных векторов. Он сначала определяет, поддаётся ли параметр инъекции вообще (например, через time-delay или boolean-различия), затем выясняет тип СУБД (по особенностям синтаксиса, ошибок, поведения), после чего подбирает оптимальную технику эксплуатации:

  • Error-based — вызывает генерацию ошибок СУБД, в которых содержится часть данных (например, имя таблицы);
  • Union-based — использует оператор UNION SELECT для добавления собственных запросов и получения результата в теле веб-страницы;
  • Boolean-based blind — проверяет истинность условий по изменению содержимого страницы (например, AND 1=1 vs AND 1=2);
  • Time-based blind — измеряет задержку ответа при выполнении условий с SLEEP() или аналогами;
  • Out-of-band — использует DNS- или HTTP-запросы из контекста СУБД для передачи данных (актуально при полной слепоте).

После подтверждения уязвимости SQLmap может автоматически:

  • перечислить базы данных, таблицы, столбцы;
  • извлечь содержимое таблиц (частично или полностью);
  • загрузить файлы с сервера (--file-read);
  • записать файлы на сервер (--file-write);
  • получить оболочку ОС (--os-shell) — если СУБД запущена с правами, позволяющими выполнение системных команд (например, xp_cmdshell в MSSQL).

SQLmap поддерживает обход WAF/IPS: кодирование полезной нагрузки в hex, unicode, комментарии, случайные регистры, добавление лишних пробелов и null-байтов. Он также умеет работать с токенами CSRF, сессионными куками, HTTP-аутентификацией, прокси.

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

Nessus​

Nessus, разрабатываемый компанией Tenable, представляет собой класс сетевого сканера уязвимостей (vulnerability scanner), ориентированного на окружение, в котором он работает. Если ZAP и Burp тестируют поведение приложения, то Nessus проверяет состояние инфраструктуры: серверов, сетевых устройств, баз данных, сервисов.

Nessus работает по клиент-серверной модели: ядро (Nessus Scanner) выполняет проверки, а веб-интерфейс (Tenable.io или локальный Nessus Manager) управляет заданиями и визуализирует результаты. Сканер подключается к целевым хостам по IP-адресу, определяет открытые порты (через TCP/UDP-сканирование), идентифицирует сервисы (по баннерам, сигнатурам, поведению), а затем применяет к ним соответствующие плагины — более чем 80 000 проверок, регулярно обновляемых.

Плагины Nessus делятся на категории:

  • Discovery — определение ОС, версий ПО, типов устройств;
  • Configuration — проверка настроек: слабые пароли по умолчанию, ненужные сервисы, избыточные права;
  • Vulnerability — обнаружение известных уязвимостей по CVE, эксплуатируемых удалённо без аутентификации;
  • Compliance — аудит на соответствие стандартам (PCI DSS, CIS Benchmarks, HIPAA, NIST): например, проверка длины паролей, шифрования дисков, логирования;
  • Malware — поиск следов компрометации: подозрительные процессы, известные хеши вредоносов.

Особенно ценна функция Authenticated Scanning: при предоставлении учётных данных (локального администратора, SSH-ключа) Nessus получает доступ к файловой системе, реестру Windows, конфигурационным файлам и может проводить глубокую проверку — например, обнаружить уязвимую версию библиотеки, даже если она не экспонируется наружу, или проверить, установлены ли патчи безопасности (patch audit).

Nessus не заменяет DAST-инструменты, но дополняет их. Пример типичного сценария:
— Сначала Nessus сканирует сеть и находит, что на сервере 192.168.1.10 работает Apache 2.4.29 (уязвимость CVE-2018-1312 — mod_auth_digest remote DoS).
— Затем Burp Suite тестирует веб-приложение на этом сервере и обнаруживает SQL-инъекцию в /search.
— Эксплуатация инъекции через SQLmap позволяет выполнить команды ОС.
— Через Nessus уже известно, что ядро Linux устарело и содержит локальную уязвимость эскалации привилегий (CVE-2021-4034 — PwnKit).
— Комбинация этих уязвимостей даёт полный контроль над сервером.

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

Интеграция тестирования безопасности в жизненный цикл разработки​

Эффективное тестирование безопасности невозможно в виде разовой «проверки перед релизом». Для снижения стоимости исправления и повышения качества защиты процесс должен быть встроен в каждый этап жизненного цикла — от проектирования до эксплуатации. Это достигается через практики DevSecOps.

На этапе проектирования​

Проводится Threat Modeling — систематический анализ архитектуры на предмет потенциальных угроз. Используются методики STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) или PASTA (Process for Attack Simulation and Threat Analysis). Результат — карта угроз с указанием активов, границ доверия, потенциальных атакующих, векторов и мер контроля. Эта карта становится основой для требований к безопасности и определяет, какие виды тестирования потребуются позже.

На этапе разработки​

  • SAST (Static Application Security Testing) анализирует исходный код на наличие небезопасных конструкций (например, eval(), конкатенация строк в SQL, отсутствие валидации входных данных). Хотя SAST выходит за рамки данной главы, важно отметить, что он дополняет DAST: SAST находит ошибки в коде, DAST — ошибки в поведении.
  • Разработчики запускают локальные сканеры (например, ZAP в passive mode) во время отладки, чтобы сразу видеть предупреждения.
  • Пишутся security unit/integration tests: проверка прав доступа, валидации входных данных, обработки ошибок.

На этапе CI/CD​

В конвейер сборки и развёртывания интегрируются:

  • автоматический DAST-скан (например, ZAP CLI) против staging-окружения;
  • проверка зависимостей на наличие известных уязвимостей (OWASP Dependency-Check, Snyk, Trivy);
  • сканирование контейнерных образов (Clair, Anchore);
  • проверка конфигураций IaC (Terraform, Ansible) на антипаттерны безопасности (Checkov, tfsec).

Если сканер находит критическую уязвимость (например, RCE), сборка прерывается — security gate не пройден.

На этапе эксплуатации​

  • Регулярное внешнее сканирование (еженедельно/ежемесячно) для выявления деградации защиты (например, после обновления ПО);
  • Периодические пентесты (раз в 6–12 месяцев или после крупных изменений);
  • Мониторинг угроз (threat intelligence): отслеживание новых CVE, связанных с используемыми технологиями;
  • Инцидент-реагирование: использование знаний, полученных при тестировании, для настройки правил SIEM/WAF.

Работа с результатами​

Отчёт о тестировании безопасности должен содержать не просто список уязвимостей, а:

  • Техническое описание: как воспроизводится проблема, какие запросы/ответы участвуют;
  • Контекст риска: к каким данным/функциям ведёт эксплуатация, возможные последствия;
  • Рекомендации по исправлению: конкретные шаги — например, «используйте параметризованные запросы вместо конкатенации строк в методе SearchRepository.Find()»;
  • Доказательства: скриншоты, логи, снифферы трафика (в зашифрованном виде при передаче заказчику);
  • Уровень критичности, рассчитанный по CVSS (Common Vulnerability Scoring System) или внутренней шкале.

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