3.4 Testing for Exposed Session Variables

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

Токени сеансу (Cookie, SessionID, Hidden Field), якщо вони знаходяться в розкритому вигляді, ми дозволяємо зловмиснику уособлювати незаконний доступ до додатку. Важливо, щоб вони завжди були захищені від прослуховування, особливо під час передачі між клієнтським браузером і серверами програми.

При використанні персонального проксі, можна по кожному запиту і відповіді дізнатися наступне:

- Використання протоколу (HTTP vs. HTTPS)

- HTTP Headers

- Текст у тілі запиту ( POST or контент сторінки)

Щоразу, коли дані ідентифікатора сеансу передаються між клієнтом і сервером, їх варто вивчати, що саме передається в директивах протоколу, кешуванні й у тілі запиту.

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

Захист від підслуховування часто забезпечується шифруванням SSL-сертифікатом. Слід зазначити, що шифрування або криптографічне хешування ідентифікатора сеансу слід розглядати окремо від шифрування транспорту, оскільки захищається сам ідентифікатор сеансу, а не дані, які можуть бути представлені.

Якщо ідентифікатор сеансу може бути наданий зловмисником додатку для отримання доступу, він повинен бути захищений під час передачі, щоб знизити цей ризик. Тому слід переконатися, що шифрування використовується за умовчанням і застосовується для будь-якого запиту або відповіді, в якому передається ідентифікатор сеансу, незалежно від механізму (наприклад, приховане поле форми). Прості перевірки, наприклад, заміна https:// на http:// під час перевірок програми, щоб визначити, чи є редиректи на безпечний протокол.

Тестування проксі-серверів та вразливостей кешування

Проксі-сервери також необхідно враховувати під час перевірки безпеки програм. У багатьох випадках клієнти будуть звертатися до програми через корпоративні, ISP або інші проксі-сервери або шлюзи. Протокол HTTP забезпечує директиви для управління поведінкою нижче проксі, і правильна реалізація цих директив також повинна бути реалізована.

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

Для налаштування кешу можна юзати таку директиву Cache-Control: no-cache, в такому положенні налаштування вказує, що проксі-сервер не повинен повторно використовувати будь-які дані. Якщо така настройка Cache-Control: Private вказує, що відповідь призначена окремому користувачеві і не повинна зберігатися в кеші спільного використання. У цьому випадку відповідь може зберігатись приватним кешем браузера. У разі використання вашого сайту в веб-кафе або інших спільних комп'ютерних клубів, це є явним ризиком. Навіть на робочих машинах, кешований ідентифікатор сеансу може бути відкритий через компрометацію файлової системи або через використання мережевих сховищ. Слід зазначити, що кеші HTTP/1.0 не розпізнають дериктиву Cache-Control: no-cache.

Тестування вразливостей GET та POST

Як правило, запити GET не варто використовувати, оскільки ідентифікатор сеансу може відображатись у логах проксі чи брандмауері. Ними набагато легше маніпулювати, ніж іншими видами транспорту. Крім того, атаки з використанням міжсайтових сценаріїв (XSS) найлегше використовується шляхом відправки жертві спеціально створеного посилання. Це набагато менш ймовірно, якщо дані відправляються від клієнта за запитом POST.

Весь код на стороні сервера, який отримує дані із запитів POST, повинен бути протестований, щоб переконатися, що він не приймає дані, якщо цей же запит надіслати як GET. Наприклад, розглянемо наступний запит POST, створений сторінкою входу до системи.

POST http://owaspapp.com/login.asp HTTP/1.1

Host: owaspapp.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0

Accept: /Accept-Language: en-us, en

Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Keep-Alive: 300

Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG

Cache-Control: max-age=0

Content-Type: application/x-www-form-urlencodedContent-Length: 34

Login=Username&password=Password&SessionID=12345678

Якщо механізм логіна login.asp погано реалізований, можна спробувати перейти по наступному URL:

http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678

Який виконає GET запит, якщо нас пропустить під цим користувачем, значить у нас є проблеми.

Тестування транспортних уразливостей

Усі взаємодії між Клієнтом та Додатком мають бути перевірені як мінімум за такими критеріями.

- Як передаються ідентифікатори сеансу? наприклад, GET, POST, поле форми (включаючи приховані поля)

- Чи завжди ідентифікатори сеансу за промовчанням відправляються через зашифрований транспорт?

- Чи можна маніпулювати програмою для надсилання ідентифікаторів сеансів у незашифрованому вигляді? наприклад, змінивши HTTP на HTTPS?

- Які директиви керування кешем застосовуються до запитів/відповідей, які передають ідентифікатори сеансу?

- Чи завжди є ці директиви? Якщо ні, то де винятки?

- Чи використовуються запити GET, що включає ідентифікатор сеансу?

- Якщо використовується POST, чи можна замінити його на GET?