Умение запустить автоматизированный сканер или скопировать полезную нагрузку из готовой базы данных не делает специалиста пентестером. Настоящая ценность проявляется в момент, когда стандартный инструмент ломается, и приходится понимать, как именно база данных или браузер интерпретируют каждый байт запроса.
Уязвимость межсайтового скриптинга часто сводится кандидатами к простой краже сессионных идентификаторов. Интервьюер немедленно усложняет условие, сообщая о наличии флага HttpOnly у всех куки. Стандартная реакция заключается в растерянности или предложении загрузить вредоносный файл на устройство жертвы. Подобный ответ демонстрирует поверхностное понимание возможностей исполняемого кода в браузере.
Флаг HttpOnly действительно блокирует чтение значения через свойство document.cookie. Механизм никак не ограничивает способность скрипта взаимодействовать с DOM-деревом страницы или инициировать сетевые запросы. Браузер автоматически прикрепляет защищенные куки ко всем исходящим запросам в пределах домена, независимо от источника инициации. Злоумышленник использует уязвимость для подмены атрибута action у формы авторизации, перенаправляя вводимые пользователем учетные данные на подконтрольный сервер. Альтернативный сценарий предполагает внедрение кейлоггера, перехватывающего нажатия клавиш до момента отправки формы. Третий вариант заключается в выполнении фоновых запросов через fetch для изменения настроек аккаунта. Сервер обрабатывает такие запросы как легитимные, поскольку браузер автоматически подставляет валидные сессионные данные.
SQL-инъекции и механика параметризованных запросов
Кандидаты уверенно описывают процесс эксплуатации инъекций типа Union-based. Они знают методику использования ORDER BY для определения количества столбцов и помнят про системные таблицы information_schema. Глубина понимания проверяется вопросами о менее очевидных техниках или механизмах защиты.
Типичная ошибка заключается в незнании термина Stacked Queries. Специалист может догадаться, что точка с запятой позволяет выполнить вторую команду, но не понимает зависимости этой возможности от конкретного драйвера базы данных. В MySQL поддержка множественных запросов в одном вызове часто отключена по умолчанию в целях безопасности. В Microsoft SQL Server такая возможность является стандартным поведением, открывая путь к выполнению системных команд через xp_cmdshell.
Еще более критичным пробелом выступает неумение объяснить архитектурный метод защиты. Описание принципа параметризованных запросов часто сводится к расплывчатому упоминанию специальных функций. Защита работает иначе. База данных сначала компилирует шаблон запроса и строит план его выполнения. Данные пользователя передаются отдельно и обрабатываются строго как литералы.
# Уязвимый код: конкатенация строк
query = "SELECT * FROM users WHERE username = '" + user_input + "'"
cursor.execute(query)
# Защищенный код: параметризованный запрос
query = "SELECT * FROM users WHERE username = %s"
cursor.execute(query, (user_input,))В первом случае интерпретатор базы данных воспринимает введенные данные как часть исполняемой инструкции. Во втором случае драйвер передает структуру запроса и данные раздельно, гарантируя, что пользовательский ввод будет обработан исключительно как строковое значение, а не как команда. Разделение этапа компиляции и этапа передачи данных делает инъекцию технически невозможной.
Атаки на JWT и смешение алгоритмов шифрования
Тема JSON Web Token часто сводится к знанию структуры из трех частей и упоминанию возможности брутфорса слабого секретного ключа. Подобный уровень знаний недостаточен для прохождения собеседования. Интервьюеры ожидают понимания специфичных атак на реализацию стандарта.
Классический вопрос касается атаки через алгоритм none. Спецификация JWT позволяет указывать алгоритм подписи в заголовке токена. Некоторые уязвимые библиотеки читают этот заголовок и, встретив значение none, полностью отключают проверку криптографической подписи. Атакующий меняет алгоритм в заголовке на none, модифицирует полезные данные и удаляет часть подписи. Сервер, доверяя заголовку, принимает подделку как валидный токен.
Более сложный сценарий предполагает атаку на смешение алгоритмов. Если сервер поддерживает как симметричный HS256, так и асимметричный RS256, злоумышленник подменяет алгоритм в заголовке с RS256 на HS256. Затем он подписывает модифицированный токен, используя публичный ключ сервера в качестве симметричного секрета. Сервер, ожидая проверку по алгоритму HS256, успешно верифицирует подпись, так как публичный ключ доступен ему самому. Подобная архитектурная ошибка полностью нивелирует преимущества асимметричного шифрования.
Ошибки бизнес-логики и аргументация через метрики CVSS
Автоматизированные сканеры уязвимостей часто пропускают ошибки бизнес-логики. Такие дефекты возникают из-за неверного проектирования процессов, а не из-за синтаксических ошибок в коде. Запрос выглядит абсолютно валидным с технической точки зрения. Сервер успешно его обрабатывает. Проблема кроется в том, что разрешенное действие нарушает бизнес-правила приложения. Финансовые операции часто уязвимы к манипуляциям с отрицательными значениями. Пользователь инициирует перевод отрицательной суммы на свой счет. Сервер вычитает отрицательное значение из баланса получателя и прибавляет его к балансу отправителя. В результате баланс отправителя увеличивается. Разработчики забывают добавить проверку на то, что сумма перевода должна быть строго больше нуля.
Техническая часть составляет лишь половину требований к специалисту. Вторая половина касается умения отстаивать свои находки перед бизнесом. Типичный кейс на собеседовании звучит так: найдена критическая уязвимость во внутреннем сервисе. Разработчики просят понизить оценку до средней, чтобы не блокировать завтрашний релиз, обещая исправить всё в следующем спринте. Неопытный кандидат часто отвечает уклончиво или соглашается пойти навстречу. Подобная позиция демонстрирует непонимание роли пентестера. Соглашаясь на понижение оценки, специалист берет на себя ответственность за потенциальный инцидент. Если сервис взломают, в отчете о расследовании будет указано, что уязвимость была известна, но ее критичность была занижена.
Правильный подход опирается на объективные метрики. Калькулятор CVSS предоставляет четкие критерии. Ключевым аргументом здесь выступает метрика Scope. Если уязвимость в одном компоненте позволяет скомпрометировать другой компонент с другими границами безопасности, параметр Scope меняется с Unchanged на Changed. Это изменение математически поднимает базовый балл до уровня High или Critical, независимо от того, находится сервис во внутренней сети или нет. Пентестер должен представить разработчикам этот расчет и полную цепочку атаки.
Чек-лист подготовки и смена парадигмы обучения
Переход от уровня новичка к уверенному джуну требует смены парадигмы обучения. Вместо механического запоминания полезных нагрузок необходимо фокусироваться на понимании протоколов и архитектуры приложений.
[√] Изучение спецификаций протоколов. Понимание того, как именно браузер обрабатывает куки, как работает механизм CORS или как формируется HTTP-запрос, дает преимущество перед теми, кто полагается только на инструменты.
[√] Глубокий анализ инструментов. Знание того, как именно автоматизированные средства определяют тип базы данных или как прокси обрабатывает макросы, позволяет эффективно использовать эти инструменты в нестандартных ситуациях.
[ ] Практика объяснения сложных концепций. Умение объяснить механику SQL-инъекции или XSS человеку без технического бэкграунда за две минуты является отличным индикатором глубины собственного понимания.
[x] Избегание зависимости от готовых решений. Решение лабораторных работ без подглядывания в ответы формирует навык самостоятельного анализа и дедукции, который критически важен в реальных проектах.
Теоретические знания редко учитывают наличие веб-брандмауэров или систем обнаружения вторжений. На практике полезная нагрузка, идеально работающая в локальной лаборатории, мгновенно блокируется корпоративным WAF. Профессионал тратит время на анализ ответов сервера, подбор обходных техник и фаззинг, чтобы доказать, что уязвимость эксплуатируема даже в защищенной среде. Демонстрация обхода фильтрации добавляет находке весомости и показывает заказчику, что проблема требует архитектурных изменений, а не простого добавления нового правила в черный список.