3.1 Testing for Session Management Schema
Суть вразливості:
Одним з основних компонентів будь-якого веб-додатку є механізм, за допомогою якого він контролює та підтримує стан користувача, щоб взаємодіяти з ним. Щоб уникнути безперервного прохання пройти автентифікацію для кожної сторінки веб-сайту або служби, веб-програми реалізують різні механізми зберігання та перевірки облікових даних протягом заздалегідь визначеного періоду часу. Ці механізми відомі як керування сеансом.
У цьому тесті тестувальник хоче перевірити, що файли cookie та інші токени сеансу створюються у безпечному та непередбачуваному режимі. Зловмисник, який може передбачити і підробити слабкий cookie-файл, може легко захопити сеанси законних користувачів.
Файли cookie використовуються для реалізації керування сеансами і детально описані в RFC 2965. Коротко, коли користувач звертається до програми, яка повинна відстежувати дії та особистість цього користувача за кількома запитами, файл cookie (або cookie) генерується сервером і відправляється клієнту. Потім клієнт відправить файл cookie назад на сервер у всіх наступних підключеннях, поки термін дії cookie не закінчиться або не буде знищений. Дані, що зберігаються у файлі cookie, можуть надати на сервері великий спектр інформації про те, хто користувач, які дії він здійснив досі, які переваги і т.д.
Типовий приклад – кошик для покупок в Інтернеті. Протягом усього сеансу користувача додаток повинен зберігати та відстежувати його особистість, його профіль, продукти, які він вибрав для покупки, кількість, індивідуальні ціни, знижки, тощо. (інші методи - це параметри URL та приховані поля). Через важливість даних, які вони зберігають, файли cookie мають життєво важливе значення для спільної безпеки програми.
Можливість втручання у файли cookie може призвести до захоплення сеансів законних користувачів, отримання більш високих привілеїв в активних сеансах і загалом несанкціонований вплив на роботу програми. У цьому тесті тестувальник повинен перевірити, чи можуть файли cookie, видані клієнтам, протистояти широкому спектру атак, спрямованих на перешкоду законним користувачам та самому додатку. Загальна мета - створити файл cookie, який вважатиметься дійсним додатком і забезпечить несанкціонований доступ (сеанс викрадення, підвищення привілеїв тощо).
Зазвичай основні атаки такі:
- Збір файлів cookie: збір достатньої кількості зразків файлів cookie;
- Зворотній інжиніринг файлів cookie: аналіз алгоритму генерації файлів cookie;
- Маніпуляція cookie: підробка дійсного cookie для виконання атаки. Останній крок може вимагати великої кількості спроб, залежно від того, як створюється cookie (атака методом грубої сили).
Інший варіант атаки полягає у переповненні файлу cookie. Власне кажучи, ця атака має іншу природу, тому що тут тестувальники не намагаються відтворити дійсний файл cookie. Натомість мета полягає в тому, щоб переповнити область пам'яті, тим самим втручання у правильну поведінку програми та можливе впровадження (і віддалене виконання) шкідливого коду.
Як протестувати
Усі взаємодії між клієнтом та додатком мають бути протестовані як мінімум за такими критеріями:
- Чи всі директиви Set-Cookie позначені як Secure?
- Чи виконуються якісь операції з файлами cookie у незашифрованому вигляді?
- Чи можна примусово передати cookie через незашифрований канал?
- Постійні файли cookie?
- Який час закінчення терміну використовується для файлів cookie і чи розумно воно?
- Чи налаштовані файли cookie, які, як очікується, будуть тимчасовими?
- Які налаштування HTTP/1.1 Cache-Control використовуються для захисту файлів cookie?
- Які налаштування HTTP/1.0 Cache-Control використовуються для захисту файлів cookie?
Збір файлів cookie
Перший крок, необхідний для керування файлом cookie, - це зрозуміти, як додаток створює файли cookie та керує ними. У цьому завдання тестувальники повинні спробувати відповісти на такі питання:
- Скільки файлів cookie використовує програму? Перегляньте програму. Зверніть увагу, коли створюються файли cookie. Складіть список отриманих файлів cookie, сторінку, яка встановлює їх (з директивою set-cookie), домен, для якого вони дійсні, їх значення та їх характеристики. - Які частини програми створюють або змінюють cookie? Переглядаючи програму, знайдіть, які файли cookie залишаються постійними, а які змінюються.
- Які частини програми потребують файл cookie для доступу та використання? Дізнайтеся, які частини програми потрібен файл cookie. Відкрийте сторінку і спробуйте ще раз без файлу cookie або зі зміненим значенням запросити доступ. Спробуйте порівняти, які файли cookie та де використовуються. Електронна таблиця, яка зіставляє кожен файл cookie з відповідними частинами програми та пов'язаною інформацією, може спростити роботу.
Сесійний аналіз
Самі токени сеансу (Cookie, SessionID або Hidden Field) повинні бути перевірені, щоб переконатися в їх якості та безпеці. Їх слід тестувати за такими критеріями, як на випадковість, унікальність, стійкість до статистичної та криптографічної інформації.
- Структура токена та витік інформації
Перший етап - вивчити структуру та зміст ідентифікатора сеансу, наданого додатком. Поширена помилка тут - це включення певних даних у токен замість видачі загального значення та посилання на серверну сторону даних.
Якщо ідентифікатор сеансу знаходиться у відкритому тексті, структура та відповідні дані можуть бути відразу очевидними, наприклад 192.168.100.1:owaspuser:password:15:58.
Якщо здається, що частина або весь токен закодований або хешований, його слід порівняти з різними методами, щоб перевірити чи очевидна заплутаність. Наприклад, рядок 192.168.100.1:owaspuser:password:15:58 представлена у шістнадцятковому форматі, Base64 і як хеш MD5:
- Hex: 3139322E3136382E3130302E313A6F77617370757365723A70617373 776F72643A31353A3538
- Base64: MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
- MD5: 01c2fc4f0a817afd8366689bd29dd40a
Після аналізу одного токена сеансу слід вивчити репрезентативну вибірку. Наприклад, 32-бітний токен може включати 16 біт статичних даних і 16 біт змінних даних. Це може вказувати на те, що перші 16 біт представляють фіксований атрибут користувача - наприклад ім'я користувача або IP-адресу. Якщо другий 16-бітний фрагмент збільшується з постійною швидкістю, це може вказувати на послідовний або навіть на основі часу елемент для генерації токена.
Якщо визначені статичні елементи токенів, необхідно зібрати додаткові зразки, варіюючи один потенційний вхідний елемент. Наприклад, спроби входу в систему через інший обліковий запис користувача або з іншої IP-адреси можуть призвести до відхилення раніше створеної статичної частини токена сеансу.
Наступні області повинні бути розглянуті під час тестування структури одиночного та множинного ідентифікатора сеансу:
– Які частини ідентифікатора сеансу статичні?
- Яка конфіденційна інформація у відкритому вигляді зберігається в ідентифікаторі сеансу? Наприклад. імена користувачів / UID, IP-адреси
- Яка конфіденційна інформація, яку можна легко розшифрувати, зберігається?
- Яку інформацію можна вивести із структури ідентифікатора сеансу?
- Які частини ідентифікатора сеансу статичні для тих самих умов входу в систему?
- Які очевидні закономірності є в ідентифікаторі сеансу в цілому або в окремих частинах?
Передбачуваність та випадковість ідентифікатора сеансу
Слід провести аналіз змінних областей (якщо є) ідентифікатора сеансу, щоб встановити наявність будь-яких відомих чи передбачуваних закономірностей. Ці аналізи можуть виконуватися вручну та з використанням індивідуальних або OTS-статистичних даних. або криптоаналітичних інструментів для виявлення будь-яких закономірностей у вмісті ідентифікатора сеансу. Ручні перевірки повинні включати порівняння Ідентифікатора сеансу, виданих для тих самих умов входу в систему, наприклад, одного і того ж імені користувача, пароля та IP-адреси.
Час – важливий фактор, який також необхідно контролювати. Слід виконувати велику кількість одночасних підключень, щоб зібрати зразки в одному часовому вікні та зберегти цю змінну постійною. Навіть 50 мс може бути занадто грубим, і зразок, взятий таким чином, може виявити компоненти, що залежать від часу.
Зворотній інжиніринг файлів cookie
Тепер, коли тестувальник перерахував файли cookie і отримав загальне уявлення про їх використання, настав час детальніше вивчити куки, які здаються цікавими. Які файли cookie цікавлять тестувальника? Файл cookie для забезпечення безпечного методу управління сеансом повинен поєднувати в собі кілька характеристик, кожна з яких спрямована на захист файлу cookie від різних атак.
Ці характеристики коротко описані нижче:
1. Непередбачуваність: файл cookie повинен містити кілька даних, які важко вгадати. Чим складніше підробити файл cookie, що діє, тим складніше зламати сеанс законного користувача. Якщо зловмисник може вгадати cookie, який використовується в активному сеансі законного користувача, вони зможуть повністю видати себе за цього користувача (здійснити захоплення сеансу).
2. Стійкість до злому: файл cookie має протистояти зловмисним спробам модифікації. Якщо тестувальник отримує cookie типу IsAdmin = No, його легко змінити для отримання адміністративних прав
3. Термін дії: критичний файл cookie повинен бути дійсним лише протягом певного періоду часу і повинен бути видалений з диска або пам'яті, щоб уникнути ризику повторного відтворення. Це не стосується файлів cookie, де зберігаються некритичні дані. які необхідно пам'ятати під час сеансів (наприклад, про зовнішній вигляд сайту).
4. Прапор Secure: для файлу cookie, значення якого є критичним для цілісності сеансу, цей прапор повинен бути увімкнений, щоб дозволити його передачу тільки в зашифрованому каналі для запобігання підслуховування.
Ще один аспект, який слід враховувати, – це час. Завжди записуйте точний час отримання файлу cookie, коли є можливість, що час відіграє роль у значенні файлу cookie (сервер може використовувати мітку часу як частину значення cookie). Записаний час може бути місцевим або тимчасовим штампом сервера, включеним у відповідь HTTP. (або обидва). При аналізі зібраних значень тестувальник повинен спробувати з'ясувати всі змінні, які могли вплинути на значення cookie та намагайтеся міняти їх по одному. Передача на сервер змінених версій одного і того ж файлу cookie може дуже допомогти зрозуміти, як програма зчитує та обробляє cookie.
Приклади перевірок, які необхідно виконати на цьому етапі, включають:
- Який набір символів використовується у файлі cookie? Чи має кукі числове значення? буквено-цифровий? шістнадцятковий? Що відбувається, якщо тестер вставляє в cookie символи, які не належать до очікуваного кодування?
- Чи файл cookie складається з різних частин, що містять різну інформацію? Як різні частини поділені? З якими роздільниками? Деякі частини файлу cookie можуть мати вищу дисперсію, інші можуть бути постійними, інші можуть приймати лише обмежений набір значень. Розбити файл cookie на його базові компоненти – це перший та фундаментальний крок.
Ось приклад структурованого файлу cookie, який легко виявити:
ID = 5a0acfc7ffeb919: CR = 1: TM = 1120514521: LM = 1120514521: S = j3am5KzC4v01ba3q
У цьому прикладі показано 5 різних полів, що містять різні типи даних:
- ID - шістнадцятковий
- CR - невелике ціле число TM та LM
- велике ціле число. (І, як не дивно, вони мають однакове значення. Варто подивитися, що відбувається при зміні одного з них)
S - буквено-цифровий Навіть якщо розподільники не використовуються, наявність достатньої кількості зразків може допомогти зрозуміти структуру.
Атаки грубої сили або Bruteforce
Атаки методом грубої сили неминуче виникають через питання, що стосуються передбачуваності та випадковості. Якщо варіація в межах Ідентифікатора сеансу відносно мала, а термін дії ідентифікатора сеансу довгий, можливість успішної атаки повним перебором дуже висока.
Довгий ідентифікатор сеансу та більш короткий термін дії значно ускладнять завдання досягти успіху в атаці методом грубої сили.
- Скільки часу займе атака шляхом перебору всіх можливих ідентифікаторів сеансу?
- Чи достатньо простір ідентифікатора сеансу, щоб запобігти брутфорсу? Наприклад, чи достатня довжина ключа, порівняно з тривалістю життя, що діє?
- Чи знижують затримки між спробами підключення до різних ідентифікаторів сеансу ризик цієї атаки?
Інструменти
OWASP Zed Attack Proxy Project (ZAP) - имеет механизм анализа токена.
