Забезпечення безпеки передачі даних HTTP

💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

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

Самим найпростішим є розширення HTTPS, при якому дані, передані по протоколу HTTP, «упаковуються» в криптографічний протокол SSL або TLS, тим самим забезпечуючи захист цих даних. На відміну від HTTP, для HTTPS за замовчуванням використовується TCP-порт 443. Щоб підготувати веб-сервер для обробки HTTPS з'єднань, адміністратор повинен отримати і встановити в систему сертифікат для цього веб-сервера.

SSL (Secure Sockets Layer) - криптографічний протокол, що забезпечує безпечну передачу даних по мережі Інтернет. При його використанні створюється захищене з'єднання між клієнтом і сервером. SSL спочатку розроблений компанією Netscape Communications. Згодом на підставі протоколу SSL 3.0 був розроблений і прийнятий стандарт RFC, що отримав назву TLS. Цей протокол використовує шифрування з відкритим ключем для підтвердження автентичності передавача і отримувача. Підтримує надійність передачі даних за рахунок використання коригувальних кодів і безпечних хеш-функцій. На нижньому рівні багаторівневого транспортного протоколу (наприклад, TCP) він є протоколом запису і використовується для інкапсуляції різних протоколів (POP3, IMAP, SMTP або HTTP). Для кожного инкапсулированного протоколу він забезпечує умови, при яких сервер і клієнт можуть підтверджувати один одному свою справжність, виконувати алгоритми шифрування і проводити обмін криптографічними ключами, перш ніж протокол прикладної програми почне передавати й одержувати дані.

Для доступу до веб-сторінок, захищеним протоколом SSL, в URL замість схеми http, як правило, підставляється схема https, яка вказує на те, що буде використовуватися SSL-з'єднання. Стандартний TCP-порт для з'єднання по протоколу https - 443. Для роботи SSL потрібно, щоб на сервері мався SSL-сертифікат.

В мережі Веб підтримуються 3 типи аутентифікації при клієнт-серверних взаємодіях:

- Basic - базова аутентифікація, при якій ім'я користувача та пароль передаються в заголовках http-пакетів. Пароль при цьому не шифрується і присутній в чистому вигляді в кодуванні base64. Для даного типу аутентифікації використання SSL є обов'язковим.

- Digest - дайджест-аутентифікація, при якій пароль користувача передається в хешировані вигляді. За рівнем конфіденційності паролів цей тип мало чим відрізняється від попереднього, так як атакуючому все одно, чи дійсно це справжній пароль або тільки хеш від нього: перехопивши посвідчення, він все одно отримує доступ до кінцевої точки. Для даного типу аутентифікації використання SSL є обов'язковим.

- Integrated - інтегрована аутентифікація, при якій клієнт і сервер обмінюються повідомленнями для з'ясування автентичності один одного за допомогою протоколів NTLM або Kerberos. Цей тип аутентифікації захищений від перехоплення посвідчень користувачів, тому для нього не потрібно протокол SSL. Тільки при використанні даного типу аутентифікації можна працювати за схемою http, у всіх інших випадках необхідно використовувати схему https.

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

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

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

Такі відомості дозволяє отримати додатковий засіб під назвою cookie. Механізм cookie дозволяє серверу зберігати інформацію на комп'ютері клієнта і витягувати її звідти.

Ініціатором записи cookie виступає сервер. Якщо у відповіді сервера присутній поле заголовка Set-cookie, клієнт сприймає це як команду на запис cookie. Надалі, якщо клієнт звертається до сервера, від якого він раніше прийняв поле заголовка Set-cookie, крім іншої інформації він передає серверу дані cookie. Для передачі зазначеної інформації серверу використовується поле заголовка Cookie.

Для того щоб в загальних рисах уявити собі, як відбувається обмін даними cookie, розглянемо наступний приклад. Припустимо, що клієнт передає запити на сервери А, В і С. Припустимо також, що сервер В, на відміну від А і С, передає клієнту команду записати cookie. Послідовність запитів клієнта серверу і відповідей на них буде виглядати приблизно так.

4. Отримання відповіді від сервера В. До складу відповіді входить поле заголовка SetCookie. Отримавши його, клієнт записує cookie на диск.

5. Передача запиту серверу С. Незважаючи на те що на диску зберігається запис cookie, клієнт не вживає ніяких спеціальних дій, оскільки значення cookie було записано з ініціативи іншого сервера.

7. Передача запиту серверу А. В цьому випадку клієнт також ніяк не реагує на той факт, що на диску зберігається cookie.

9. Передача запиту серверу В. Перед тим як сформувати запит, клієнт визначає, що на диску зберігається запис cookie, створена після отримання відповіді від сервера В. Клієнт перевіряє, чи задовольняє даний запит деяким вимогам, і, якщо перевірка дає позитивний результат, включає в заголовок запиту поле Cookie.

Таким чином, процедуру запису та отримання cookie можна уявити собі як своєрідний " запит" сервера, інкапсульованний в його відповіді клієнту. Відповідно отримання cookie також можна уявити собі як відповідь клієнта, інкапсульованний в складі запиту того ж серверу.

Розглянемо докладніше, які дані передаються в поле заголовка Set-cookie і як вони впливають на поведінку клієнта.

Set-cookie: ім'я = значення; expires = дата; path = шлях; домен = ім'я_домена, secure

- пара ім'я = значення - іменовані дані, які зберігаються за допомогою механізм cookie. Ці дані повинні зберігатися на клієнт-машині і передаватися серверу у складі чергового запиту клієнта;

- дата, яка є значенням параметра expires, визначає час, після закінчення якого інформація cookie втрачає свою актуальність. Якщо ключове слово expires відсутній, дані cookie видаляються після закінчення поточного сеансу роботи браузера;

- значення параметра domain визначає домен, з яким зв'язуються дані cookie. Щоб дізнатися, чи слід передавати у складі запиту дані cookie, браузер порівнює доменне ім'я сервера, до якого він збирається звернутися, з доменами, які пов'язані із записами cookie, що зберігаються на клієнт-машині. Результат перевірки буде вважатися позитивним, якщо сервер, якому направляється запит, належить домену, пов'язаному з cookie. Якщо відповідність не виявлено, дані cookie не передаються;

- шлях, вказаний як значення параметра path, дозволяє виконати подальшу перевірку і прийняти остаточне рішення про те, чи слід передавати дані cookie в складі запиту. Крім домена із записом cookie зв'язується шлях. Якщо браузер виявив відповідність імені домена значенню параметра domain, він перевіряє, чи відповідає шлях до ресурсу шляху, пов'язаному з cookie. Порівняння вважається успішним, якщо ресурс міститься в каталозі, вказаному за допомогою ключового слова path, або в одному з його підкаталогів. Якщо і ця перевірка дає позитивний результат, дані cookie передаються серверу. Якщо параметр path в поле Set-Cookie відсутній, то вважається, що запис cookie пов'язана з URL конкретного ресурсу, переданого сервером клієнтові;

- останній параметр, secure, вказує на те, що дані cookie повинні передаватися по захищеному каналу.

Для передачі даних cookie серверу використовується поле заголовка Cookie. Формат цього поля досить простий:

C допомогою поля Cookie передається одна або декілька пар ім'я = значення. Кожна з цих пар належить записи cookie, для якої URL запитуваного ресурсу відповідають імені домена і шляхи, зазначеним раніше в поле Set-cookie.

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