До сих пор мы смотрели на продукт глазами обычного пользователя, который иногда ошибается или вводит что-то неожиданное. В этой главе — другой взгляд: что если ввод неожиданный не по ошибке, а специально? Manual QA не занимается взломом систем — это отдельная специализация (security-тестирование, пентест), требующая собственной глубокой подготовки. Но замечать признаки проблем с безопасностью, правильно их называть и вовремя эскалировать специалисту — часть работы любого тестировщика.
Чему научишься за этот урок:
— формулировать границу роли manual QA в безопасности: замечать и эскалировать, не эксплуатировать;
— называть риски, связанные с аутентификацией, авторизацией и сессиями (глава 3), и что именно проверить;
— объяснять, почему опасный ввод данных — это не только баг валидации, но иногда более серьёзный класс проблемы;
— ориентироваться в категориях OWASP Top 10 как в карте типичных уязвимостей, не как в инструкции.
Тестировщик — не пентестер, но должен уметь замечать
Работа с уязвимостями продукта делится на две принципиально разные роли. Security-тестировщик (пентестер) — отдельная специализация: целенаправленно ищет и проверяет уязвимости, обычно с отдельным разрешением и по чёткому регламенту (какие системы можно трогать, что именно разрешено делать). Manual QA в это не входит: его задача — заметить подозрительный признак во время обычного тестирования, правильно назвать класс проблемы и эскалировать security-специалисту или разработчику, а не пытаться самостоятельно довести находку до рабочей атаки. Эта граница — не формальность, а профессиональная ответственность: непреднамеренная попытка «доломать» находку без разрешения и регламента может навредить реальным пользователям и данным.
Риски аутентификации, авторизации и сессий
Вы уже знаете из главы 3, что аутентификация отвечает на вопрос «кто ты», а авторизация — «что тебе можно», и что сервер «помнит» пользователя между запросами через сессию (обычно — через cookie с идентификатором сессии). С точки зрения безопасности у каждого из этих трёх понятий есть типичный риск, который стоит держать в голове:
- Аутентификация. Сообщение об ошибке при неверном логине или пароле не должно давать понять, что именно неверно — «неверный логин или пароль» безопаснее, чем отдельно «такого пользователя не существует» и отдельно «неверный пароль»: вторая формулировка позволяет постороннему перебором узнать, какие email вообще зарегистрированы в системе.
- Авторизация. Классический риск — доступ к чужим данным через подмену идентификатора: если в адресе страницы виден номер заказа или профиля, стоит проверить, не откроются ли чужие данные при простой подстановке другого номера, пока пользователь остаётся в своей же учётной записи.
- Сессии. Сессия должна реально завершаться при выходе из системы (logout) — стоит проверить, что после выхода старая ссылка на личный кабинет действительно перестаёт работать, а не продолжает открывать данные, потому что сессия на сервере не была аннулирована.
Обратите внимание: все три проверки выше — это позитивные и негативные тест-кейсы в чистом виде (глава 5), просто с прицелом на чужие данные и на состояние после выхода. Придумывать код для эксплуатации не нужно — нужно наблюдать за поведением продукта и правильно называть находку.
Ввод данных: не всегда просто баг валидации
В главе 5 вы разобрали негативные проверки — ввод неожиданных значений, чтобы увидеть реакцию продукта. Иногда реакция на неожиданный ввод — это просто баг интерфейса (например, обрезанный текст). Но если поле ввода в принципе не ограничивает и не экранирует то, что в него введено, а сервер потом использует введённый текст как часть команды или показывает его на странице без изменений — это уже не косметика, а отдельный класс проблем безопасности. И это касается не только форм ввода на странице (глава 7) — точно та же логика применима к параметрам API-запроса (глава 8): если API принимает значение параметра без проверки и подставляет его напрямую в запрос к базе данных или в ответ, риск ровно тот же, просто вход в него не через видимую форму, а через тело или строку запроса. Тестировщику не нужно самому составлять рабочую вредоносную нагрузку — достаточно заметить симптом: если ввести в поле текст с HTML-тегами, например <b>тест</b>, и он СРАБОТАЛ — то есть слово «тест» стало жирным, а не показались сами угловые скобки, — значит, ввод не экранируется, и это уязвимость. Останется описать находку так, чтобы разработчик или security-специалист мог её воспроизвести и оценить реальный риск.
OWASP Top 10 — карта категорий, не инструкция
OWASP Top 10 — регулярно обновляемый список самых распространённых категорий уязвимостей веб-приложений, который составляет открытое международное сообщество OWASP (Open Worldwide Application Security Project). Это не набор готовых атак, а словарь общепринятых названий классов проблем — полезен тестировщику именно тем, что позволяет правильно НАЗВАТЬ находку в отчёте, а не тем, что учит их создавать. Несколько категорий, которые вам стоит уметь узнавать по названию и общему смыслу:
- Broken Access Control (нарушение контроля доступа) — пользователь получает доступ к данным или действиям, которые ему не разрешены (пример из этого урока — подмена чужого номера заказа в адресе).
- Injection (инъекции) — введённые пользователем данные обрабатываются сервером как часть команды или запроса, а не как обычный текст.
- Identification and Authentication Failures (проблемы идентификации и аутентификации) — слабости в проверке личности пользователя или в управлении сессией (например, сессия не завершается при выходе).
- Security Misconfiguration (небезопасная конфигурация) — например, среда осталась в тестовом/отладочном режиме на боевом сервере, показывая лишние технические детали.
- Cryptographic Failures (проблемы криптографии) — чувствительные данные (пароли, платёжные данные) хранятся или передаются без должной защиты.
Симптом, который заметил QA Категория OWASP ---------------------------------------------------- ---------------------------- Чужой заказ открылся по подставленному номеру Broken Access Control Введённый HTML-тег СРАБОТАЛ (стал жирным/курсивом/скриптом) Injection Старая ссылка на кабинет работает после выхода Identification/Auth Failures Ошибка сервера показывает лишние технические детали Security Misconfiguration
Итог:
— manual QA замечает и эскалирует признаки проблем безопасности, но НЕ занимается самостоятельной эксплуатацией уязвимостей — это отдельная специализация (security-тестирование, пентест) со своим регламентом;
— у аутентификации, авторизации и сессий (глава 3) есть типичные риски: раскрытие существования аккаунта через формулировку ошибки, доступ к чужим данным через подмену идентификатора, незавершённая сессия после выхода;
— неограниченный или неэкранированный ввод данных иногда указывает не на косметический баг, а на более серьёзный класс проблемы;
— OWASP Top 10 — общепринятый словарь названий категорий уязвимостей, полезен для правильного названия находки в отчёте, а не как инструкция.
Контрольный вопрос. В чём заключается роль manual QA в вопросах безопасности продукта?
Подсказка: Вспомни разделение ролей в начале урока — чем отличается manual QA от security-тестировщика.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Почему сообщение об ошибке входа «неверный логин или пароль» безопаснее, чем раздельные сообщения «такого пользователя нет» и «неверный пароль»?
Подсказка: Подумай, какую дополнительную информацию о системе получает посторонний человек из раздельных формулировок.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что нужно проверить в первую очередь применительно к рискам АВТОРИЗАЦИИ, если номер заказа виден прямо в адресе страницы?
Подсказка: Речь про доступ к ЧУЖИМ данным — это категория авторизации, не про отображение или скорость.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что означает категория OWASP «Injection» (инъекции)?
Подсказка: Вспомни таблицу-шпаргалку урока — какой симптом сопоставлен именно с категорией Injection.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Тестировщик ввёл в поле комментария текст с HTML-тегом, и тег СРАБОТАЛ на странице (например, часть текста стала жирной), вместо того чтобы просто показаться как обычные символы. Какие из следующих действий соответствуют правильной профессиональной границе manual QA (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Два варианта — это стандартный процесс оформления находки, два других — выход за профессиональную границу manual QA из начала урока.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется международное сообщество, которое составляет регулярно обновляемый список самых распространённых категорий уязвимостей веб-приложений («Top 10»)? Ответь одним словом — аббревиатурой.
Подсказка: Аббревиатура прямо стоит перед «Top 10» в названии, встречается в заголовке раздела урока.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик заметил, что после выхода из личного кабинета (logout) старая ссылка на кабинет всё ещё открывает данные, как будто пользователь так и не вышел. Как одним словом называется понятие из главы 3, которое отвечает именно за это поведение? Ответь одним словом.
Подсказка: Речь о том, что сервер должен был «забыть» пользователя после выхода — вспомни, какое понятие из главы 3 за это отвечает.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Пользователь A подставил в адресе страницы номер заказа пользователя B (просто изменил цифру в URL, оставаясь в своей учётной записи) — и увидел чужой заказ целиком. К какой категории OWASP из урока относится эта находка? Ответь термином на английском, как он записан в уроке.
Подсказка: Речь про доступ к данным, которые не должны быть разрешены этому пользователю — вспомни первую категорию из списка урока.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях, почему manual QA, обнаружив признак уязвимости (например, неэкранированный HTML в поле комментария), не должен пытаться самостоятельно довести находку до рабочей атаки, даже если технически это возможно.
Критерий приёмки: объяснено, что это выход за профессиональную роль manual QA (не пентестер, нет отдельного разрешения/регламента); упомянут риск реального вреда пользователям/данным продукта при неконтролируемой попытке «доломать» находку; указано, что правильное действие — зафиксировать находку и эскалировать специалисту.
Подсказка: Вспомни разделение ролей QA/пентестер из начала урока и почему эта граница — не формальность.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. На нашей учебной платформе тестировщик заметил, что страница ошибки сервера при некорректном запросе показывает полный текст технической ошибки, включая внутренний путь к файлу на сервере. Определи, к какой категории OWASP из урока это относится, и опиши, что именно должно быть в баг-репорте на эту находку (структура баг-репорта — из главы 6), не пытаясь развить находку в реальную атаку.
Критерий приёмки: названа категория «Security Misconfiguration» (небезопасная конфигурация) с обоснованием (лишние технические детали показаны пользователю); в описании баг-репорта присутствуют минимум шаги воспроизведения и фактический результат (что именно показала ошибка); явно указано, что тестировщик не пытается получить из этой информации дальнейший доступ или углубить находку самостоятельно.
Подсказка: Сопоставь симптом («лишние технические детали в ошибке сервера») с таблицей категорий урока, и вспомни поля баг-репорта из главы 6.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Что дальше
Мы разобрали, что должен замечать manual QA в вопросах безопасности — и, не менее важно, где проходит граница его роли. В следующем уроке — шире: как вообще решить, что тестировщик проверяет сам, а что эскалирует специалисту, не только в вопросах безопасности.
