Тестирование безопасности — QA — Собеседование

JuniorТеорияОчень часто

Чем тестирование аутентификации и авторизации различается?

Аутентификация проверяет, кто вы: login, MFA, выпуск токена, блокировка, сброс пароля. Авторизация проверяет, что вам разрешено: роли, владение, доступ к каждому объекту. Баг, который тестировщик реально ловит, — это авторизация: смените id в запросе и прочтите чужую запись (IDOR) или дойдите до admin-эндпоинта обычным пользователем.

Типичные ошибки

✗Менять определения местами — аутентификация это кто, авторизация это что
✗Верить, что UI спрятал действие, когда эндпоинт всё ещё его авторизует
✗Упускать IDOR — что смена id открывает данные другого пользователя

Уточняющие вопросы

→Как проверить IDOR, имея два обычных аккаунта?
→Почему авторизацию всегда проверяют на API, а не в UI?

JuniorТеорияОчень часто

Что такое OWASP Top 10 и как тестировщик его использует?

OWASP Top 10 — это поддерживаемый сообществом ранжированный список самых критичных рисков безопасности веб-приложений: broken access control, инъекции, криптографические сбои и другие. Это база осведомлённости, а не сертификация: тестировщик берёт его как общий словарь и перечень того, что прощупывать в каждом релизе.

Типичные ошибки

✗Считать список сертификацией, которую проходят, а не базой осведомлённости
✗Думать, что это запускаемый инструмент, а не каталог рисков для проверки
✗Полагать, что отметка всех десяти пунктов снимает нужду в проверках

Уточняющие вопросы

→Назовите три категории из актуального OWASP Top 10.
→Почему broken access control так высоко в последних редакциях?

MiddleДизайнЧасто

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

Прощупывайте через proxy, внедряя SQL-метасимволы: одиночную кавычку, чтобы вызвать ошибку базы, затем ' OR 1=1--, затем payload с задержкой вроде sleep. Свидетельство — утёкшая SQL-ошибка, изменённая выборка или измеримая задержка, доказывающая, что ввод доходит до запроса. Исправление, о котором вы сообщаете, — параметризованные запросы, а не экранирование в UI и не WAF.

Типичные ошибки

✗Называть исправлением санитизацию ввода или WAF вместо параметризованных запросов
✗Думать, что QA чинит инъекцию, тогда как он её прощупывает и сообщает
✗Ждать видимого изменения страницы, упуская сигналы по ошибке и по времени

Уточняющие вопросы

→Как payload по времени подтверждает инъекцию, когда ничего не выводится?
→Почему параметризованные запросы останавливают инъекцию там, где экранирование нет?

MiddleДизайнЧасто

Вы тестируете работу с сессиями в банковском веб-приложении. Пользователь может войти на нескольких устройствах, сменить пароль и выйти. Опишите проверки безопасности сессий, которые вы проведёте — покрывая idle- и абсолютный таймаут, что именно logout обязан сделать на сервере, session fixation и флаги cookie — и что провал каждой проверки даст злоумышленнику.

Убедитесь, что idle- и абсолютный таймаут завершают сессию. Проверьте, что logout инвалидирует её на сервере, а не просто удаляет cookie, чтобы перехваченный токен умер. Проверьте, что session id ротируется при входе и при смене привилегий против fixation, и что cookie несут HttpOnly, Secure и SameSite. Наконец, убедитесь, что политика одновременных сессий работает ровно как задумано.

Типичные ошибки

✗Думать, что logout делается на клиенте, а не инвалидируется на сервере
✗Упускать session fixation — id обязан ротироваться при входе и смене привилегий
✗Опускать или неверно читать флаги cookie HttpOnly, Secure и SameSite

Уточняющие вопросы

→Как доказать, что logout убил сессию на сервере, а не только cookie?
→Что такое session fixation и какое действие обязано ротировать id?

MiddleДизайнЧасто

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

Внедрите безобидный маркер вроде тега <script> или картинки с onerror и посмотрите, выполнится ли он вместо показа как текст. Шапка — это stored XSS, отражённый поиск — reflected, а сборка DOM из фрагмента URL — DOM-based. Исправление, которое вы запросите, — контекстно-зависимое кодирование вывода (HTML-тело, атрибут, JS и URL различаются) с CSP как эшелонированной защитой.

Типичные ошибки

✗Прописывать чёрный список ввода вместо контекстного кодирования вывода
✗Считать любой XSS одним типом, упуская stored, reflected и DOM-based
✗Верить, что HTTPS или WAF мешают XSS исполниться в браузере

Уточняющие вопросы

→Почему кодирование различается между HTML-телом и JS-контекстом?
→Что добавляет Content-Security-Policy, когда кодирование уже есть?

MiddleТеорияИногда

Где заканчивается проверка безопасности QA и где начинается пентест?

Проверка безопасности QA — это скриптовая проверка на релизе, что известные контроли держатся: доступ, обработка ввода, сессии, базовый набор OWASP; с обычным аккаунтом и с отчётом о подозрении на дефект. Пентест — авторизованная состязательная работа: специалисты связывают и эксплуатируют неизвестные слабости, доказывая реальный ущерб, периодически.

Типичные ошибки

✗Думать, что тестировщик проводит полный пентест с эксплойтами каждый релиз
✗Считать пентест просто автоматическим сканером, запускаемым раз в год
✗Путать сообщение о подозрении на дефект с доказательством ущерба через эксплойт

Уточняющие вопросы

→Какой доступ или согласование есть у пентестера, но нет у тестировщика на релизе?
→Какие проверки из базового OWASP остаются задачей тестировщика, а не пентестера?

MiddleДизайнИногда

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

Прогоните сценарии с PII — регистрация, вход, оплата, правка профиля, ошибочные пути, — затем ищите в хранилище точные введённые значения. Маскирование пройдено, только если поле редактируется везде: на каждом уровне, включая debug и stack trace, в телах, URL и у внешнего вендора. Читаемое значение где угодно — дефект, и частичное маскирование, опознающее человека, — тоже.

Типичные ошибки

✗Проверять только уровень INFO и счастливый путь, пропуская debug и stack trace
✗Считать шифрование на диске заменой редактированию самих значений
✗Принимать частичное маскирование, всё ещё опознающее человека

Уточняющие вопросы

→Как поймать PII, которое появляется только в stack trace ошибки?
→Почему копия у внешнего лог-вендора входит в область этой проверки?

MiddleТеорияРедко

Что такое фаззинг и какого рода баги он находит?

Фаззинг забрасывает в интерфейс искажённый, случайный и граничный ввод и следит за падениями, ответами 500, stack trace и зависаниями. Его оракул — не верен ли вывод, а падает ли и течёт ли, поэтому он находит случаи, которые ваш набор тестов не вообразил. Coverage-guided фаззеры мутируют ввод в сторону новых путей кода, загоняя программу в более глубокие состояния.

Типичные ошибки

✗Думать, что оракул — корректность вывода, а не падение-или-утечка
✗Путать фаззинг с нагрузочным тестированием или статическим анализом
✗Считать случайный ввод бесполезным без известного ожидаемого результата

Уточняющие вопросы

→Какие сигналы вы отслеживаете, пока работает фаззер?
→Чем coverage-guided фаззер отличается от чисто случайного ввода?

SeniorДизайнРедко

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

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

Типичные ошибки

✗Удалять только из основной базы и верить, что реплики подтянутся сами
✗Принимать флаг мягкого удаления как удовлетворение права на удаление
✗Закрывать по тикету инженерии без свидетельства из каждого хранилища

Уточняющие вопросы

→Как поступить с данными субъекта в неизменяемом бэкапе, который нельзя избирательно править?
→Почему обезличенные строки аналитики всё ещё рискуют провалить запрос на удаление?