3.9 Testing for Session Hijacking
Суть вразливості:
Зловмисник, який отримав доступ до файлів cookie користувача, може видати себе за нього. Ця атака відома як захоплення сеансу. При розгляді мережевих злодій, тобто зловмисники, які контролюють мережу, яку використовує і жертва, де файли cookie можуть бути відкриті зловмиснику за протоколом HTTP. Щоб запобігти цьому, cookie повинні бути позначені атрибутом Secure, щоб вони передавалися лише за HTTPS.
Зверніть увагу, що атрибут Secure також слід використовувати, коли веб-програма повністю розгорнута на HTTPS, в іншому випадку можлива наступна атака крадіжки cookie. Припустимо, що example.com повністю розгорнутий по HTTPS, але вони не позначені атрибутом Secure. І тоді можливі такі кроки атаки:
1. Жертва надсилає запит на http://another-site.com.
2. Зловмисник спотворює відповідну відповідь та запускає запит до http://example.com.
3. Тепер браузер намагається отримати доступ до http://example.com.
4. Хоча запит не виконується, сеансові файли cookie пропускаються через HTTP.
Повне впровадження HSTS описано у статті Стефано Кальзавара під назвою «Тестування недоліків цілісності у веб-сесіях». Повне прийняття HSTS відбувається, коли хост активує HSTS собі і всі його піддомени. Часткове використання HSTS - це коли хост активує HSTS тільки для себе.
З встановленим атрибутом Domen файли cookie можуть спільно використовуватися піддоменами. Використовувати HTTP із субдоменами слід уникати, щоб запобігти розкриттю незашифрованих файлів cookie, надісланих HTTP. Щоб проілюструвати цей недолік безпеки, припустимо, що сайт example.com активує HSTS без опції includeSubDomains. Можлива наступна атака:
1. Жертва надсилає запит на http://another-site.com.
2. Зловмисник спотворює відповідну відповідь та запускає запит до http://fake.example.com.
3. Тепер браузер намагається отримати доступ до http://fake.example.com, що дозволено конфігурацією HSTS.
4. Оскільки запит надсилається в піддомен example.com із встановленим атрибутом Domain, він включає сеанс файлів cookie, які передаються у відкритому вигляді через HTTP.
Повний HSTS повинен бути активований у вершині домену, щоб запобігти цій атакі.
Як протестувати
Ось кроки для виконання цього тесту:
1. Увійдіть на сайт як жертва та перейдіть на будь-яку сторінку, яка потребує аутентифікації.
2. Видаліть із сховища файлів cookie всі файли cookie, які відповідають таким умовам:
- у разі відсутності прийняття HSTS: встановлено атрибут Secure.
- у разі часткового впровадження HSTS: встановлено атрибут Secure або не встановлено атрибут Domain.
3. Збережіть значення сховища cookie.
4. Очистіть сховище cookie, увійдіть у систему як зловмисник і перейдіть на сторінку в кроці 1.
5. Запишіть у сховищі для файлів cookie один за одним файли cookie, збережені на кроці 3.
6. Знову запустіть безпечну функцію, вказану на кроці 1.
7. Очистіть сховище з файлами cookie і знову увійдіть у систему як жертву.
8. Перегляньте, чи успішно було здійснено операцію на кроці 6 в обліковому записі жертви. Якщо так, то атака була успішною. В іншому випадку сайт захищений від злому сеансу.
Рекомендується використовувати дві різні машини або браузера для жертви та зловмисника. Це дозволяє зменшити кількість помилкових спрацьовувань, якщо веб-програма знімає фінгерпринт, щоб перевірити, чи дозволено доступ з файлу cookie.