Коли просто тестувати вже недостатньо: чому QA варто знати основи кібербезпеки

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, спільното! Мене звати Вікторія, і з недавніх пір я QA Lead в компанії OX Company. Ні, у мене немає десятирічного досвіду і купи кейсів, але я завжди прагнула розвиватися і якнайшвидше стати сильним, конкурентним QA-інженером. У моєму роадмапі було достатньо цікавих технологій та напрямків, які я б хотіла вивчати, щоб досягти цього, і один із них — кібербезпека.

Насправді я відтягувала цей момент, бо розуміла, що це важка історія. Треба опанувати вже той Linux, розумітися на якихось DevOps-штуках, ще й JS було б непогано знати для XSS. Спойлер: ні, глибоко занурюватися не доведеться, якщо це доповнення до вашої ролі QA, а не основна професія. І ні, ви не станете тим хакером у чорному худі із зеленим екраном.

Але відкладати навчання більше не вдалося: керівництво компанії запропонувало мені пройти курс, щоб стати сильнішим спеціалістом, розумітися на атаках та превентивно захищати наші продукти. Я погодилася, бо це дуже крута можливість для мого росту, хоча це трохи лякало. Зараз я ані краплі не жалкую, що вирішила спробувати!

QA — це більше, ніж пошук багів

Що ви уявляєте, коли чуєте про професію QA-інженера? Хтось вважає, що вони «тицькають кнопки», хтось більш поважно — «вони знаходять баги». Але я вважаю, що QA — це більше, ніж баги та репорти: це людина, яка покращує продукт і піклується про обидві сторони: про розробників і про користувачів.

Думаю, більшість моїх колег погодяться: найцінніші баги — ті, що вдається виявити ще до того, як вони коштують бізнесу репутації або грошей. Так от, кібербезпека працює так само на випередження, бо основна її мета — захистити продукт від будь-яких зовнішніх проникнень, захистити дані клієнтів, захистити репутацію.

Я пропоную вам розглянути цей напрямок з боку тестування. Є цілий вид тестування, який цьому присвячений — Penetration testing (тестування на проникнення). Але часто QA-інженери його опускають, бо, можливо, не знають, як його проводити. У цьому блозі я хочу навести декілька прикладів, які можуть бути не тільки корисними для продукту, а й справді цікавими.

Дисклеймер: я не пишу з точки зору професіонала з кіберзахисту — я хочу поділитися досвідом QA, який дійсно допоможе колегам.

Як я можу застосувати знання з кібербезпеки в QA?

Звісно, ми можемо поговорити про SQL-інʼєкції, XSS, XXE атаки, але про це вже багато написано. Навіть без глибоких знань ви знайдете чимало готових інʼєкцій і скриптів, щоб перевірити, чи вразлива ваша аплікація.

Але я пропоную зануритися трохи глибше і розглянути цікавіші способи перевірки.

🔐 Перший лот — Broken Access Control

З цією вразливістю я вперше зіткнулася ще до навчання, працюючи на одному з проєктів. Як виявилося пізніше, бекенд продукту не перевіряв привілеї користувачів. Тобто роль, права доступу, user ID — усе це або не перевірялося зовсім, або перевірка була формальною.

На жаль, я тоді не помітила цю серйозну прогалину через брак досвіду — просто не знала, що такі речі потрібно перевіряти.

Уявімо, що в системі є кілька ролей: admin, support, user.

• Адмін має повний контроль над системою: може створювати, читати, редагувати й видаляти будь-які дані.
• Сапорт — обмеженіші права, наприклад, лише читання й редагування.
• Звичайний юзер — може переглядати та змінювати лише свою інформацію.

Для взаємодії з бекендом використовуються API-запити. Припустимо, що це REST API:

POST /create_user
GET /read_all
PUT /edit/{user_id}
DELETE /delete?id={user_id}

На перший погляд — усе стандартно. Але саме тут може ховатися небезпека.

Якщо бекенд не перевіряє, чи має користувач право виконувати конкретний запит, він може змінити user_id у параметрах запиту — і замість своїх даних змінити чужі. Уявіть, що користувач просто вручну підставляє id=1002 замість id=1001 і бачить чи змінює чужі дані.

Це приклад горизонтальної ескалації привілеїв (Horizontal Privilege Escalation) — коли користувач з одним рівнем доступу отримує можливість бачити або змінювати дані на тому ж рівні, але які йому не належать.

А тепер інший кейс. Уявімо, що користувач вирішує спробувати щось нестандартне — наприклад, надіслати запит до ендпоінта GET /read_all_users, який, теоретично, доступний лише адмінам. Якщо бекенд не перевіряє роль у токені, юзер все одно отримає список усіх користувачів — тобто доступ до інформації, яка йому не призначена. Теж саме можна уявити із роллю сапорта: він може спробувати видалити користувача, навіть якщо на UI у нього немає кнопки «Delete», просто надіславши запит.

Це вже вертикальна ескалація привілеїв (Vertical Privilege Escalation) — коли користувач отримує доступ до функціональності, передбаченої для вищого рівня ролі.

Обидва ці випадки — частина Broken Access Control, тобто ситуацій, коли система неправильно або взагалі не обмежує доступ до ресурсів. Такі вразливості дуже поширені та дуже небезпечні, бо вони дозволяють зловмисникам робити дії від імені інших або отримувати чутливу інформацію без відповідних прав.

🔐 Другий лот — Improper Session Management

При роботі з токенами недостатньо перевіряти, що юзер його отримує та використовує після логіну в системі. Для прикладів будемо брати найпопулярніші JWT-токени.

Ось що варто знати:

• токен складається з 3 частин: header.payload.signature.
  • Header містить тип токена та алгоритм підпису;
  • Payload — корисне навантаження, інфо про юзера;
  • Signature — підпис, який генерується шляхом підпису header + payload за допомогою секретного ключа й алгоритму, вказаного в header.
• ви його можете декодувати на будь-якому доступному онлайн-сервісі (а значить, це може зробити хто завгодно).
• токен може містити в собі чутливу інформацію про юзера: айді, роль, пошту, навіть іноді пароль.
• ви можете закодувати в токен ту інформацію, яку хочете, і спробувати з тим токеном піднятися вище по привілеях (кодування також можна зробити онлайн).

Ваші дії як тестувальника:

• Взяти токен вашої системи та розкодувати його.
• Звернути увагу на алгоритм в хедері та на інформацію в пейлоаді.
• Якщо в пейлоаді важлива інформація, обовʼязково сказати про це команді та донести, що це неправильно.
• Спробувати змінити пейлоад (наприклад, змінити роль користувача) та закодувати з тим самим алгоритмом токен.
• Надіслати запит з новим токеном, якщо не буде помилки, то скоріш за все бекенд не перевіряє сигнатуру, що також є вразливістю.

Також при роботі з токенами важливо перевіряти їх експерейшен. Якщо токен валдіний тільки 24 години, то впевніться, що так воно і є насправді. Крім того, логічно, що після зміни пароля (зі сторони адміна чи користувача) має генеруватися новий токен, а старий має бути недійсним.

🔐 Третій лот — Business Logic Vulnerabilities

Це не класичні технічні вразливості, це помилки у самій бізнес-логіці — коли продукт працює не так, як задумано, і користувач може цим скористатися.

Приклад, який я зустрічала в e-commerce: система дозволяла застосувати одноразовий купон кілька разів. Просто повторно надіславши запит із тим самим кодом — знижка знову працювала. Або ж інший варіант: користувач змінює ціну товару на клієнті (наприклад, з 1000₴ на 10₴) — і бекенд це «ковтає», бо довіряє UI.

Що може зробити QA:

• Перевірити, чи справді одноразові купони не можна застосувати повторно.
• Спробувати вручну змінити суму знижки або ціну товару у запиті до API.
• Перевірити, чи можна обійти обмеження, наприклад, використати купон на інші категорії товарів, ніж передбачено.
• Спробувати створити сценарій, де кінцева сума замовлення — негативна або 0.

Такі баги технічно нескладні, але бізнесу вони можуть коштувати дуже дорого.

Чому QA варто розбиратися в основах безпеки

Ми розглянули лише кілька прикладів, проте атак дуже багато. Ви можете самостійно зануритися в цю тему та знайти доволі цікаві кейси для майбутніх перевірок. Але те, що я знаю точно — це те, що QA-інженерам дуже корисно розбиратися в цій базі. Це не додатковий стек, це абсолютно новий кут зору, котрий допоможе вам покращувати продукти. Іноді навіть базові знання можуть врятувати від критичного інциденту.

Навіть якщо ви не плануєте ставати security-інженером, розуміння базових принципів дозволяє:

• ставити правильні запитання на етапі планування;
• вчасно виявляти уразливості, які не виявить жоден UI-тест;
• бачити логічні помилки, які технічно «проходять», але бізнесово — неприйнятні;
• захистити користувача ще до того, як він зіштовхнеться з проблемою.

Системи стають складнішими, а ризики — серйознішими. І в команді саме QA може бути тією людиною, яка помітить, що щось не так. Безпека — це теж про якість. І ми вже давно не просто «шукаємо баги», ми допомагаємо створювати продукти, яким довіряють.

Корисні ресурси для початку

Я можу порадити почати з лайтових ресурсів для ознайомлення з напрямком:

• OWASP Top 10 — подивіться, які вразливості наразі є найбільш поширеними.
• OWASP Juice Shop — тренажер для тестування вразливостей у вебзастосунку з челенджем на пошук 100 вразливостей.
• PortSwigger Web Security Academy — дуже якісна безкоштовна платформа з теорією + практикою, від авторів Burp Suite.
• Hack The Box (HTB) — практичні сценарії з тестування вразливостей (є beginner-дружній режим).
• TryHackMe — ще простіше для початку: гейміфікований формат з поетапним навчанням (є модулі для QA/DevSecOps).

Саме для роботи я б виділила Burp Suite, ZAP і, звісно, Postman.

Цього буде достатньо для початку, а далі ви можете точково вивчати вразливості, що потенційно загрожують вашим продуктам.

Які можна зробити висновки?

QA сьогодні — це не просто перевірка UI і «чи працює кнопка». Це роль, яка вимагає розуміння архітектури, логіки, користувацького досвіду й так, навіть безпеки.

Ми не обовʼязково маємо вміти проводити повноцінне пентест-сканування чи писати експлойти — але маємо знати, де слабке місце, як його знайти й вчасно попередити команду. Це те, що відрізняє хорошого тестувальника від сильного.

Моя порада — не бійтеся зануритися в нову сферу. Почніть з малого: одна вразливість, один токен, один приклад. І дуже швидко ви побачите, як змінюється не лише ваш підхід до тестування, а й ваша цінність у команді.

А як ви вважаєте — чи повинен QA відповідати за базову перевірку безпеки, чи це вже «не його зона»?