Тестирование безопасности для QA: как проверять авторизацию, права доступа и защиту данных

Почему QA должен думать о безопасности

Когда говорят «тестирование безопасности», многие тестировщики мысленно передают эту задачу security-инженеру или пентестеру. Логика понятна: есть специалисты, которые занимаются именно этим. Но на практике большинство команд не имеют выделенного security-специалиста, а уязвимости, которые попадают в продакшн, часто элементарны - их мог бы поймать любой внимательный QA.

Речь не о том, чтобы тестировщик стал экспертом по криптографии или знал все CVE. Речь о базовом слое проверок: правильно ли работает авторизация, соблюдается ли разграничение прав, не утекают ли данные через API, не принимает ли система то, что не должна принимать.

Эти проверки не требуют специальных инструментов. Они требуют понимания логики приложения и привычки задавать вопрос: «А что будет, если пользователь сделает то, что делать не должен?»

Где чаще всего живут уязвимости

Прежде чем разбирать конкретные проверки, полезно понять, где уязвимости встречаются чаще всего. OWASP Top 10 - это список наиболее распространенных классов проблем в веб-приложениях, который обновляется раз в несколько лет. Актуальная версия доступна на owasp.org.

Для QA-инженера наиболее практически значимы три категории из этого списка:

• Broken Access Control - нарушение контроля доступа. Пользователь получает данные или выполняет действия, которые ему не разрешены.
• Identification and Authentication Failures - проблемы с аутентификацией. Слабые пароли, отсутствие блокировки после множества попыток, токены без срока жизни.
• Security Misconfiguration - неправильная конфигурация. Открытые эндпоинты, подробные сообщения об ошибках, дефолтные учетные данные.

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

Авторизация и аутентификация: что проверять

Аутентификация отвечает на вопрос «кто ты?», авторизация - «что тебе можно делать?». Это разные механизмы, и ошибки в каждом из них приводят к разным последствиям.

Аутентификация

Базовые проверки, которые стоит включить в любой регрессионный прогон:

• Можно ли войти с неверным паролем после нескольких попыток? Система должна блокировать аккаунт или вводить задержку.
• Что происходит с сессией после выхода из аккаунта? Токен должен инвалидироваться на сервере, а не только удаляться из браузера.
• Есть ли срок жизни у access-токена? Если токен не протухает никогда, его кража дает постоянный доступ.
• Работает ли «Забыл пароль» безопасно? Ссылка для сброса должна быть одноразовой и иметь ограниченный срок действия.
• Принимает ли система пустой пароль или пароль из одного символа?

Авторизация

Здесь главный вопрос - может ли пользователь получить доступ к ресурсу, который ему не принадлежит. Это называется IDOR (Insecure Direct Object Reference) - один из самых частых и опасных классов уязвимостей.

Представим интернет-магазин. У пользователя A есть заказ с ID 1042. Пользователь B знает, что заказы открываются по адресу /api/orders/1042. Если сервер не проверяет, чей это заказ, пользователь B увидит чужие данные.

Как проверить: создайте двух тестовых пользователей. Авторизуйтесь под одним, скопируйте URL или ID ресурса. Затем авторизуйтесь под другим и попробуйте обратиться к тому же ресурсу напрямую - через браузер или Postman. Сервер должен вернуть 403 или 404, но не данные чужого пользователя.

Разграничение прав: роли и привилегии

Большинство приложений имеют несколько ролей: обычный пользователь, менеджер, администратор. Ошибки в разграничении прав - это когда пользователь с меньшими правами может выполнить действие, доступное только роли выше.

Типичные сценарии для проверки:

• Обычный пользователь пытается вызвать API-метод, который доступен только администратору. Например, DELETE /api/users/5 или POST /api/admin/settings.
• Менеджер пытается изменить данные другого менеджера или получить доступ к разделу, который видит только владелец аккаунта.
• Пользователь без подписки пытается вызвать эндпоинт, который должен быть закрыт paywall-ом.

Важный нюанс: интерфейс скрывает кнопки и разделы в зависимости от роли, но API при этом может оставаться открытым. Тестировщик должен проверять именно API, а не только то, что видно в браузере. Если кнопка «Удалить пользователя» не отображается для роли «Менеджер», это не значит, что соответствующий запрос будет отклонен сервером.

Защита данных: что не должно утекать

Данные могут утекать несколькими путями: через ответы API, через логи, через сообщения об ошибках, через заголовки HTTP-ответов.

Ответы API

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

Откройте ответ любого GET-запроса в Postman и внимательно просмотрите JSON. Если в ответе есть поля, которые не нужны клиенту, это повод задать вопрос разработчику.

Сообщения об ошибках

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

Третий пример особенно важен: если система сообщает, что email не найден, злоумышленник может перебором определить, какие адреса зарегистрированы в системе. Правильный ответ - одинаковое сообщение для «нет такого пользователя» и «неверный пароль».

HTTP-заголовки

Откройте DevTools или Postman и посмотрите на заголовки ответа. Заголовок Server: Apache/2.4.51 или X-Powered-By: PHP/7.4.3 сообщает версию используемого ПО - это помогает злоумышленнику искать известные уязвимости именно для этой версии. В продакшне такие заголовки лучше скрывать или убирать.

Работа с токенами и сессиями

JWT (JSON Web Token) - распространенный формат токенов в современных приложениях. У него есть особенности, которые важно проверять.

Токен состоит из трех частей: заголовок, payload и подпись. Payload можно декодировать без ключа - это не шифрование, а кодирование в Base64. Зайдите на jwt.io и вставьте токен из вашего приложения. Вы увидите его содержимое. Проверьте:

• Есть ли поле exp (expiration)? Если нет - токен не протухает никогда.
• Нет ли в payload чувствительных данных: паролей, секретных ключей, данных платежных карт?
• Что происходит, если изменить поле в payload и отправить модифицированный токен? Сервер должен отклонить его из-за невалидной подписи.

Последний пункт проверяется так: возьмите токен, декодируйте payload, измените, например, поле role с user на admin, снова закодируйте и отправьте запрос. Если сервер принял такой токен - это критическая уязвимость.

Инъекции и некорректный ввод

SQL-инъекция - классический пример атаки, при которой пользовательский ввод интерпретируется как команда базы данных. Для QA не нужно знать синтаксис атак наизусть, но базовую проверку провести стоит.

В поля ввода - имя, email, поиск, фильтры - попробуйте ввести специальные символы: одиночную кавычку ', двойную кавычку

Как выстроить процесс: с чего начинать и как приоритизировать

Когда тестировщик впервые сталкивается с задачей проверить безопасность, возникает вопрос: за что браться в первую очередь? Проверок много, время ограничено, а функциональное тестирование никто не отменял.

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

Простая последовательность для нового проекта:

1. Составьте список всех ролей в системе и опишите, что каждая роль должна видеть и делать.
2. Для каждой роли проверьте, что она не может сделать то, что разрешено только другой роли.
3. Проверьте все эндпоинты, которые работают с чужими данными: заказы, профили, документы, платежи.
4. Убедитесь, что ошибки не раскрывают внутреннюю структуру системы.
5. Проверьте поведение при истечении сессии и при попытке использовать старый токен.

Этот список не заменяет полноценный security-аудит, но закрывает большинство уязвимостей, которые реально попадают в продакшн в командах без выделенного специалиста по безопасности.

Чеклист для регрессионного прогона

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

Инструменты, которые реально пригодятся

Тестировщику не нужен арсенал пентестера. Достаточно нескольких инструментов, которые большинство QA-инженеров уже используют в работе.

Postman или Insomnia - для прямой работы с API. Позволяют отправлять запросы с токенами разных пользователей, менять заголовки, подставлять чужие ID. Большинство проверок из этой статьи делаются именно здесь.

DevTools браузера - вкладка Network показывает все запросы и ответы, включая заголовки. Удобно смотреть, что именно возвращает сервер и нет ли в ответах лишних данных.

jwt.io - онлайн-декодер токенов. Вставляете токен, видите его содержимое. Полезно для проверки срока жизни и состава payload.

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

Для большинства команд Postman и DevTools покрывают 80% практически значимых проверок. Остальные инструменты подключаются по мере роста зрелости процесса.

Как фиксировать находки и общаться с командой

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

Описывайте не только что сломано, но и что это позволяет сделать злоумышленнику. Разница между «API возвращает данные без проверки роли» и «любой авторизованный пользователь может получить список всех заказов с именами и адресами клиентов» очевидна. Второй вариант понятен не только разработчику, но и менеджеру, который принимает решение о приоритете.

Указывайте конкретные шаги воспроизведения: какой запрос отправили, с каким токеном, что получили в ответе. Прикладывайте скриншот из Postman или DevTools.

Не публикуйте реальные токены или данные пользователей в баг-трекере, если он доступен широкому кругу людей. Используйте тестовые аккаунты и маскируйте чувствительные значения.

Уязвимости, связанные с контролем доступа и утечкой данных, как правило, получают высокий приоритет. Но финальное решение о приоритете принимает команда совместно, и QA здесь выступает как источник информации, а не как единственный судья.

Тестирование на разных уровнях: фронтенд, бэкенд и мобильные приложения

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

Во фронтенде основные риски связаны с тем, что чувствительные данные попадают в localStorage или sessionStorage, а также с тем, что логика разграничения прав реализована только на клиенте. Проверьте: не хранится ли токен в localStorage вместо httpOnly-куки, не записываются ли персональные данные в хранилище браузера, не выполняется ли проверка роли только в JavaScript без дублирования на сервере.

На уровне бэкенда и API основная задача уже описана выше: проверять эндпоинты напрямую, не полагаясь на то, что интерфейс что-то скрывает. Дополнительно стоит обращать внимание на CORS-политику: если сервер разрешает запросы с любого домена (Access-Control-Allow-Origin: *), это может быть проблемой для эндпоинтов с чувствительными данными.

В мобильных приложениях уязвимости часто прячутся в другом месте. Трафик между приложением и сервером можно перехватить через прокси (например, Charles или mitmproxy), если приложение не реализует certificate pinning. Это позволяет увидеть все запросы и ответы, включая токены и данные. Для QA это полезный инструмент проверки, но он же показывает, насколько приложение уязвимо к перехвату.

Типичные ошибки при тестировании: что пропускают чаще всего

Даже внимательные тестировщики регулярно пропускают одни и те же классы проблем. Полезно знать о них заранее.

Проверка только happy path авторизации. Тестировщик проверяет, что вход с правильными данными работает, и считает задачу выполненной. Но не проверяет: что происходит при множественных неудачных попытках, работает ли выход из аккаунта на всех устройствах, инвалидируется ли токен при смене пароля.

Доверие к интерфейсу. Если кнопка скрыта, тестировщик не проверяет соответствующий API-запрос. Это одна из самых частых причин, по которой уязвимости доходят до продакшна.

Игнорирование заголовков ответа. Заголовки редко проверяют в рамках функционального тестирования, но именно они могут раскрывать версии ПО или отсутствие базовых защитных механизмов вроде X-Content-Type-Options или X-Frame-Options.

Тестирование только своего аккаунта. Многие проверки требуют двух и более тестовых аккаунтов с разными ролями. Если тестировщик работает только с одним аккаунтом, он физически не может проверить сценарии с доступом к чужим данным.

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

Когда подключать специалиста по безопасности

QA-инженер закрывает базовый слой проверок, но есть ситуации, когда без специалиста по безопасности не обойтись. Важно понимать эту границу, чтобы не переоценивать свои проверки и не создавать ложное ощущение защищенности.

Если продукт работает с платежными данными, медицинскими записями или персональными данными в объеме, требующем соответствия регуляторным требованиям, базовых QA-проверок недостаточно. Это не значит, что их не нужно делать: они по-прежнему полезны и снижают количество очевидных проблем. Но финальное подтверждение безопасности должен давать специалист с соответствующей квалификацией.

Хорошая практика: договориться с командой о том, что QA проводит базовые проверки при каждом релизе, а полноценный security-аудит проводится раз в квартал или перед крупными запусками. Это дает разумный баланс между скоростью и уровнем защиты.

А лучшие вакансии для тестировщиков ищите на hirehi.ru