Безпека вебзастосунків

Урок 01 · 13 хв

OWASP Top 10, мислення атакувальника і контроль доступу

Звідки береться список OWASP, як моделювати загрози і чому IDOR досі на першому місці.

13 хвУрок 1 з 5Є практикаAsk AI до кожного пункту

OWASP (Open Worldwide Application Security Project) це відкрита спільнота, яка публікує безкоштовні гайди з безпеки. Найвідоміший з них, OWASP Top 10, це список найпоширеніших і найнебезпечніших категорій вразливостей вебзастосунків. Його складають на основі даних сотень тисяч реальних застосунків і опитувань спеціалістів. Цей курс іде за редакцією 2021 року, яку досі найчастіше згадують у вимогах і на співбесідах.

Курс продовжує курс «Авторизація і безпека»: там основи cookie, сесій, JWT, CORS і перше знайомство з XSS та SQL-ін'єкціями. Тут ми йдемо глибше: як ці атаки виглядають у реальному коді, де саме ламаються популярні фреймворки і як закрити дірку правильно, а не косметично.

AI

Можна спитати про цей пункт«Суть уроку»

OWASP Top 10:2021

  • A01 Broken Access Control: користувач бачить або змінює чуже. Цей урок.
  • A02 Cryptographic Failures: дані без шифрування, слабкі алгоритми, паролі у відкритому вигляді. Урок 4.
  • A03 Injection: SQL, команди ОС, а також XSS, який у 2021 році включили в цю категорію. Уроки 2 і 3.
  • A04 Insecure Design: дірка в самій логіці, а не в коді. Лікується моделюванням загроз, про нього нижче.
  • A05 Security Misconfiguration: стандартні паролі, увімкнений debug, відкриті бакети, відсутні заголовки. Урок 5.
  • A06 Vulnerable and Outdated Components: старі залежності з відомими CVE. Урок 5.
  • A07 Identification and Authentication Failures: перебір паролів, слабкі сесії, відсутність MFA. Урок 4.
  • A08 Software and Data Integrity Failures: неперевірені оновлення, CI/CD і пакети, яким довіряють наосліп. Урок 5.
  • A09 Security Logging and Monitoring Failures: атака йде тижнями, а ніхто не помічає. Урок 4.
  • A10 Server-Side Request Forgery (SSRF): сервер ходить за URL, який підсунув користувач. Урок 5.
AI

Можна спитати про це правило«Список оновлюється»

AI

Можна спитати про цей пункт«OWASP Top 10:2021»

План курсу

  • Урок 1. Top 10, моделювання загроз, контроль доступу і IDOR.
  • Урок 2. Ін'єкції: SQL, команди ОС, пастки ORM і NoSQL.
  • Урок 3. XSS і CSRF: три види XSS, кодування виводу, CSP, SameSite, CSRF-токени.
  • Урок 4. Автентифікація і секрети: хешування паролів, rate limiting, MFA, секрети поза git, ротація ключів, журнали й моніторинг.
  • Урок 5. SSRF, завантаження файлів, заголовки безпеки, CORS, залежності й ланцюг постачання.
AI

Можна спитати про цей пункт«План курсу»

Мислення атакувальника

Розробник думає: «як зробити, щоб працювало». Атакувальник думає: «що буде, якщо надіслати не те, що чекають». Усе, що приходить від клієнта, він контролює повністю: URL, параметри, тіло запиту, заголовки, cookie, ім'я файлу, навіть поле role у JSON, якого немає у формі. Фронтенд не є захистом: перевірку в браузері обходять одним запитом через curl.

AI

Можна спитати про це правило«Клієнту не можна довіряти»

AI

Можна спитати про цей пункт«Мислення атакувальника»

Моделювання загроз

Threat modeling це звичка ставити чотири питання ще до коду: що ми будуємо, що може піти не так, що ми з цим зробимо і чи добре ми впорались. Достатньо намалювати схему потоків даних (браузер, API, база, сторонні сервіси) і пройтись по кожній стрілці. Для «що може піти не так» зручна абревіатура STRIDE:

  • Spoofing: видати себе за іншого. Захист: автентифікація.
  • Tampering: змінити дані в дорозі або в базі. Захист: підписи, перевірка цілісності, права.
  • Repudiation: «це не я зробив». Захист: журнал дій.
  • Information disclosure: витік даних. Захист: шифрування, контроль доступу.
  • Denial of service: покласти сервіс. Захист: ліміти, таймаути, черги.
  • Elevation of privilege: звичайний користувач стає адміном. Захист: перевірка прав на кожен запит.
AI

Можна спитати про цей пункт«Моделювання загроз»

Broken Access Control і IDOR

IDOR (Insecure Direct Object Reference): сервер бере ідентифікатор з запиту і віддає об'єкт, не перевіривши, чи він належить поточному користувачу. Користувач бачить /api/invoices/1042, міняє на 1043 і читає чужий рахунок. Автентифікація при цьому працює ідеально: користувач справжній, просто об'єкт не його.

Вразливо і виправлено

Ще надійніше вбудувати власника прямо в запит до бази. Тоді забути перевірку неможливо: чужий рядок просто не знайдеться.

Власник у WHERE
AI

Можна спитати про це правило«UUID не замінює перевірку»

AI

Можна спитати про цей пункт«Broken Access Control і IDOR»

Інші форми зламаного доступу

  • Підвищення привілеїв через тіло запиту (mass assignment): PATCH /me з полем role: admin, а сервер зберігає весь об'єкт. Лікується білим списком полів.
  • Адмінські маршрути без перевірки ролі: кнопки немає в інтерфейсі, але DELETE /api/users/7 працює для всіх.
  • Довіра до прихованих полів: price чи userId з форми замість значень із сесії і бази.
  • Відкриті за замовчуванням ресурси: нова сторінка чи endpoint без middleware автоматично доступні всім.
Білий список полів замість усього body
AI

Можна спитати про це правило«Deny by default»

AI

Можна спитати про цей пункт«Інші форми зламаного доступу»

Перевірка

Закріпи, поки не пішов далі

  1. 1. Користувач міняє /api/orders/15 на /api/orders/16 і бачить чуже замовлення. Як це називається?

  2. 2. Чи закриває IDOR перехід з числових id на UUID?

  3. 3. Кнопку видалення сховали для звичайних користувачів. Чого бракує?

  4. 4. Яка літера STRIDE відповідає за «звичайний користувач отримав права адміна»?

Читати далі
ПрактикаРозв’яжи задачі урокуКілька коротких завдань у редакторі. Перевіряй код одразу й бач, де помилка.Почати практику