Сегодня от приложения ждут не только стабильной работы, но и уверенности в безопасности. На фоне растущего числа кибератак пользователи уделяют всё больше внимания защите своих персональных данных. В связи с этим, информационная безопасность — не опция, а обязательный элемент качества ПО.
Часто QA-специалисты фокусируются на функциональности, удобстве использования, пользовательском опыте, упуская из виду свой огромный потенциал в укреплении безопасности продукта. А между тем, именно они могут предотвратить появление уязвимостей или найти их раньше, чем это сделают злоумышленники. И если исправить баг в продакшене — дорого, то исправить последствия успешной кибератаки — во много раз дороже, и речь здесь не только о деньгах, но и о репутации.
Привет, Хабр! Я QA-специалист в IT-компании SimbirSoft. И в этой статье разберемся, какую роль QA может играть в обеспечении безопасности IT-продукта.
Зона ответственности QA в обеспечении безопасности
Сложился стереотип, что безопасность — это зона ответственности AppSec, пентестеров и Red Team. В этой цепочке обычно не находится место для QA. Однако высокий уровень защищенности достижим только при тесном сотрудничестве всех участников процесса, где у каждой роли есть свои уникальные сильные стороны.
Специалисты по ИБ смотрят на продукт глазами атакующего: моделируют угрозы, ищут уязвимости в коде, архитектуре, инфраструктуре, используют глубокие знания об уязвимостях, статический и динамический анализ кода (SAST/DAST).
QA-специалисты смотрят на приложение глазами пользователя (как правило, это и есть один из самых первых пользователей). Они знают, как система должна работать, глубоко погружены в бизнес-логику и понимают все, даже самые неочевидные, пользовательские сценарии. Именно это может быть полезно при поиске уязвимостей на раннем этапе, когда «странное» и нелогичное поведение в итоге может стать точкой входа для злоумышленника.
Поэтому для QA особенно важно знать основные типы уязвимостей и уметь «переключать мышление», чтобы взглянуть на систему с другой стороны. Такой специалист не просто найдет баг, а задастся вопросом: «Можно ли использовать данное поведение во вред?». В свою очередь AppSec-специалисты закроют то, что требует более глубокой экспертизы и моделирование атак. Вместе они образуют многоуровневую и эффективную линию обороны.
Выстраивание безопасности на ранних этапах
Принцип раннего тестирования должен быть знаком каждому QA-специалисту. Хорошей практикой является тестирование требований на этапе их формирования — еще до написания первой строчки кода. Помимо проверок на понятность, однозначность, выполнимость требований, важно их оценить с точки зрения безопасности.
Нужно убедиться, что учтены ограничения, лимиты, логика обработки ошибок и содержание сообщений для пользователя. Ведь если это явно не указано в требованиях, то не факт, что разработчик это реализует. А многие ошибки раскрывают лишнюю техническую информацию о системе или инфраструктуре, которая может быть полезна атакующему.
У ИБ-специалистов не всегда есть возможность участвовать в каждом обсуждении требований. Здесь на помощь может прийти QA-специалист, который имеет представление об уязвимостях и атаках на приложения. Его вопросы на этапе проектирования могут сэкономить десятки часов на исправлениях в будущем.
Вопросы, которые можно задать на этапе анализа требований:
Что произойдет, если пользователь введёт слишком длинное значение, отрицательное число или спец. символ?
Какие ограничения на роли и права доступа? Что система должна делать при попытке совершить действие без нужных прав?
Можно ли повторно использовать промокод?
Можно ли выполнить одну и ту же операцию несколько раз подряд?
Как должны обрабатываться ошибки? Какие данные можно выводить пользователю? Какие данные можно хранить в логах?
Есть ли ограничения на длительность сессии?
Что будет, если нарушить последовательность этапов в определенном сценарии?
Подобные вопросы помогают выявить потенциальные проблемы еще до написания кода, когда их исправление требует минимальных усилий и затрат.
Включение базовых проверок в тесты
Безусловно, многие проблемы можно найти еще на этапе анализа требований, но учесть абсолютно всё невозможно. Функционал усложняется, меняется в процессе разработки и создается разными командами, которые по отдельности могут не знать, как должна работать система в целом, что неизбежно приводит к появлению «слепых зон». Поэтому давайте разберём, что можно добавить в привычные тесты.
Для внедрения базовых проверок на распространенные уязвимости необязательно быть хакером или знать сложные инструменты. Многое можно встроить в обычные функциональные тест-кейсы или чек-листы. А для проведения проверок подойдут привычные для QA инструменты: DevTools, Postman, Fiddler, Charles. Параллельно можно освоить специализированные инструменты, которые сделают процесс более простым и эффективным.
Специализированные инструменты, которые работают как прокси между браузером/мобильным приложением и сервером:
-
Burp Suite — один из самых популярных инструментов для тестирования безопасности веб-приложений.
Плюсы: огромный функционал, который расширяется плагинами, большое сообщество
Минусы: бесплатная версия имеет ограничения, дорогая pro-версия
-
OWASP ZAP — мощный бесплатный сканер уязвимостей.
Плюсы: открытый исходный код, нет ограничений как в Burp Suite, поддержка headless-mode, что полезно для автоматизации
Минусы: нет такого большого количества плагинов, на мой взгляд пользовательский интерфейс более сложный, чем в Burp Suite
-
Caido — достаточно новый инструмент, позиционирующий себя как более простой и легковесный аналог Burp Suite.
Плюсы: удобный пользовательский интерфейс, хорошо подходит для работы в команде
Минусы: есть ограничения в бесплатной версии, инструмент активно развивается, пока не обладает всеми возможностями аналогов
Я бы рекомендовал остановить выбор на Burp Suite, так как функционала бесплатной версии более чем достаточно для основных проверок, а для быстрого погружения есть много информации в сети. Но выбор всегда за вами, тем более никто не запрещает совмещать инструменты.
Какие проверки можно внедрить?
Уязвимости бизнес-логики
Уязвимости бизнес-логики — это недостатки в приложении, которые позволяют злоумышленнику манипулировать легитимным функционалом для достижения вредоносных целей. Их достаточно сложно поймать автоматизированными средствами, потому что такие уязвимости часто уникальны для конкретного приложения. Для их поиска необходимо глубокое понимание того, как система должна работать с точки зрения бизнес-процессов. Именно эта компетенция является ключевой для QA-специалиста, поэтому он отлично подойдет для такой задачи.
Помимо проверки положительного сценария, важно подумать, как можно обойти заложенные лимиты и ограничения, можно ли нарушить порядок шагов или пропустить часть этапов процесса.
Особое внимание следует уделять правам доступа и их разграничению. В современных приложениях может быть много разных ролей со своими правами. При этом права могут накладываться или быть взаимоисключающими, что может породить много непредсказуемых ситуаций. Следует проверять, что пользователи по умолчанию имеют только минимально необходимые права, а выдача дополнительных прав происходит корректно и контролируемо. Важно тестировать сценарии отзыва прав и ограничения доступа после их изменения, а также проверять, что нет «спящих» прав, которые можно использовать для обхода ограничений. QA может оценивать, как система реагирует на попытки выполнять действия без соответствующих прав, и выявлять ситуации, когда дефолтные права или ошибки при выдаче/отзыве прав создают потенциальные уязвимости.
Для составления тестов отлично подходят техники тест-дизайна такие как тестирование состояний переходов и причина-следствие. Будет полезно рисовать диаграммы, составлять интеллект-карты, тем самым находить неочевидные сценарии и цепочки действий, которые приводят к уязвимостям. Например, диаграмма переходов состояний поможет выявить, можно ли из одного состояния перейти сразу к другому, минуя часть этапов. А анализ причин и следствий позволит смоделировать ситуации, когда изменение одного параметра (например, количества товаров) влечет за собой нарушение бизнес-правил (например, применение неположенной скидки).
Insecure Direct Object Reference (IDOR)
IDOR — небезопасная прямая ссылка на объект. Возникает, когда атакующий может получить доступ или манипулировать объектами, которые ему не принадлежат, путем подбора идентификаторов. Поиск не требует больших усилий и временных затрат, но уязвимость встречается достаточно часто. Мне удавалось находить немало таких проблем, просто заменяя идентификатор в запросе.
Как искать:
1) Менять идентификатор в запросах (GET /api/user/123 -> GET /api/user/124)
2) При отсутствии идентификатора добавить идентификатор в запрос, основываясь на похожих запросах в приложении или часто используемых названиях параметров. Например, в запрос для изменения адреса электронной почты:
PUT /api/user
{
"email": "user@example.com"
} можно добавить идентификатор пользователя:
PUT /api/user
{
"email": "user@example.com",
"userId": 124
}3) Использовать разные типы данных. Например, приложение по-разному может обрабатывать integer, float, string. Предыдущий запрос можно отправить с userId в виде числа с плавающей точкой или строки:
PUT /api/user
{
"email": "user@example.com",
"userId": 124.0
}
PUT /api/user
{
"email": "user@example.com",
"userId": "124"
} 4) Использовать разный Content-Type и тело запроса в другом формате. Вместо часто используемого JSON, приложение может поддерживать и другие форматы, но контроль доступа может работать только для JSON:
PUT /api/user
Content-Type: application/x-www-form-urlencoded
email=user@example.com&userId=1245) Использовать другой HTTP-метод. Приложение может позволять выполнять действия GET-запросом, что уже является плохой практикой, но всё становится серьёзнее, если таким образом можно обойти контроль доступа:
GET /api/user?email=user@example.com&userId=124Проблемы аутентификации и сессии
Важно понимать, как работает аутентификация и как приложение управляет сессией: какие данные используются для подтверждения личности, как сервер связывает запрос с пользователем и что происходит при завершении сессии. Глубокое понимание этих механизмов помогает QA находить уязвимости, которые напрямую влияют на безопасность аккаунтов.
Отсюда вытекают основные моменты, которые стоит проверять QA-специалисту:
Как сервер связывает конкретный запрос с сессией? (cookie, JWT, session ID)
Достаточно ли защищены эти идентификаторы (сложность, случайность, передача только по HTTPS)?
Как быстро должна завершиться сессия при бездействии? (таймаут в несколько минут, часы, дни?)
Действительно ли отзывается токен при выходе из системы?
Нужно ли дополнительное подтверждение для критически важных операций (например, изменение email или реквизитов оплаты)?
Можно ли завершить все активные сессии с одного устройства?
Есть ли ограничения на количество попыток входа и попыток восстановления доступа?
Не отключается ли двухфакторная аутентификация при восстановлении доступа?
Подобные проверки легко встраиваются в пользовательские сценарии и не требуют глубокого технического погружения, но могут найти критичные дефекты.
Раскрытие информации
Здесь тоже обычно не требуется глубоких технических знаний. Раскрытие внутреннего устройства приложения может происходить в ответах сервера: в заголовках, текстах ошибок или даже в теле ответа. Таким образом можно получить информацию об инфраструктуре, версиях ПО или внутренней логике приложения, а чем больше злоумышленник знает, тем легче ему построить атаку. На своей практике неоднократно встречал ситуации, когда неожиданный символ в запросе приводил к ответу с ошибкой SQL-запроса, а неожиданный HTTP-метод возвращал стек-трейс.
На что стоит обращать внимание
Заголовки ответа. Могут приходить заголовки с точной версией ПО, что облегчает поиск эксплойтов для злоумышленника (например, Server, X-Powered-by)
Сообщения об ошибках. Стек-трейсы, подробные ошибки об исключениях могут являться хорошей подсказкой для атакующего и вряд ли будут полезны обычному пользователю
Избыточные данные в API. Часто сервер отдаёт больше, чем нужно клиенту: внутренние ID, скрытые поля, флаги, служебные значения
Как тестировать:
Отправлять неожиданные данные: слишком длинные или слишком короткие строки, данные в разных форматах, специальные символы
Не заполнять обязательные поля
Использовать разные HTTP-методы (например, GET вместо POST и наоборот)
Проверять ответы на наличие лишних данных (например, отсутствие скрытых полей, внутренних ID или отладочной информации)
Тут следует задаваться вопросом: «Нужна ли здесь данная информация?» Если нет однозначного ответа, то это повод для уточнений.
В дополнение стоит кратко отметить, что существуют и «классические» технические уязвимости — SQLi, XSS, CSRF, SSRF и другие. Они требуют отдельного внимания и более глубокого погружения. Часть этих проверок можно включить в базовый набор автоматических сканов и простых ручных проверок, но глубокий анализ лучше доверять профильным инженерам.
Более подробно изучить уязвимости и попрактиковаться в их поиске можно на Web Security Academy
Заключение
Внедрение практик в тестирование безопасности в работу QA — это важное стратегическое вложение как для бизнеса, так и для специалиста.
Для бизнеса:
Экономия денег и времени. Чем раньше найдена уязвимость, тем дешевле её исправить
Рост доверия пользователей. Успешная кибератака может нанести колоссальный удар по репутации, а ее восстановление обойдется гораздо дороже профилактики инцидентов
Конкурентное преимущество. Надежный и безопасный продукт становится весомым аргументом на рынке и помогает привлечь новых клиентов
Для QA:
Навыки в области безопасности делают специалиста более востребованным и повышают его рыночную стоимость
Понимание угроз и уязвимостей помогает QA лучше понять устройство системы: как устроена архитектура, как связаны между собой компоненты и где могут возникнуть риски
Повышение качества тестирования. Навыки поиска нестандартных сценариев, анализа бизнес-логики и «мышления атакующего» делают QA сильнее даже в чисто функциональном тестировании
В итоге бизнес получает более надежный и защищенный продукт, а инженер — новые компетенции, карьерные перспективы и интересные задачи. Это не заменит работу AppSec-специалистов, пентестеров, Red Team, а дополняет ее, выстраивая многоуровневую защиту.
Спасибо за внимание!
Больше авторских материалов для QA-специалистов от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.