Безопасность: вопросы для собеседования QA

Аутентификация подтверждает личность пользователя (ты — это ты), авторизация определяет его права в системе (что тебе разрешено).

JWT (JSON Web Token) — компактный формат токена: три части через точку — header (алгоритм подписи), payload (claims: sub, exp, iat, roles), signature. Сервер верифицирует подпись без обращения к БД.

Из практики: при тестировании JWT проверяю: токен принимается только с валидной подписью; истёкший токен (exp) отклоняется; права из claims реально ограничивают доступ к ресурсам.

Идентификация — это ответ на вопрос «кто пытается войти».

Аутентификация подтверждает личность, а авторизация определяет, что этому пользователю разрешено делать в системе.

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

Основные виды: по паролю, по одноразовому коду, по аппаратному ключу, по биометрии и комбинированные схемы MFA.

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

Из практики: при тестировании важно проверять не только успешный вход, но и восстановление доступа, блокировки и повторные попытки.

Чаще всего в продуктах встречаются ролевая, атрибутная и ресурсная модели авторизации.

QA проверяет не только «доступ есть/нет», но и границы прав для каждой роли в каждом чувствительном действии.

Из практики: больше всего дефектов нахожу на переходах ролей и в редких комбинациях прав.

Анонимизация — необратимая замена реальных данных: имён, телефонов, email — на синтетические значения. Маскирование — частичное скрытие: иванов@mail.ru → и***@mail.ru.

На практике применяю: faker-библиотеки для генерации синтетических данных, маскирование в SELECT-запросах перед выгрузкой в тестовую среду, обфускацию через скрипты миграции.

Из практики: критично проверять, что маскировка применяется везде — в БД, API-ответах, логах и резервных копиях, иначе утечка ПДн остаётся через побочные каналы.

Authorization Code Flow: фронт получает code, обменивает его на токен через бэкенд. Секрет клиента не попадает в браузер — безопасно для серверных приложений и SPA с PKCE.

PKCE (Proof Key for Code Exchange) — расширение Authorization Code Flow для публичных клиентов (SPA, мобильные): code_verifier генерируется клиентом, code_challenge отправляется на сервер. Без PKCE Authorization Code уязвим для перехвата. Implicit Flow (устаревший) выдаёт токен напрямую в URL браузера — небезопасно.

Из практики: для новых проектов Authorization Code + PKCE — стандарт. При тестировании проверяю, что Authorization Code нельзя использовать дважды и что PKCE не обходится при его отсутствии.

XSS-проверки показывают, можно ли выполнить вредный скрипт через пользовательский ввод или сохранённые данные.

CSRF-проверки подтверждают, что критичные действия защищены токеном и проверкой происхождения запроса, а CSP ограничивает загрузку опасного контента.

Из практики: базовый набор проверок XSS/CSRF/CSP даёт быстрый сигнал о рисках ещё до полноценного аудита.

Проверяю, что персональные поля маскируются устойчиво и не восстанавливаются через косвенные признаки (комбинации полей, временны́е метки).

Смотрю, что маскировка применяется во всех точках: основная БД, аналитические хранилища, API-ответы, журналы событий и резервные копии.

Из практики: самая частая ошибка — маскируют данные в продовой БД, но забывают про резервные копии и аналитический DWH. Проверяю все каналы утечки, а не только основную базу.

SQL-инъекция — это атака, когда злоумышленник подставляет в пользовательский ввод фрагмент SQL, и сервер исполняет его, потому что запрос строится конкатенацией строк.

Защита: всегда использовать параметризованные запросы (prepared statements). Параметры передаются отдельно от текста запроса, и СУБД никогда не интерпретирует их как код.

Из практики: при ревью кода первое, на что смотрят — есть ли «склейка» строк в SQL. Любое "SELECT * FROM users WHERE name = '" + name + "'" — потенциальная инъекция.

OWASP Top 10 — это список наиболее распространённых угроз для веб-приложений, обновляемый раз в несколько лет. Текущая версия включает Broken Access Control, Injection, Cryptographic Failures, Insecure Design и др.

QA использует его как чек-лист: проверить наиболее частые уязвимости (SQL-инъекции, XSS, неавторизованный доступ, утечка чувствительных данных, небезопасные настройки).

Из практики: даже без отдельного security-инженера базовая проверка по OWASP Top 10 ловит большинство уязвимостей, которые потом нашли бы при пентесте.

XSS (Cross-Site Scripting) — это уязвимость, при которой злоумышленник внедряет JavaScript в страницу, и он выполняется в браузере других пользователей.

Виды: stored (вредоносный код сохраняется в БД — например, в комментарии, и выполняется у всех, кто смотрит), reflected (код приходит в URL и отражается в ответе), DOM-based (внедрение через клиентский JS без участия сервера).

Из практики: защита — экранировать вывод во всех местах, использовать CSP, отказаться от innerHTML с пользовательскими данными. QA проверяет вставку <script>alert(1)</script>, ' onerror=alert(1)>, javascript: ссылок.

CSRF (Cross-Site Request Forgery) — это атака, при которой пользователь, авторизованный на сайте A, заходит на вредоносный сайт B, и B отправляет запрос на A от имени пользователя (потому что cookies автоматически прикрепляются).

Защита: CSRF-токен (уникальный для каждой сессии/формы), SameSite cookies (Lax или Strict), проверка заголовков Origin/Referer, использование Authorization header вместо cookies для API.

Из практики: для современных SPA с JWT в localStorage CSRF менее актуален. Для классических серверных рендеров с session cookie — обязательная защита.

Горизонтальная привилегия: может ли user A прочитать/изменить данные user B (типичный IDOR — Insecure Direct Object Reference). Подменяем ID в URL/тело запроса и проверяем доступ.

Вертикальная: может ли обычный пользователь выполнить админскую операцию. Запрашиваем admin-эндпоинт с обычным токеном.

Из практики: также проверяют — истекает ли токен, отзывается ли при logout, работают ли refresh-токены, не утекают ли они в логи/ссылки/реферер.

Инжекция — это внедрение управляющих конструкций интерпретатора в данные. SQL-инжекция (в БД), Command injection (в shell), LDAP-инжекция, NoSQL-инжекция, OS-команды через path/file, шаблонные инжекции (SSTI).

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

Из практики: защита — параметризованные запросы, экранирование на уровне библиотеки, белые списки допустимых значений. QA проверяет специальные символы интерпретатора и реакцию.

Это ситуация, когда чувствительные данные (пароли, токены, персональные данные, банковские реквизиты) попадают туда, куда не должны: в логи, в URL, в кеш CDN, в публичный API, в нешифрованной БД.

Тесты: открыть DevTools и посмотреть сетевые ответы — нет ли там лишних полей. Поискать пароли в логах. Проверить, что cookies с токеном помечены HttpOnly и Secure.

Из практики: типовая проблема — API возвращает объект пользователя целиком, включая hash пароля и внутренние ID. Также: пароли в URL (через GET), личные данные в localStorage.

Тип файла: что приходит — реально картинка или маскированный исполняемый файл (проверяют по magic bytes, не только по расширению). Размер: попытка залить 1ГБ — обработает или зависнет. Имя: путь обхода (../../etc/passwd), специальные символы.

Содержимое: SVG может содержать JS, документ — макросы. Двойные расширения (file.jpg.php). Безопасное хранение — на отдельном домене, без выполнения серверных скриптов.

Из практики: типовые уязвимости — загрузка веб-шелла, обход через case-sensitivity (.PHP), MIME-spoof. Тесты на формат, размер, имя, проверка серверной валидации.

Это HTTP-заголовки, которыми сервер сообщает браузеру правила безопасности. Главные: Content-Security-Policy (откуда грузить скрипты), Strict-Transport-Security (только HTTPS), X-Frame-Options (запретить встраивание в iframe), X-Content-Type-Options: nosniff, Referrer-Policy.

Также важны Set-Cookie с флагами HttpOnly, Secure, SameSite, и Permissions-Policy для управления API (камера, гео).

Из практики: тестировщик проверяет наличие через DevTools или утилиты вроде securityheaders.com. Их отсутствие — типичная находка пентеста.

Сценарии: 10 неправильных паролей подряд — блокировка/задержка/капча? Спам OTP — ограничивает ли по email/телефону/IP? API: 1000 запросов за минуту — какие коды и через какое время?

Также проверяют, что лимиты применяются на правильном слое (по пользователю, не только по IP — иначе обход через несколько IP).

Из практики: rate limiting должен быть на критичных эндпоинтах (логин, OTP, регистрация, восстановление, платежи). Отсутствие — типовая уязвимость, ведущая к brute force и SMS-бомбингу.

Базовые позиции: новые эндпоинты — есть ли авторизация и привилегии; новые поля в API — нет ли лишних данных; новые формы — нет ли XSS, инжекций, загрузки файлов без валидации; новые токены — корректная ротация.

Также: обновление зависимостей с известными уязвимостями (npm audit, snyk), security-headers, корректная работа на HTTPS, защита от CSRF на изменяющих запросах.

Из практики: хорошо помогает специальный smoke security-check для каждого релиза — 20-30 минут проверки наиболее частых ошибок.

Самая частая категория уязвимостей. Включает: IDOR (доступ к чужим объектам по ID), отсутствие проверки роли, обход path через ../, доступ к админ-эндпоинтам без авторизации.

Тестируют: меняют ID в URL/body, удаляют токен или меняют на чужой, идут на админ-эндпоинты с обычным токеном.

Из практики: типовая ошибка разработчиков — проверять права на UI и забывать на API. Тест через прямой API быстро находит.

JWT — это токен с header, payload, signature, кодированный в base64. Сервер подписывает, клиент хранит и отправляет в Authorization header.

Подводные камни: alg=none (отказ от проверки подписи), плохая ротация ключей, утечка (нельзя отозвать без blacklist), несовершенство в content (PII в открытом payload).

Из практики: payload не шифруется, base64 = читаемый. Не кладите туда чувствительные данные. Для отзыва нужен blacklist или короткий TTL + refresh-токены.

OAuth 2.0 — протокол делегирования авторизации. Роли: Resource Owner (пользователь), Client (приложение), Authorization Server (выдаёт токены), Resource Server (хранит данные).

Flows: Authorization Code (с PKCE) для web/mobile, Client Credentials для server-to-server, Device Code для TV.

Из практики: в 2025 году implicit и password flow считаются устаревшими. Authorization Code + PKCE — рекомендованный для большинства приложений.

Type confusion: подмена числа на строку, объекта на массив, расширение JSON-payload неожиданными полями. Если бэкенд не валидирует — ведёт к багам и уязвимостям.

В NoSQL injection в Mongo: подмена строки на {$ne: null} обходит проверку пароля.

Из практики: всегда проверяйте, что бэкенд строго валидирует типы. Тесты на инъекцию объектов в JSON-параметры — обязательная часть security-чека.

Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy.

Проверяют через DevTools или утилиты типа securityheaders.com.

Из практики: отсутствие — типовая находка пентеста. Подключают обычно через reverse proxy (nginx, Cloudflare) или middleware.

Тип: magic bytes vs расширение (PHP под видом jpg). Размер: 1ГБ загрузка. Имя: path traversal (../../etc/passwd), специальные символы.

Содержимое: SVG с JS, Word с макросами. Двойные расширения file.jpg.php. Серверная сторона: где хранится, выполняется ли как код.

Из практики: классическая уязвимость — загрузка web-shell на сервер с PHP/Java. Защита — хранить на отдельном домене, не выполнять, проверять magic bytes.

Rate limiting ограничивает количество запросов от одного источника за время. Защищает от brute force, DDoS, бот-абуза.

Тестируют: 100 запросов за секунду — какой код? через какое время восстанавливается? применяется по IP, user, token? Обход через proxy/Tor?

Из практики: правильное rate limiting часто ставится на reverse proxy (nginx, Cloudflare) или API gateway. На уровне приложения — Redis-based счётчик.

Pentest — структурированная попытка взлома системы внешними или внутренними тестерами. Имитация атаки.

Security review — анализ кода, архитектуры, конфигурации на соответствие практикам безопасности. Без попытки эксплуатации.

Из практики: оба нужны. Review раз в квартал, pentest раз в год + перед мажорными релизами. Лучше — несколько pentest-команд для разнообразия взгляда.

Scope — это permissions, которые запрашивает Client от Resource Owner: read:profile, write:posts. User соглашается на конкретные.

Audience (aud) — кому предназначен токен. Защищает от подделки: токен для одного API не сработает на другом.

Из практики: scope позволяет minimum privilege (запрашивать только нужное). Тестируют: соответствует ли поведение scope, обработка отказа в части прав.

Идентификация — «кто ты говоришь, что есть» (логин, email). Аутентификация — проверка, что ты действительно тот (пароль, токен, биометрия, 2FA). Авторизация — что тебе разрешено делать (доступ к ресурсу, операции).

Последовательность: идентификация → аутентификация → авторизация. Без аутентификации авторизация бессмысленна.

Из практики: путаница ведёт к 401 vs 403 ошибкам, неправильным сообщениям пользователю и архитектурным дырам.

Basic Auth — логин/пароль в Base64 в заголовке. Простая, но небезопасная без HTTPS, нет ротации. API key — статичный ключ в заголовке/query. Простой, но не подходит для пользовательских сценариев. JWT — самодостаточный токен (header.payload.signature), не требует серверного состояния. OAuth 2.0 — фреймворк делегированной авторизации (вход «через Google»). OIDC — слой identity поверх OAuth2 (стандартизированный id_token). mTLS — взаимная аутентификация через сертификаты, машинно-машинная.

Выбор зависит от сценария: межсервисное API — API key или mTLS. Пользовательский веб — OAuth2/OIDC. Внутренний микросервис — mTLS или JWT.

Из практики: JWT — самый перепутанный. Это формат токена, а не механизм аутентификации. JWT удобен в OAuth/OIDC, но не сам по себе.

Шифрование — преобразование данных так, что прочитать может только тот, у кого есть ключ. Симметричное — один и тот же ключ для шифрования и расшифровки (AES). Быстро, но проблема — как безопасно передать ключ.

Асимметричное — пара ключей (публичный/приватный). Шифруют публичным, расшифровывают приватным. RSA, ECC. Медленнее, но решает проблему обмена ключами.

Из практики: чаще всего используют гибрид. TLS handshake — асимметричное, чтобы согласовать сессионный ключ, потом весь трафик — симметричное. Получаем скорость + безопасный обмен.

Хэширование — одностороннее преобразование данных в строку фиксированной длины (хэш). Из хэша нельзя восстановить исходные данные. Изменение байта — изменение хэша.

Отличие от шифрования: шифрование обратимо (есть расшифровка), хэширование — нет. Используется для проверки целостности (checksums), хранения паролей (bcrypt, argon2), индексации, цифровых подписей.

Из практики: пароли хранят как хэш с солью и кост-фактором (bcrypt/argon2), не как MD5/SHA1. MD5/SHA1 устарели для безопасности — но годятся для checksum.

SQL-инъекция — внедрение SQL-кода через входные данные приложения. Пример: вместо `SELECT * FROM users WHERE name = 'Иван'` получается `SELECT * FROM users WHERE name = '' OR 1=1 --'`, и злоумышленник видит всех.

Защита: 1) параметризованные запросы (placeholder, prepared statements) — главное правило; 2) ORM с правильным использованием; 3) валидация и whitelist входных данных; 4) принцип наименьших привилегий БД-юзера; 5) WAF как дополнительный слой.

Из практики: 99% инъекций ловятся параметризованными запросами. Конкатенация SQL-строки в коде — почти всегда уязвимость.