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

Три способи знаходити вразливості руками людей - з різними цілями, вартістю й зрілістю, яку вони вимагають від команди.

Пентест (тестування на проникнення):

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

VDP (Vulnerability Disclosure Policy, політика розкриття вразливостей):

• публічна політика: як повідомити про вразливість, що дозволено досліджувати, що ні, як ви реагуєте і що не будете переслідувати дослідників, які діяли добросовісно;
• без грошової винагороди (подяка, згадка в зали слави);
• мінімальна вимога для будь-якої організації - разом із security.txt. Без неї люди, що випадково знайшли проблему, не знають, куди писати, і бояться юридичних наслідків.

Bug bounty:

• VDP з грошовими винагородами залежно від серйозності, зазвичай через платформи (HackerOne, Bugcrowd, Intigriti);
• безперервна перевірка багатьма дослідниками з різними навичками;
• плюси: платите за результат, покриття нових релізів;
• мінуси: потік звітів, частина з яких - дублікати й низькоякісні знахідки; потрібна команда, що швидко розбирає звіти й виправляє проблеми. Запуск bug bounty без зрілих процесів обертається завалом звітів і поганою репутацією серед дослідників.

Рекомендована послідовність зрілості:

1. базова гігієна й автоматизовані перевірки (SAST, SCA, DAST);
2. VDP і security.txt - канал для повідомлень;
3. пентест перед важливими релізами й регулярно (раз на рік чи після великих змін);
4. приватний bug bounty (запрошені дослідники), потім публічний - коли процес обробки налагоджено.

Що важливо в будь-якому варіанті:

• чіткі межі: що можна тестувати (staging чи продакшен), що заборонено (DoS, соціальна інженерія, доступ до даних реальних користувачів);
• терміни реакції: підтвердження отримання, оцінка, виправлення, повідомлення досліднику;
• координоване розкриття: публікація подробиць - після виправлення, за домовленістю з дослідником.

Докладніше в документації: OWASP: розкриття вразливостей

Інцидент - не час вигадувати процес. Порядок дій, ролі й контакти мають бути визначені заздалегідь, інакше паніка коштує годин і доказів. NIST SP 800-61 Rev. 3 (2025) пов'язує реагування на інциденти із загальним керуванням кібербезпекою (CSF 2.0): підготовка, виявлення, реагування, відновлення - як безперервний цикл.

Основні кроки:

1. Виявлення й оцінка. Сповіщення моніторингу, повідомлення клієнта чи дослідника. Перше - зрозуміти масштаб: що скомпрометовано, з якого часу, чи триває атака.

2. Стримування (containment):

• закрити вектор атаки (вимкнути вразливу функцію, правило WAF, заблокувати обліковий запис);
• ротувати скомпрометовані секрети - ключі API, паролі до бази, APP_KEY, токени, сесії користувачів;
• ізолювати уражені сервери, не знищуючи їх - вони потрібні для розслідування.

3. Збереження доказів: журнали, знімки дисків і пам'яті, копії підозрілих файлів - до того, як їх перезапише ротація журналів чи перевстановлення сервера. Записувати хронологію всіх дій.

4. Усунення й відновлення: виправлення вразливості, перевстановлення скомпрометованих систем з чистих образів, відновлення даних з бекапів, створених до компрометації, посилений моніторинг після повернення.

5. Повідомлення:

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

6. Розбір після інциденту (post-mortem) без пошуку винних: як потрапили, чому не помітили раніше, що змінити в процесах і моніторингу. Задачі - в трекер з відповідальними.

Що підготувати заздалегідь:

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

Помилки, яких варто уникати: приховувати інцидент, «тихо виправити» без розслідування масштабу, повідомляти неперевірену інформацію, знищити сервер разом із доказами.

Докладніше в документації: NIST SP 800-61 Rev. 3: реагування на інциденти

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

1. «Відкриття при помилці» (fail-open) - перевірка, що при збої пропускає:

function isAllowed(User $user, string $action): bool
{
    try {
        return $this->permissionService->check($user, $action);
    } catch (Throwable) {
        return true;   // «щоб не блокувати користувачів» - а насправді вимкнений контроль доступу
    }
}

Сервіс прав недоступний - і всі отримують доступ. Правильно - закриття при помилці (fail-closed): відмова й запис у журнал.

Те саме з перевіркою підпису вебхука, ліцензії, ліміту запитів, антифроду: виняток не повинен означати «перевірку пройдено».

2. Незавершені операції й неузгоджений стан. Гроші списано, а замовлення не створено; товар зарезервовано, а оплата впала. Транзакції бази, ідемпотентні операції, компенсуючі дії й узгодження (reconciliation) - щоб помилка посередині не лишала систему в стані, який можна використати.

3. Розкриття інформації через помилки: стеки викликів, SQL-запити, шляхи файлів, внутрішні адреси в повідомленнях про помилки. Користувачу - загальне повідомлення з ідентифікатором, деталі - в журнал.

4. Непередбачені стани як вектор атаки:

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

5. Виснаження ресурсів: необмежені розміри запитів, файлів, масивів, глибина рекурсії, кількість повторів - атака на доступність через «легальні», але завеликі дані.

Як захищатися:

• закривати при помилці в усіх перевірках безпеки;
• обробляти винятки там, де відомо, що робити, а не ковтати їх широкими catch (Throwable);
• транзакції для операцій, що мають виконатися разом;
• обмеження на розміри, кількості, час виконання;
• тести негативних сценаріїв: що станеться, якщо сервіс прав, платіжний шлюз чи Redis недоступні, - і чи безпечний результат;
• моніторинг помилок - сплеск винятків часто означає, що хтось шукає слабке місце.

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

Перевірка безпеки «наприкінці» (пентест перед релізом) знаходить проблеми, коли їх найдорожче виправляти, і перетворює безпеку на перешкоду. Ідея shift left - вбудувати безпеку в кожен етап.

1. Вимоги й дизайн:

• вимоги безпеки в задачах: «доступ лише власнику», «ліміт 5 спроб на хвилину», «журналювати зміну ролі» - як звичайні критерії приймання;
• OWASP ASVS (Application Security Verification Standard, актуальна версія 5.0) - перелік перевірних вимог за рівнями: L1 для більшості застосунків, L2 для застосунків з чутливими даними, L3 для критичних систем. Зручно брати як джерело критеріїв, а не вигадувати їх щоразу;
• моделювання загроз для функцій, що зачіпають автентифікацію, платежі, файли, персональні дані.

2. Розробка:

• безпечні значення за замовчуванням у фреймворку й шаблонах проєкту (Laravel вже дає більшість: екранування, CSRF, підготовлені запити, хешування паролів);
• спільні компоненти для типових задач (завантаження файлів, вебхуки, HTTP-клієнт із захистом від SSRF) - щоб кожен розробник не писав своє;
• тести на безпеку: авторизація кожного ендпойнта, валідація, межі.

3. Перевірка в CI: SAST, аудит залежностей, сканування секретів, сканування образів - автоматично на кожен PR, з блокуванням критичних знахідок.

4. Definition of Done з пунктами безпеки: перевірено права, немає секретів у коді, нові залежності перевірено, події безпеки журналюються, документація оновлена.

5. Експлуатація: моніторинг і сповіщення, регулярні оновлення, DAST проти staging, VDP і security.txt, план реагування на інциденти.

6. Люди:

• security champions - по одному розробнику в команді, що глибше розбирається в безпеці, стежить за практиками й є першою точкою для питань. Масштабується краще, ніж окрема команда безпеки, через яку мають проходити всі рішення;
• навчання на реальних прикладах з власного коду й інцидентів, а не абстрактні курси;
• культура без пошуку винних: про знайдену вразливість мають повідомляти, а не приховувати.

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

OWASP SAMM - модель зрілості, щоб оцінити поточний стан процесів і спланувати поступові покращення, а не все одразу.

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