3.2 Testing for Cookies Attributes
Суть вразливості:
Веб-файли cookie часто є ключовим вектором атаки для зловмисних користувачів (зазвичай націлених на інших користувачів цієї програми), тому програма завжди повинна виявляти належну обачність для захисту файлів cookie користувачів.
Найчастіше використовуваним механізмом зберігання сеансів у браузерах є зберігання файлів cookie. Файли cookie можуть бути встановлені сервером за допомогою заголовка Set-Cookie у HTTP-відповіді або через JavaScript. Файли cookie можуть використовуватися для багатьох випадків, таких як:
- Управління сеансом
- Персоналізація
- Відстеження
Щоб захистити дані файлів cookie, галузь розробила засоби, які допомагають заблокувати ці файли та обмежити їх від атак. Згодом файли cookie стали переважним механізмом зберігання для веб-застосунків, оскільки вони надають гнучкість у використанні та захисті даних.
Засоби захисту файлів cookie:
Як протестувати
Нижче буде обговорено опис кожного атрибуту та префікса. Тестувальник повинен підтвердити, що вони використовуються правильно додатком. Файли cookie можна перевіряти за допомогою перехоплюючого проксі.
Атрибути файлів cookie:
1) Secure Attribute
Атрибут Secure повідомляє браузеру надсилати cookie тільки в тому випадку, якщо запит надсилається безпечним каналом, наприклад HTTPS. Це допоможе захистити cookie від передачі у незашифрованих запитах. Якщо програма працює через HTTP і HTTPS, то зловмисник може перенаправити користувача на HTTP протокол, щоб можна було перехопити користувача запит і витягнути з нього куку.
2) HttpOnly Attribute
Атрибут HttpOnly використовується для запобігання атакам, таким як витік сеансу, оскільки він не дозволяє злити файлу cookie через клієнтський скрипт, такий як JavaScript. Це не обмежує всю поверхню XSS-атак, але надзвичайно обмежує досяжність векторів XSS-атак. У цьому випадку перехоплення куки зловмисником.
3) Domain Attribute
Атрибут Domain визначає, які хости можуть отримувати cookie. Якщо домен збігається або якщо це піддомен основного домену, домен перевірятиме налаштування Path Attribute. Зверніть увагу, що тільки ті хости, які належать доданому домену, можуть встановлювати cookie.
За замовчуванням куки є лише тому домену, який його надав. Наприклад, куки, які були встановлені сайтом site.com, не будуть доступні на сайті other.com. Але що цікавіше, ми не зможемо отримати ці куки на піддомені forum.site.com.
// на site.com
document.cookie = "user=John"
// на forum.site.com
alert(document.cookie); // ні user
Але, якщо ми все ж таки хочемо дати піддоменам типу forum.site.com доступ до куки, це можна зробити. Достатньо при установці куки на сайті site.com як значення опції domain вказати кореневий домен: domain=site.com:
// перебуваючи на сторінці site.com
// зробимо куки доступним для всіх піддоменів *.site.com:
document.cookie = "user=John; domain=site.com"
// пізніше
// на forum.site.com
alert(document.cookie); // є куки user=John
З історичних причин установка domain=.site.com (з точкою перед site.com) також працює і дозволяє доступ до cookie для піддоменів. Це старий запис, але можна використовувати його, якщо потрібно, щоб підтримувалися дуже старі браузери. Таким чином, опція domain дозволяє нам дозволити доступ до cookie для піддоменів.
4) Path Attribute
Path Attribute відіграє важливу роль у налаштуванні файлів cookie у поєднанні з доменом. Крім домену, можна вказати URL-адресу, для якої дійсний файл cookie. Якщо домен і шлях збігаються, файл cookie буде відправлений у запиті. Як і у випадку з Domain Attribute, якщо Path Attribute встановлено занадто вільно, він може залишити програму вразливою для атак. Наприклад, якщо Path Attribute був встановлений на root/ веб-сервер, файли cookie додатків будуть надіслані кожному додатку в тому ж домені (якщо кілька програм знаходиться на одному сервері). Пара прикладів для кількох програм на одному сервері:
path=/bank
path=/private
path=/docs
path=/docs/admin
5) Expires Attribute
Expires Attribute використовується для:
- установки кук
- обмеження тривалості життя сесії, якщо сесія триває надто довго
- примусово видалити cookie, встановивши для нього минулу дату
На відміну від сеансових файлів cookie, постійні файли cookie будуть використовуватися браузером до закінчення терміну дії cookie. Після закінчення терміну дати встановленого часу браузер видалить файл cookie.
6) SameSite Attribute
Атрибут SameSite використовується для підтвердження того, що cookie не слід надсилати разом із міжсайтовими запитами. Ця особливість дозволяє серверу зменшити ризик витоку інформації між організаціями. Цей атрибут можна налаштувати у трьох різних режимах:
- Strict
- Lax
- None
Strict - це найбільше обмежувальне використання SameSite, що дозволяє браузеру відправляти cookie тільки першим особам. контекст без навігації верхнього рівня. Іншими словами, дані, пов'язані з файлом cookie, будуть надсилатись лише за запитами, що відображаються в адресному рядку браузера. Файл cookie не надсилатиметься за запитами, створеними третіми особами, на партійні сайти. Це значення особливо рекомендується для дій, які виконуються в одному домені. Однак він може призводити до деяких обмежень у системі керування сеансами. Може негативно впливати на навігацію користувача, оскільки браузер не надсилатиме файли cookie за будь-якими запитами, згенерованими зі стороннього домену або електронної пошти, відповідно користувачеві потрібно знову увійти в систему, навіть якщо у нього і так вже є автентифікований сеанс.
Lax – менш обмежений, ніж Strict. Файл cookie буде надіслано, якщо URL-адреса дорівнює домену файлу cookie (спочатку party), навіть якщо посилання йде з стороннього домену. Це значення вважається дефолтним налаштуванням браузерів. Оскільки воно забезпечує кращий досвід користувача, ніж значення Strict. Він не запускається для об'єктів, таких як зображення, де файли cookie можуть не знадобитися для доступу до них.
None - вказує, що браузер відправлятиме cookie при міжсайтових запитах (нормальна поведінка до реалізації SamseSite), тільки якщо також використовується атрибут Secure, наприклад SameSite = None; Secure. Це рекомендоване значення замість того, щоб не вказувати будь-яке значення SameSite, оскільки воно змушує використовувати Secure атрибут.
7) Cookie Prefixes
За промовчанням файли cookie не можуть гарантувати цілісність та конфіденційність інформації, що зберігається в них. Ці обмеження не дозволяють серверу бути впевненим у тому, як були задані атрибути cookie. Щоб надати серверам такі функції із зворотною сумісністю, галузь ввела концепцію префіксів імен файлів cookie для полегшення передачі таких відомостей, які вбудовані в ім'я файлу cookie.
- Host Prefix
Host-припускає, що файли cookie будуть відповідати наступним умовам:
1. Файл cookie має бути встановлений із атрибутом Secure.
2. Файл cookie повинен бути встановлений з URI, який користувач вважає безпечним.
3. Надсилається тільки тому хосту, який встановив cookie, і НЕ ПОВИНЕН включати будь-які атрибути Domain.
4. Файл cookie має бути встановлений з атрибутом Path зі значенням / щоб він відправлявся на кожен запит до хоста.
Тому файл cookie Set-Cookie: Host-SID = 12345; Secure; Path = / буде прийнято, поки будь-який з наступних відхилятиметься: Set-Cookie: Host-SID = 12345 Set-Cookie: Host-SID = 12345; Secure Set-Cookie: Path=/Host-SID=12345; Domain = site.example Set-Cookie: Host-SID = 12345; Domain = site.example; Set-Cookie: Host-SID = 12345; Secure; Domain = site.example; Path = /
- Secure Prefix
Він менш суворий і може бути введений шляхом додавання чутливого до регістру рядка Secure- в ім'я файлу cookie. Очікується, що будь-який файл cookie, що відповідає префіксу Secure-, задовольнятиме наступні умови:
1. Файл cookie має бути встановлений із атрибутом Secure.
2. Файл cookie повинен бути встановлений з URI, який користувач вважає безпечним.
Інструменти
OWASP Zed Attack Proxy Project (ZAP) - имеет механизм анализа токена.
Browser Plug-in
