3.3 Testing for Session Fixation

Суть вразливості:

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

Уразливості фіксації сеансу виникають, коли:

- Веб-додаток аутентифікує користувача без попереднього анулювання існуючого ідентифікатора сеансу, продовжуючи тим самим використовувати ідентифікатор сеансу, раніше пов'язаний з користувачем.

- Зловмисник може нав'язати користувачеві відомий ідентифікатор сеансу, щоб після автентифікації користувача зловмисник міг мати доступ до автентифікованого сеансу.

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

Як протестувати

Тестування на вразливість фіксації сеансу Насамперед потрібно надіслати запит на сайт, що тестується (наприклад, www.example.com). Якщо тестувальник запитує наступне:

GET www.example.com

Вони отримають таку відповідь:

HTTP/1.1 200 OK

Date: Wed, 14 Aug 2008 08:45:11 GMT

Server: IBM_HTTP_Server

Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure

Cache-Control: no-cache="set-cookie,set-cookie2"

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Content-Type: text/html;charset=Cp1254

Content-Language: en-US

Програма встановлює новий ідентифікатор сеансу JSESSIONID = 0000d8eyYq3L0z2fgq10m4v-rt4: -1 для клієнта. Потім, якщо тестувальник успішно аутентифікується у додатку за допомогою наступного POST HTTPS:

POST https://www.example.com/authentication.php HTTP/1.1

Host: www.example.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plai

n;q=0.8,image/png,*/*;q=0.5

Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300Connection: keep-alive

Referer: http://www.example.comCookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1

Content-Type: application/x-www-form-urlencoded

Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in

Тестувальник бачить наступну відповідь від сервера:

HTTP/1.1 200 OK

Date: Thu, 14 Aug 2008 14:52:58 GMT

Server: Apache/2.2.2 (Fedora)X-Powered-By: PHP/5.1.6Content-language: en

Cache-Control: private, must-revalidate, max-age=0

X-Content-Encoding: gzip

Content-length: 4090

Connection: close

Content-Type: text/html; charset=UTF-8

...

HTML data

...

Оскільки після успішної аутентифікації новий файл cookie не створювався, тестувальнику вже зрозуміло, що можна виконати захоплення сеансу. Тестувальник може надіслати користувачеві дійсний ідентифікатор сеансу (можливо, використовуючи прийом соціальної інженерії), дочекатися, поки він пройде аутентифікацію. Після цього файли cookie будуть призначені привілеї, відповідно до ролі користувача.

Інструменти

OWASP Zed Attack Proxy Project (ZAP) - имеет механизм анализа токена.

JHijack - a numeric session hijacking tool