Junior: питання на співбесіді з теми «OWASP і процеси безпеки»

OWASP Top 10 - перелік найкритичніших категорій ризиків вебзастосунків від некомерційної спільноти OWASP. Він складається з даних про реальні вразливості й опитування спеціалістів і оновлюється раз на кілька років. Це не стандарт і не чекліст для повної перевірки, а спільна мова й відправна точка для навчання та пріоритизації.

OWASP Top 10:2025:

1. A01 Broken Access Control - порушення контролю доступу (чужі дані за зміненим id, відсутні перевірки прав);
2. A02 Security Misconfiguration - помилки конфігурації (налагодження на продакшені, відкриті службові файли, стандартні паролі);
3. A03 Software Supply Chain Failures - збої ланцюжка постачання ПЗ (вразливі й скомпрометовані залежності, збірка, CI);
4. A04 Cryptographic Failures - криптографічні помилки (незашифровані дані, слабкі алгоритми, погане керування ключами);
5. A05 Injection - ін'єкції (SQL, команди ОС, XSS);
6. A06 Insecure Design - небезпечний дизайн (вразливості в самій архітектурі й логіці);
7. A07 Authentication Failures - збої автентифікації;
8. A08 Software or Data Integrity Failures - порушення цілісності ПЗ і даних;
9. A09 Security Logging and Alerting Failures - збої журналювання й сповіщень;
10. A10 Mishandling of Exceptional Conditions - неправильна обробка виняткових ситуацій.

Що помітно змінилося порівняно з 2021:

• ланцюжок постачання став окремою широкою категорією (замість вужчої «вразливі й застарілі компоненти»);
• неправильна конфігурація піднялася на друге місце;
• SSRF більше не окрема категорія - увійшла до контролю доступу;
• з'явилася нова категорія про обробку виняткових ситуацій: помилки, що «відкривають» доступ (fail-open), витоки через повідомлення про помилки;
• у категорії журналювання акцент на сповіщеннях: недостатньо писати журнали, хтось має реагувати.

Як використовувати на практиці:

• як основу навчання команди й пунктів рев'ю коду;
• для пріоритизації: контроль доступу - на першому місці не випадково, його варто перевіряти в кожному ендпойнті;
• для повнішої перевірки - OWASP ASVS (стандарт вимог до перевірки безпеки), а не лише Top 10.

Докладніше в документації: OWASP Top 10:2025

security.txt (RFC 9116) - текстовий файл за адресою /.well-known/security.txt, що повідомляє дослідникам безпеки, як повідомити про знайдену вразливість.

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

Приклад:

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: uk, en
Policy: https://example.com/security/policy
Acknowledgments: https://example.com/security/thanks
Canonical: https://example.com/.well-known/security.txt
Encryption: https://example.com/pgp-key.txt

Поля:

• Contact (обов'язкове) - email, форма чи телефон для повідомлень; можна кілька;
• Expires (обов'язкове) - до якої дати інформація актуальна. RFC радить не більше ніж на рік уперед - щоб застарілий файл з неробочими контактами не вводив в оману;
• Policy - посилання на політику розкриття вразливостей: що досліджувати можна, а що ні, як ви реагуєте;
• Preferred-Languages, Acknowledgments, Encryption (ключ для зашифрованих повідомлень), Canonical - необов'язкові.

Практичні моменти:

• файл має бути доступний за HTTPS саме за шляхом /.well-known/security.txt. Правила вебсервера чи WAF, що блокують «приховані» шляхи, мають робити виняток для /.well-known/;
• у Laravel - статичний файл public/.well-known/security.txt або маршрут, що генерує його з актуальною датою Expires;
• адреса Contact має реально читатися - скринька, яку ніхто не перевіряє, гірша за її відсутність;
• файл можна підписати OpenPGP, щоб підтвердити автентичність;
• нагадування про оновлення Expires - інакше файл «протухне» через рік.

Це частина ширшої картини - політики розкриття вразливостей (VDP): security.txt лише вказує, куди писати, а процес реагування має існувати насправді.

Докладніше в документації: RFC 9116: security.txt

CVE (Common Vulnerabilities and Exposures) - унікальний ідентифікатор публічно відомої вразливості: CVE-2025-12345. Він дає змогу однозначно говорити про ту саму проблему в базах даних, звітах сканерів, бюлетенях вендорів. Інші екосистеми мають свої ідентифікатори: GHSA-... (GitHub Advisory Database), PKSA-... (Packagist).

CVSS (Common Vulnerability Scoring System) - оцінка серйозності від 0 до 10:

Оцінка складається з метрик: вектор атаки (мережа чи потрібен локальний доступ), складність, потрібні привілеї, участь користувача, вплив на конфіденційність, цілісність і доступність. Актуальна версія стандарту - CVSS 4.0.

Як читати повідомлення (advisory) у залежності:

1. чи вразлива наша версія? Діапазон уражених версій і версія з виправленням;
2. чи використовуємо ми вразливу частину? Вразливість у функції завантаження XML не загрожує, якщо застосунок її не викликає. Але «не використовуємо» треба перевірити, а не припустити;
3. чи досяжна вона ззовні? Вектор «мережа, без автентифікації» в публічному застосунку - найгірший випадок;
4. чи є публічний експлойт або ознаки активної експлуатації (каталог CISA KEV) - це різко підвищує терміновість;
5. що потрібно зробити: оновити, застосувати обхідний шлях, тимчасове правило WAF.

CVSS - не пріоритет у вашому контексті. «Критична» вразливість у бібліотеці, що використовується лише в CLI-скрипті розробника, може бути менш терміновою, ніж «середня» в публічному ендпойнті оплати. Бал - відправна точка, оцінка ризику - ваша.

Інструменти: composer audit, npm audit, Dependabot alerts, Snyk - зіставляють залежності з базами вразливостей. Важливо мати процес: хто розбирає сповіщення, у які терміни виправляються критичні й високі, як фіксується рішення «не стосується нас».

Докладніше в документації: FIRST: Common Vulnerability Scoring System

composer audit перевіряє встановлені PHP-пакети за базами відомих вразливостей (GitHub Advisory Database, Packagist) і повідомляє про уражені версії.

composer audit                 # за встановленими пакетами
composer audit --locked        # за composer.lock - зручно в CI до встановлення
composer audit --no-dev        # лише залежності продакшену
composer audit --format=json   # для автоматичної обробки

Команда повертає ненульовий код виходу, якщо є вразливості, - збірка в CI падає. Також вона повідомляє про покинуті пакети (abandoned), які більше не отримують виправлень.

npm audit - те саме для JavaScript-залежностей фронтенду:

npm audit --omit=dev           # лише залежності, що потрапляють у збірку
npm audit --audit-level=high   # падати лише на high і critical

Як вбудувати в процес:

1. CI на кожен пул-реквест і за розкладом. Нові вразливості публікуються щодня - проєкт без змін теж може стати вразливим, тож перевірка за розкладом (щодня чи щотижня) обов'язкова;
2. автоматичні PR оновлень - Dependabot чи Renovate створюють пул-реквести з оновленнями й security-сповіщеннями;
3. блокування вразливих версій - сучасний Composer за замовчуванням не дає встановити через update/require версію пакета з відомою вразливістю (налаштовується в config.policy, у старіших версіях - через ключі audit);
4. винятки - явні й з причиною: якщо вразливість не стосується проєкту, її ігнорують з поясненням і, бажано, терміном перегляду, а не вимикають перевірку повністю:

"config": {
    "policy": {
        "advisories": {
            "ignore-id": { "CVE-2026-0001": "Не використовуємо XML-парсер пакета" }
        }
    }
}

Типові помилки:

• запуск лише вручну «колись» - фактично ніколи;
• ігнорування npm audit, бо «там завжди щось є». Багато знахідок - у залежностях інструментів збирання (devDependencies), що не потрапляють у браузер; --omit=dev відфільтровує шум і показує те, що справді важливо;
• оновлення лише composer.json без composer.lock - на продакшен потрапляє версія із замка.

Пам'ятати: аудит знаходить лише відомі вразливості відомих пакетів - це не захист від скомпрометованого пакета з нульового дня.

Докладніше в документації: Composer: команда audit

Персональні дані - будь-яка інформація, за якою можна ідентифікувати людину: ім'я, email, телефон, IP-адреса, ідентифікатор пристрою, геолокація, історія замовлень. Принципи GDPR (стаття 5), на які орієнтуються й українське законодавство, і більшість сучасних регуляцій:

1. Мінімізація даних - збирати лише те, що потрібно для конкретної мети. Не просити дату народження, якщо достатньо підтвердити вік; не зберігати повний номер картки, якщо потрібні останні 4 цифри.

2. Обмеження мети - дані, зібрані для доставки замовлення, не використовуються для розсилки без окремої згоди.

3. Обмеження зберігання - дані зберігаються не довше, ніж потрібно. Неактивні облікові записи, старі журнали з IP-адресами, логи запитів - видаляються чи анонімізуються за розкладом (у Laravel - Prunable/MassPrunable моделі й запланована model:prune).

4. Точність - користувач може виправити свої дані.

5. Цілісність і конфіденційність - захист від несанкціонованого доступу: шифрування, контроль доступу, журнали дій.

6. Законність і прозорість - зрозуміла політика конфіденційності, правова підстава обробки (згода, договір, законний інтерес).

Що це означає в коді:

• права користувача: експорт своїх даних, видалення облікового запису (з даними, що за ним стоять, - включно з резервними копіями за розумний час), відкликання згоди;
• персональні дані не потрапляють у журнали й системи моніторингу без потреби (маскування email, телефонів, токенів);
• розділення доступу: не всі співробітники бачать усі дані; адмінка з журналом переглядів чутливих записів;
• шифрування особливо чутливих полів (документи, медичні дані) - каст encrypted у Laravel;
• тестові дані: не копіювати продакшен-базу з реальними людьми на ноутбуки розробників без анонімізації;
• сторонні сервіси (аналітика, CRM, LLM) отримують лише потрібне, з договором обробки даних.

Витік персональних даних - юридична подія: GDPR вимагає повідомити наглядовий орган протягом 72 годин після виявлення, якщо витік несе ризик для людей. План дій має бути готовий заздалегідь.

Докладніше в документації: GDPR, стаття 5: принципи обробки