3.7 Testing Session Timeout
Суть вразливості:
На цьому етапі тестувальники перевіряють, що програма автоматично виконує вихід користувача із системи, коли цей користувач не діє певний час. Гарантуючи, що неможливо «повторно використовувати» той самий сеанс і що жодні конфіденційні дані не зберігатимуться в кеші браузера.
Всі програми повинні реалізовувати тайм-аут простою або бездіяльності користувача. Цей тайм-аут визначає кількість часу, протягом якого сеанс залишається активним у разі відсутності активності з боку користувача, закриття та анулювання сеансу після певного періоду простою з моменту останнього HTTP-запиту, отриманого веб-програмою для даного ідентифікатора сеансу. Найкращий тайм-аут повинен бути балансом між безпекою (коротший тайм-аут) і зручністю використання (триваліший тайм-аут) і залежить від рівня чутливості даних, оброблюваних додатком. Наприклад, 60-хвилинний час виходу з публічного форуму може бути прийнятним, але такий довгий час був би занадто великим для домашнього банківського додатку (де максимальний тайм-аут Рекомендується 15 хвилин). У будь-якому випадку будь-яка програма, яка не забезпечує вихід із системи за тайм-аутом, повинна вважатися небезпечною.
Тайм-аут простою обмежує шанси того, що зловмисник може вгадати та використати дійсний ідентифікатор сеансу від іншого користувача. Однак, якщо зловмисник може захопити даний сеанс, час простою не обмежує дії зловмисника, оскільки він може генерувати активність у сеансі періодично, щоб сеанс залишався активним протягом тривалих періодів часу. Управління тайм-аутом та закінченням сеансу має бути примусове на стороні сервера. Якщо якісь дані під контролем клієнта використовуються для забезпечення тайм-ауту сеансу, наприклад, з використанням значень файлів cookie або інших параметрів клієнта для відстеження часу посилання (наприклад, кількість хвилин з моменту входу до системи), зловмисник може маніпулювати ними, щоб продовжити сеансу тривалість. Таким чином, програма повинна відстежувати час бездіяльності на стороні сервера, і після цього часу автоматично анулювати сеанс поточного користувача та видалити всі дані, що зберігаються на клієнті.
Обидві дії повинні виконуватися обережно, щоб уникнути появи слабких місць, які можуть бути використані зловмисником, який може отримати несанкціонований доступ, якщо користувач забув вийти з програми. Що стосується виходу з системи, важливо переконатися, що всі токени сеансу (наприклад, файли cookie) належним чином знищені або зроблені непридатними для використання, і що на стороні сервера застосовуються належні елементи керування, щоб запобігти повторному використанню токенів сеансу. Якщо таких дій немає належним чином виконаний, зловмисник може відтворити ці токени сеансу, щоб "воскресити" сеанс законного користувача і видавати себе за нього (ця атака зазвичай відома як "відтворення файлів cookie"). Звичайно, пом'якшуючим фактором є те, що зловмисник повинен мати доступ до цих токенів (які зберігаються на комп'ютері жертви), але в багатьох випадках це не може бути неможливим чи особливо важким. Найбільш поширений сценарій таких атак - це загальнодоступний комп'ютер, який використовується для доступу до приватної інформації. (Наприклад, електронна пошта, банківський рахунок в Інтернеті). Якщо користувач відходить від комп'ютера без явного виходу з системи та тайм-аут сеансу не реалізований у додатку, тоді зловмисник може отримати доступ до того ж облікового запису, просто натиснувши кнопку «назад» браузера.
Як протестувати
Той самий підхід, що й у розділі Testing for logout functionality. Методологія тестування дуже схожа. Спочатку тестувальники повинні перевірити, чи існує тайм-аут, наприклад, вхід у систему та очікування закінчення часу очікування виходу із системи. Як і у випадку з функцією виходу із системи, після закінчення тайм-ауту всі токени сеансу повинні бути знищені або повинні стати непридатними для використання.
Потім, якщо тайм-аут налаштований, тестувальникам необхідно зрозуміти, чи застосовується примусово тайм-аут на клієнті чи сервері (або на обох сторонах). Якщо файл cookie сеансу не є постійним, випробувачі можуть припустити, що тайм-аут примусово встановлений сервером. Якщо файл cookie сеансу містить час у зв'язаних даних (наприклад, час входу в систему, час останнього доступу або дата закінчення терміну дії постійного файлу cookie), можна припустити, що клієнт бере участь у забезпеченні тайм-ауту. У цьому випадку тестувальники можуть спробувати змінити файл cookie (якщо він не є криптографічно захищеним) і подивитися, що відбудеться з сеансом. Наприклад, тестувальники можуть встановити термін дії файлів cookie у майбутньому, потім подивитися, чи можна продовжити сеанс. Як правило, все має бути перевірено на стороні сервера, і це не повинно бути можливим шляхом переналаштування сеансу файли cookie на попередні значення, щоб знову отримати доступ до програми.
