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) - имеет механизм анализа токена.
