Що таке викрадення сеансу та як його можна зупинити

Ця історія призначена для початківців та тих, хто має базові уявлення про файли cookie (сеансові файли cookie), але хто не знає, як їх правильно захистити. Для цього не обов’язково бути експертом з безпеки. Вам просто потрібно зрозуміти процес, і тоді ви дізнаєтесь.

Якщо у вас немає уявлення про файли cookie або як вони працюють, прочитайте цю статтю про файли cookie HTTP.

Давайте дійдемо до цього! У вас є дивовижний веб-додаток, що пропонує чудові послуги для клієнтів. Це означає, що у вас буде механізм автентифікації, щоб перевести користувача у вашу програму. Ви знаєте, наскільки важлива безпека. Ви застосували всілякі заходи безпеки під час автентифікації. Чудово!

Після успішної автентифікації потрібно створити сеанс для цього користувача. Це означає, що ви фактично створюєте файл cookie і надсилаєте його назад у браузер. Наприклад, у веб-програмі Java за замовчуванням вона називається JSESSIONID. Це виглядає приблизно так:

Використовуючи цей файл cookie, лише ваш веб-сервер може визначити, хто є користувачем, і він відповідно надаватиме вміст. І це печиво виглядає чудово. У файлі cookie немає конфіденційної інформації, лише випадковий ідентифікатор (не вгадується). Тож користувач у безпеці! ... так?

Ну не зовсім так, давайте розглянемо уважніше.

У цьому файлі cookie є дві властивості: HttpOnly (HTTP) та Secure. Їх значення порожні, тобто для цього файлу cookie не ввімкнено . Тут справа доходить до того, що це вже не безпечно.

Тут у справу входить викрадення сесії.

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

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

Чи можливо це? Як вони отримують той ідентифікатор сеансу, який є в браузері користувача?

Так, це можливо. Причиною цього є два властивості файлів cookie (або прапори), які ми бачили раніше ( HttpOnly та Secure ).

HttpТільки прапор

HttpOnlyфайли cookie недоступні для Document.cookieAPI JavaScript ; вони надсилаються лише на сервер. Наприклад, файли cookie, які зберігаються на серверних сеансах, не повинні бути доступними для JavaScript, а HttpOnlyпрапорець повинен бути встановлений.

Тож кажучи простими словами, якщо ви не встановите прапор httpOnly, ваш файл cookie буде читати з інтерфейсного коду JavaScript.

Відкрийте будь-яку веб-сторінку, у файлі cookie якої не встановлено прапор httpOnly. Потім відкрийте Chrome Dev Console, а потім торкніться вкладки Console (Cmd + Shift + J або Ctrl + Shift + J). Введіть document.cookieі введіть, і ви побачите щось подібне:

Як бачите, ви отримуєте всю інформацію про файли cookie. Зловмисник JavaScript може просто опублікувати це на своєму власному сервері для подальшого використання.

Вам може бути цікаво, як вони можуть написати цей код у вашій програмі. Це можливо кількома способами.

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

Інший спосіб - використання атаки сценаріїв між сайтами . Ми не збираємося вдаватися в подробиці цього, але пам’ятайте, що це можна зробити.

То як ми це можемо виправити?

Файл cookie сеансу навіть не повинен бути доступним для клієнта JavaScript. Це потрібно лише для сервера. Ми повинні зробити це доступним лише для сервера. Це можна зробити, додавши одне слово ( httpOnly ) у ваш заголовок відповіді http_set_cookie . Подобається це:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly

Додаючи прапор httpOnly , ви вказуєте браузеру, що цей файл cookie не повинен читатися кодом JavaScript. Про все подбає браузер. Ось як це виглядає після додавання прапора httpOnly:

Зверніть увагу на галочку у властивості HTTP. Це означає, що httpOnly увімкнено.

Тут ви бачите, що document.cookie не повертає наш сеансовий файл cookie. Це означає, що жоден JS не може його прочитати, включаючи будь-які зовнішні сценарії.

Ось і все - один вниз один!

Захищений прапор

Безпечний прапор вказує браузеру , що куки повинні бути повернуті тільки до додатка через шифровані з'єднання, тобто з'єднання HTTPS.

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

Як хтось може прочитати файл cookie в запиті HTTP?

Цього можна досягти, коли хтось (який називається атакою "Людина посередині" ) контролює весь трафік у мережі клієнтів. Вони можуть бачити чисті текстові дані, якщо запит знаходиться в HTTP.

Коли він надсилається через HTTPS , усі дані будуть зашифровані з браузера та відправлені в мережу. Зловмисник не зможе отримати вихідні дані, які ви надсилали. Також зловмисник не зможе розшифрувати вміст. Ось чому надсилання даних через SSL є безпечним.

То як ми це можемо виправити?

Так само, як прапор httpOnly, вам просто потрібно додати захищений прапор у ваш заголовок відповіді HTTP set_cookie . Подобається це:

Set-Cookie: JSESSIONID=T8zK7hcII6iNgA; Expires=Wed, 21 May 2018 07:28:00 GMT; HttpOnly; Secure

У Java це можна зробити кількома способами. Якщо ви використовуєте Servlet 3.0 або новішої версії, ви можете налаштувати ці параметри в web.xml таким чином:

  true true  

Якщо ваше середовище цього не підтримує, ви можете додати його вручну. Наприклад, використовуючи сервлети, ви можете зробити це:

Нарешті, так виглядає, коли встановлені обидва прапори,

Висновок

Отже, коли ви маєте справу з файлами cookie сеансу або будь-якими іншими важливими файлами cookie, обов’язково додайте ці два прапори.

Дякуємо за читання, щасливого захисту!