Ответ.

История вопроса

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

Проблема

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

Решение

Ручное тестирование безопасности — это попытка воспроизвести потенциальные атаки с позиции обычного пользователя:

Проверка XSS, SQL Injection, CSRF.
Манипуляции с cookie и session.
Попытки нарушения авторизации и ограничения прав.

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

Ключевые особенности:

Использование простых ручных техник (изменение параметров в URL, попытки ввести опасные значения).
Проверка стандартных уязвимостей из OWASP Top 10.
Необходимость общения с DevOps/Backend для уточнения, как обрабатываются ошибки, и какие логи генерируются.

Вопросы с подвохом.

Можно ли ручным способом выявить все критические уязвимости в приложении?

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

Достаточно ли проверить только форму логина и пароля для теста безопасности?

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

Нужно ли тестировщику разбираться в HTTP-запросах и ответах, если речь о ручном тесте безопасности?

Да. Работа с инструментами вроде DevTools, Postman или Fiddler — ключ к нахождению проблем безопасности вручную.

Типовые ошибки и анти-паттерны

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

Пример из жизни

Негативный кейс

Тестировщик проверил только вход в систему на наличие XSS, не тестируя остальные пользовательские формы и параметры URL.

Плюсы:

Быстро выполненный тест первой очереди.

Минусы:

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

Позитивный кейс

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