search

oleksandrblazhko / ai-191-nikitin

0 stars 0 forks source link

CW5 #25

Closed NikitunPVLK closed 8 months ago

NikitunPVLK commented 8 months ago

Запитання №1 (1 бал)

В лабораторній роботі №5 вами було розглянуто декілька описів тестів з документу OWASP Web Security Testing Guide. Для кожного тесту вкажіть, з якими вразливостями OWASP Top 10 версії 2021 року тест пов’язано - https://owasp.org/Top10/

Запитання № 2 (1 бал)

В лабораторній роботі №6 вами було розглянуто приклади вимог до безпечного ПЗ з документу OWASP Application Security Verification Standard. Для кожного розглянутого підрозділу вимог вкажіть, з якими вразливостями OWASP Top 10 версії 2021 року цей підрозділ пов’язано https://owasp.org/Top10/

Запитання № 3 (3 бали)

В описах вразливостей OWASP Top 10 версії 2021 року є підрозділ «Example Attack Scenarios». Візміть одну вразливість, розглянуту в попередніх рішеннях, та, аналізуючи опис «Example Attack Scenarios», запропонуйте три тестові сценарії перевірки наявності вразливості. Кожний тестовий сценарій повинен містити:

  1. окремий розділ з описом дій (кроків) тестувальника, які дозволяють перевірити на наявність вразливості у форматі, наприклад, крок 1 – опис ..., крок 2 – опис ...
  2. опис очікуємого результату, який підтверджує наявність вразливлості.
NikitunPVLK commented 8 months ago

Запитання №1

Testing for Incubated Vulnerability

  1. A03:2021-Injection
  2. A05:2021-Security Misconfiguration
  3. A06:2021-Vulnerable and Outdated Components
  4. A07:2021-Identification and Authentication Failures

Testing for Error Code

  1. A01:2021-Broken Access Control
  2. A02:2021-Cryptographic Failures
  3. A03:2021-Injection
  4. A05:2021-Security Misconfiguration
  5. A09:2021-Security Logging and Monitoring

Запитання №2

CWE-640: Weak Password Recovery Mechanism for Forgotten Password

  1. A01:2021-Broken Access Control
  2. A02:2021-Cryptographic Failures
  3. A05:2021-Security Misconfiguration
  4. A07:2021-Identification and Authentication Failures
  5. A09:2021-Security Logging and Monitoring Failures

CWE-304: Missing Critical Step in Authentication

  1. A01:2021-Broken Access Control
  2. A02:2021-Cryptographic Failures
  3. A05:2021-Security Misconfiguration
  4. A07:2021-Identification and Authentication Failures
  5. A09:2021-Security Logging and Monitoring Failures

CWE-308: Use of Single-factor Authentication

  1. A01:2021-Broken Access Control
  2. A05:2021-Security Misconfiguration
  3. A07:2021-Identification and Authentication Failures

CWE-613: Insufficient Session Expiration

  1. A01:2021-Broken Access Control
  2. A05:2021-Security Misconfiguration
  3. A07:2021-Identification and Authentication Failures

Запитання №3

A07:2021-Identification and Authentication Failures

Сценарій 1

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

Кроки для перевірки

Крок 1: Збір даних: Зібрати інформацію про цільове ПЗ, включаючи його сторінку входу та механізми автентифікації.

Крок 2: Створення списку паролів: Скласти список відомих паролів, що часто використовуються, або паролів, що стали відомі в результаті попередніх зломів.

Крок 3: Автоматизована перевірка облікових даних: Використовуючи автоматизовані інструменти для систематичного тестування, виконати тестування ПЗ шляхом багаторазового введення імен користувачів та паролів зі складеного списку.

Крок 4: Аналіз відповідей: Проаналізувати відповіді від додатку після кожної спроби входу та перевірити, чи програма надає різні відповіді на правильні та неправильні спроби входу.

Крок 5: Аналіз логів: Якщо можливо, проаналізувати журнали на предмет виявлення шаблонів багаторазових невдалих спроб входу з однієї IP-адреси або незвичної активності.

Очікуваний результат

  1. Тестувальник повинен успішно увійти в систему за допомогою автоматизованого інструменту зі значною кількістю імен користувачів та паролів зі списку.
  2. ПЗ повинно послідовно відповідати певним повідомленням або поведінкою, вказуючи на те, чи була спроба входу успішною чи ні.

Сценарій 2

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

Кроки для перевірки

Крок 1: Оцінка складності пароля Cтворити обліковий запис зі слабким паролем, наприклад, зі звичайним словниковим словом або простою комбінацією (наприклад, "password" або "123456"). Проаналізувати, чи дозволяє система створити обліковий запис з паролем, який не відповідає вимогам складності.

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

Крок 3: Відсутність багатофакторної автентифікації Увійти в систему і перевірити, чи не ввімкнена багатофакторна автентифікація. Переконатися, що система покладається лише на ім'я користувача та пароль без додаткових факторів (наприклад, OTP, біометричних даних) для автентифікації.

Очікуваний результат

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

Сценарій 3

Тайм-аути сеансу програми встановлені неправильно. Користувач використовує загальнодоступний комп'ютер для доступу до програми. Замість того, щоб вибрати "вийти", користувач просто закриває вкладку браузера і йде геть. Через годину зловмисник використовує той самий браузер, і користувач все ще авторизований.

Кроки для перевірки

Крок 1: Початковий вхід: Увійти до системи, використовуючи дійсні облікові дані на загальнодоступному комп'ютері.

Крок 2: Навігація та підтвердження входу: Отримати доступ до різних функцій програми, щоб підтвердити, що користувач успішно увійшов до системи.

Крок 3: Закрити вкладку браузера: Замість того, щоб вибрати "вихід", закрити вкладку браузера або все вікно браузера.

Крок 4: Не дочекайтися завершення сеансу: Зачекати менше, ніж очікуваний період таймауту сеансу.

Крок 5: Перезапустити браузер: Повторно відкрити браузер на тому ж загальнодоступному комп'ютері, який використовувався спочатку.

Крок 6: Доступ до системи: Спробувати знову отримати доступ до системи без надання облікових даних.

Крок 7: Перевірити наявність активного сеансу: Знайти будь-які ознаки того, що сеанс попереднього користувача все ще активний без повторної автентифікації.

Крок 8: Спроба несанкціонованих дій: Якщо сеанс все ще активний, спробувати виконати дії, які вимагають автентифікації, наприклад, отримати доступ до конфіденційних даних або змінити налаштування облікового запису.

Очікуваний результат

  1. Після перезапуску браузера є змога отримати доступ до системи без повторного введення облікових даних.
  2. Є можливість виконувати дії в системі без запиту на повторний вхід, що вказує на те, що сесія все ще активна.
  3. Зловмисник може скористатися сценарієм, коли користувач виходить з системи, не закінчивши сесію.
oleksandrblazhko commented 8 months ago

5 балів