HTTP cookie

Кукі (слово не відмінюється; від англ. cookie - Печиво) - невеликий фрагмент даних, відправлений веб-сервером і зберігається на комп'ютері користувача, який веб-клієнт (звичайно веб-браузер) кожного разу пересилає веб-серверу в HTTP-запиті при спробі відкрити сторінку відповідного сайту. Застосовується для збереження даних на стороні користувача, на практиці зазвичай використовується для:

  • аутентифікації користувача;
  • зберігання персональних переваг і налаштувань користувача;
  • відстеження стану сесії доступу користувача;
  • ведення статистики про користувачах.

Прийом куки оглядачами (браузерами) вимагають багато сайтів з обмеженнями доступу, більшість інтернет-магазинів. [1] Настройка оформлення та поведінки багатьох веб-сайтів по індивідуальних переваг користувача теж заснована на куки. [2]

З моменту своєї появи куки викликали стурбованість користувачів Інтернету, оскільки стеження за діями і перевагами користувачів може піддати небезпеці таємницю особистого життя. Як результат, в Європейському союзі, Сполучених Штатах, і в інших країнах були прийняті відповідні закони, що регулюють застосування куки . Куки легко перехопити і підмінити (наприклад, для отримання доступу до облікового запису), якщо користувач використовує нешифровані з'єднання з сервером. У групі ризику користувачі, що виходять в інтернет за допомогою публічних точок доступу Wi-Fi і не використовують при цьому таких механізмів як SSL. Шифрування дозволяє також вирішити й інші проблеми, пов'язані з безпекою переданих даних.

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

Більшість сучасних браузерів дозволяють користувачам вибрати - приймати куки чи ні, але їх відключення робить неможливою роботу з деякими сайтами. Крім того, необхідність частого введення логіна і пароля робить роботу з сайтами менш зручною.


1. Призначення

Куки використовуються веб-серверами для розрізнення користувачів і зберігання даних про них.

До прикладу, якщо вхід на сайт здійснюється за допомогою куки, то після введення користувачем своїх даних на сторінці входу, куки дозволяють серверу запам'ятати, що користувач вже ідентифікований, і йому дозволено доступ до відповідних послуг та операцій. [2]

Багато сайтів також використовують куки для збереження налаштувань користувача. Ці установки можуть використовуватися для персоналізації, яка включає в себе вибір оформлення і функціональності. Наприклад, Вікіпедія дозволяє авторизованим користувачам вибрати дизайн сайту. Пошукова система Google дозволяє користувачам (у тому числі і не зареєстрованим в ній) вибрати кількість результатів пошуку, що відображаються на одній сторінці. [3]

Куки також використовуються для відстежування дій користувачів на сайті. Як правило, це робиться з метою збору статистики, а рекламні компанії на основі такої статистики формують анонімні профілі користувачів, для більш точного націлювання реклами. [4]


2. Поняття

Можлива взаємодія між браузером і сервером.

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

Специфікації [5] [6] вказують мінімальні обсяги, які повинні надаватися браузерами для зберігання куки. Так, браузер повинен зберігати щонайменше 300 куки по 4096 байт кожна, і щонайменше 20 куки для одного сервера або домену.

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

На практиці, деякі браузери можуть накладати більш жорсткі обмеження. Наприклад, Internet Explorer надає 4096 байт для всіх куки в одному домені.

Імена куки нечутливі до регістра відповідно до розділу 3.1 RFC 2965.

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

Зберігання куки також може обмежуватися в залежності від веб-сервера, домену або піддомену, де вони були створені.


3. Історія

За однією з версій термін "кукі" (печиво) походить від " чарівного печива " [7] - набору даних, які програма отримує і потім відправляє назад незмінними. У червні 1994 року Лу Монтуллі прийшла ідея використовувати їх при веб-з'єднанні. [8] У той час він був співробітником Netscape Communications, яка розробляла за замовленням пакет електронної комерції. Куки стали вирішенням проблеми надійної реалізації віртуальної корзини покупок.

За допомогою Джона Гіаннандреа в той же рік Монтуллі написав початкову специфікацію куки. Mosaic Netscape 0.9beta, випущена 13 жовтня 1994, [9] [10] вже підтримувала куки. Куки вперше почали використовуватися поза лабораторією на сайті Netscape і визначали, чи відвідував користувач сайт раніше. Монтуллі подав заявку на патент в 1995 році і отримав його в 1998 році. Internet Explorer почав підтримувати куки з версії 2, випущеної в жовтні 1995. [11]

Хоча деякі люди знали про існування куки вже в першому кварталі 1995 року, [12] широка громадськість дізналася про них лише після статті в " Financial Times "від 12 лютого 1996. У тому ж році куки опинилися в центрі уваги засобів масової інформації, особливо через потенційної загрози приватності. Куки були розглянуті в Федеральної комісії з торгівлі США у двох слуханнях в 1996 і 1997 роках.

Розвиток специфікацій куки на цьому не зупинилося. Зокрема, перші обговорення формальної специфікації почалися у квітні 1995 року. Була сформована спеціальна робоча група в рамках IETF. У якості відправної точки була обрана специфікація Netscape. У лютому 1996 року робоча група визначила сторонні куки як серйозну загрозу приватності. Вироблена специфікація була випущена під назвою RFC 2109 у лютому 1997. У ньому вказувалося, що сторонні куки повинні або блокуватися, або хоча б не працювати за замовчуванням.

У той час рекламні компанії вже щосили використовували сторонні куки і рекомендації RFC 2109 не підтримувалися ні в браузерах Netscape, ні в Internet Explorer. Пізніше, в жовтні 2000, RFC 2109 була замінена новою специфікацією RFC 2965.


4. Омани

З моменту появи куки, в ЗМІ та Інтернеті почали поширюватися різні чутки. [13] У 1998 комп'ютерний відділ Міністерства енергетики Сполучених Штатів (CIAC) заявив, що небезпеки куки не представляють, і пояснив, що "інформація про те, звідки ви приходите і які веб-сторінки відвідуєте, і так зберігається в лог-файли веб-серверів ". [14] У 2005 були опубліковані результати дослідження, [15] згідно з яким значний відсоток респондентів упевнений, що:

У дійсності ж, куки являють собою лише дані, а не програмний код: вони не можуть стерти або прочитати інформацію з комп'ютера користувача. [16] Однак куки дозволяють простежити, які веб-сторінки переглянуті користувачем на даному сайті, і ця інформація може бути збережена в профілі користувача. Такі профілі найчастіше анонімні і не містять особистої інформації користувачів (ім'я, адреса і т. д.). Точніше, вони не можуть її утримувати, поки користувач не зробив цю інформацію доступною. Але навіть незважаючи на анонімність, ці профілі стали предметом суперечок про збереження приватності.


5. Робота куки

5.1. Установка куки

Запитуючи сторінку, браузер відправляє веб-серверу короткий текст з HTTP-запитом. Наприклад, для доступу до сторінки http://www.example.org/index.html, браузер відправляє на сервер www.example.org наступний запит:

GET / index.html HTTP/1.1
Host: www.example.org

браузер
сервер

Сервер відповідає, відправляючи запитувану сторінку разом з текстом, що містить HTTP-відповідь. Там може міститися вказівка ​​браузеру зберегти куки:

HTTP/1.1 200 OK
Content-type: text / html
Set-Cookie: name = value

(Вміст сторінки)

браузер
сервер

Рядок Set-cookie відправляється лише тоді, коли сервер бажає, щоб браузер зберіг куки. У цьому випадку, якщо кукі підтримуються браузером і їх прийом включений, браузер запам'ятовує рядок name=value (ім'я = значення) і відправляє її назад сервера з кожним наступним запитом. Наприклад, при запиті наступної сторінки http://www.example.org/spec.html браузер пошле сервера www.example.org наступний запит:

GET / spec.html HTTP/1.1
Host: www.example.org
Cookie: name = value
Accept: * / *

браузер
сервер

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

Значення куки може бути змінено сервером шляхом відправлення нових рядків Set-Cookie: name=newvalue. Після цього браузер замінює старе куки з тим же name на новий рядок.

Рядок Set-Cookie, як правило, додається до HTTP-відповіді не самим HTTP-сервером, а CGI -програмою, що працює разом з ним. HTTP-сервер тільки відправляє браузеру результат роботи такої програми.

Куки також можуть встановлюватися програмами на мовах типу JavaScript, вбудованими в текст сторінок, або аналогічними скриптами, працюючими в браузері. В JavaScript для цього використовується об'єкт document.cookie. Наприклад, document.cookie = "temperature=20" створить куки під ім'ям "temperature" і значенням 20. [17]


5.2. Атрибути куки

Крім пари ім'я / значення, куки може містити строк дії, шлях і доменне ім'я. RFC 2965 також передбачає, що куки повинні обов'язково мати номер версії, але це використовується рідко. Ці атрибути повинні йти після пари name=newvalue і розділятися крапкою з комою. Наприклад:

Set-Cookie: name=newvalue; expires=date; path=/; domain=.example.org.

Зразок HTTP-відповіді google.com, що містить куки з атрибутами.

Домен і шлях говорять браузеру, що куки повинна бути відправлена ​​назад на сервер при запитах URL для вказаного домену та шляхи. Якщо вони не вказані, використовуються домен і шлях запитаної сторінки [6].

Фактично, куки визначаються трійкою параметрів ім'я-домен-шлях (оригінальна специфікація Netscape враховувала лише пару ім'я-шлях [5]). Іншими словами, куки з різними шляхами або доменами є різними куки, навіть якщо мають однакові імена. Відповідно, куки змінюється на нове, тільки якщо нове куки має ті ж ім'я, шлях і домен.

Дата закінчення вказує браузеру, коли видалити куки. Якщо термін закінчення не зазначений, куки видаляється після закінчення користувальницького сеансу, тобто із закриттям браузера. Якщо ж вказана дата закінчення терміну зберігання, куки стає постійною до вказаної дати. Дата закінчення вказується у форматі "Нер, ДД Мес РРРР ГГ: ММ: СС GMT". Наприклад:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31 Dec 2010 23:59:59 GMT; path=/; domain=.example.net

куки з прикладу вище має ім'я RMID і значення "732423sdfs73242". Термін його зберігання закінчиться 31 грудня 2010 в 23:59:59. Шлях "/" і домен "example.net" показують браузеру, що потрібно відправити куки при перегляді будь-якої сторінки в домені example.net [18].


5.3. Умови закінчення терміну зберігання

Термін зберігання куки минає в наступних випадках: [19]

  1. В кінці сесії (наприклад, коли браузер закривається), якщо кукі не є постійними.
  2. Дата закінчення була вказана і термін зберігання вийшов.
  3. Браузер видалив куки за запитом користувача.

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

5.4. Аутентифікація

Куки можуть використовуватися сервером для впізнання раніше автентифікувати користувачів. Це відбувається наступним чином: [20]

  1. Користувач вводить ім'я користувача і пароль у текстових полях сторінки входу і відправляє їх на сервер.
  2. Сервер отримує ім'я користувача і пароль, перевіряє їх і, при їх правильності, відправляє сторінку успішного входу, прикріпивши куки з якимсь ідентифікатором сесії. Ця куки може бути дійсна тільки для поточної сесії браузера, але може бути налаштована і на тривале зберігання.
  3. Кожного разу, коли користувач запитує сторінку з сервера, браузер автоматично відправляє куки з ідентифікатором сесії сервера. Сервер перевіряє ідентифікатор по своїй базі ідентифікаторів і, за наявності в базі такого ідентифікатора, "дізнається" користувача.

Цей метод широко використовується на багатьох сайтах, наприклад на Yahoo!, в Вікіпедії і в Facebook.

Багато браузерів (зокрема Opera, FireFox), шляхом редагування властивостей куки, можуть управляти поведінкою веб-сайтів. Змінивши термін закінчення непостійних (сесійних) куки можна, наприклад, отримати формально-необмежену сесію після авторизації на якомусь сайті. Можливість редагування куки стандартними засобами відсутня в Internet Explorer. Але, скориставшись іншими механізмами, наприклад, JavaScript, користувач може змінити куки-файл. Більш того, існує можливість замінити сесійні куки постійними (із зазначенням терміну придатності).

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


6. Налаштування браузера

Перегляд і настроювання куки в браузері Firefox 3.0

Більшість сучасних браузерів підтримують куки. [21] І, як правило, користувач може вибрати, повинні куки використовуватися чи ні. Найбільш поширені наступні настройки браузерів: [18]

  1. Повне відключення куки.
  2. Видалення куки при закритті браузера.
  3. Розрізнення сторонніх куки з третьої сторони і відповідне поводження з ними (наприклад, обмеження або заборона для них).
  4. Обробка куки на основі "білого" і / або "чорного" списків, оновлюваних користувачем або виготовлювачем браузера. Куки з "чорного списку" блокуються.
  5. Заборона куки від певних доменів (різновид "чорного списку").
  6. Установка розумних строків закінчення куки.

Більшість браузерів, що підтримують JavaScript, дозволяють користувачеві побачити активні на даному сайті куки, набравши javascript:alert("Cookies: "+document.cookie) або javascript:prompt("Cookies:",document.cookie) в адресному рядку браузера [18]. Деякі браузери містять менеджер кукі, що дозволяє користувачеві вибірково переглянути і видалити кукі, що зберігаються в браузері.


7. Конфіденційність та сторонні куки

Куки значним чином впливають на конфіденційність та анонімність користувачів Інтернету. Хоча куки відправляються тільки на сервери домену, для якого вони призначені, веб-сторінка може довантажувати зображення або інші компоненти з інших доменів. Куки, одержувані під час підвантаження цих компонентів з інших доменів, називаються "сторонніми" [22].

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

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

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

Уряд Сполучених Штатів прийняло строгі закони стосовно куки в 2000 році, після того, як з'ясувалося, що Агентство по боротьбі з наркотиками США використовувало куки для відстеження користувачів, що проглянули їх антинаркотичну рекламу в мережі. У 2002 році Деніел Брандт встановив, що ЦРУ встановлює на комп'ютери постійні куки з терміном зберігання до 2010 року. Коли ЦРУ було сповіщено про неправомірність подібного використання куки, управління заявило, що це було ненавмисно і припинило їх установку. [23] 25 грудня 2005 Брандт виявив, що Агентство національної безпеки залишало пару постійних куки після оновлення програмного забезпечення. Після цього повідомлення Агентство негайно відключило куки. [24]

Директива Євросоюзу про конфіденційність електронних даних від 2002 року [25] містить норми, що стосуються використання куки. Зокрема, пункт 3 статті 5 встановлює, що зберігання даних (в тому числі куки) може здійснюватися лише якщо:

  1. користувачеві надається інформація про те, як ці дані використовуються;
  2. користувач має можливість відмовитися від цього.

Тим не менш, в даній статті також йдеться, що зберігання технічно необхідних даних звільняється від цих норм. Очікувалося, що директива набуде чинності з жовтня 2003, але доповідь від грудня 2004 зазначає, що ці положення не знайшли застосування на практиці і що в деяких державах ( Словаччина, Латвія, Греція, Бельгія і Люксембург) ці положення не внесені в національні законодавства. Доповідь пропонує провести ретельний аналіз ситуації в державах, що беруть участь в договорі.

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

Багато веб-браузери, включаючи Safari від Apple і Internet Explorer версій 6 і 7 від Microsoft, підтримують специфікації P3P, які дозволяють визначити, чи слід дозволяти сторонні куки. Веб-браузер Opera дозволяє користувачам відмовитися від сторонніх куки і створити глобальні або вибіркові профілі безпеки для веб-доменів. [26] Firefox 2 був позбавлений цієї опції, але вона була відновлена ​​в версії 3.


8. Недоліки куки

Крім проблем конфіденційності, куки мають і деякі технічні недоліки. Зокрема, вони не завжди точно ідентифікують користувача і можуть бути причиною атак зловмисників.

8.1. Неточна ідентифікація

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

Аналогічно, куки не розрізняють користувачів, що користуються одним комп'ютером і браузером, якщо не використовуються різні облікові записи в операційній системі.


8.2. Крадіжка куки

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

Куки можуть бути вкрадені іншим комп'ютером, читаючою трафік мережі.

Куки можуть бути вкрадені за допомогою аналізу трафіку - це називається зломом сесії. Мережевий трафік може бути перехоплений і прочитаний не тільки його відправником і одержувачем (особливо в публічних мережах Wi-Fi). Цей трафік включає в себе і куки, передані через незашифровані HTTP-сесії. Там, де мережевий трафік не шифрується, зловмисники можуть прочитати повідомлення користувачів мережі, в тому числі їх куки, використовуючи програми, звані сніфер.

Ця проблема може бути вирішена шляхом встановлення між користувачем і сервером шифрованого з'єднання з використанням протоколу HTTPS. Сервер також може використовувати спеціальний прапор при установці кукі, після чого браузер буде передавати їх тільки по надійному каналу, наприклад, через SSL -з'єднання. [6]

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

Міжсайтовий скриптінг: куки повинні обмінюватися лише між сервером і клієнтом, а відправляються третій стороні.

Для того щоб гарантувати передачу куки тільки через HTTPS-сесію, куки повинні мати атрибут Secure.

Інший спосіб крадіжки куки - міжсайтовий скриптінг і несанкціонована відправка куки на сервери, які не повинні отримувати їх. Сучасні браузери можуть виконувати фрагменти коду, отримані з сервера. Якщо кукі доступні під час цього виконання, їх вміст може в тій чи іншій формі опинитися на серверах, які не повинні отримувати до них доступ. Шифрування куки не допоможе в цьому випадку. [28]

Наступний вид міжсайтового скриптингу, як правило, використовують на сайтах, де користувачам дозволено відправляти повідомлення з HTML-вмістом. При вставці відповідного PHP / Javascript-коду в повідомлення атакуючий може отримати куки інших користувачів.

Ці атаки можна запобігти установкою прапора HttpOnly, [29] що робить куки недоступними для скриптів з боку клієнта. Тим не менш, веб-розробники повинні передбачати захист від міжсайтового скриптинга на стадії розробки веб-сайтів. [30]


8.3. Підміна куки

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

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

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


8.4. Міжсайтовий куки

Атакуючий використовує баг браузера для відправки сервера підроблених куки.

Кожен сайт повинен мати свої власні кукі, і сайт example.com не повинен змінювати або встановлювати куки іншого сайту example.org. Уразливості веб-браузерів дозволяють шкідливим сайтам порушувати це правило. Це схоже на відправлення куки, але тут зловмисник атакує користувачів з уразливими браузерами, а не сайт безпосередньо. Метою таких атак можуть бути ідентифікатори сесій.

Для захисту користувачам рекомендується використовувати останні версії браузерів, в яких ця проблема виправлена.


8.5. Нестабільність між клієнтом і сервером

Куки можуть викликати протиріччя між клієнтом і сервером. Якщо користувач отримує куки, а потім натискає кнопку "Назад" у браузері, то стан браузера вже інше у порівнянні з моментом отримання куки. Для прикладу візьмемо електронний магазин з кошиком покупок, заснованої на застосуванні куки: користувач додає покупку в корзину, потім натискає кнопку "Назад", але покупка залишається в кошику, хоча користувач, можливо, хотів скасувати покупку. Це може призвести до плутанини і помилок. Веб-розробники повинні пам'ятати про це і вживати заходів для вирішення таких ситуацій.


8.6. Термін дії куки

Постійні куки критикуються експертами за свій довгий термін зберігання, який дозволяє веб-сайтам відстежувати користувачів і створювати їх профіль з плином часу. [31] Тут зачіпаються і питання безпеки, оскільки вкрадені постійні куки можуть використовуватися протягом значного періоду часу.

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


9. Альтернативи куки

Деякі операції, для яких використовуються куки, можуть бути реалізовані за допомогою інших механізмів. Тим не менше, ці альтернативи мають свої недоліки, які роблять куки деколи більш кращими на практиці. Більшість цих альтернатив дозволяє відстежувати користувача, хоча і менш надійним способом, ніж куки. Як результат, недоторканність приватного життя залишається під загрозою, навіть якщо кукі відключені браузером або не встановлюються сервером.

9.1. IP-адресу

Цей ненадійний метод відстеження користувачів заснований на зберіганні IP-адрес комп'ютерів, що переглядають сторінки. Дана техніка доступна з самої появи World Wide Web, яка вимагає знання IP-адреси клієнта для завантаження сторінки. Цю інформацію можна зберігати на сервері поза залежністю від того, використовуються куки чи ні.

Тим не менше цей спосіб менш надійний, ніж куки, оскільки комп'ютери і проксі можуть спільно використовуватися декількома користувачами, а один комп'ютер може використовувати різні IP-адреси в різних сесіях (найчастіше це відноситься до комутованого з'єднання, т. зв. dial-up).

Відстеження по IP-адресою може виявитися неможливим і при використанні систем збереження анонімності (наприклад, Tor). У таких системах один браузер може мати кілька IP-адрес, і кілька користувачів можуть використовувати один IP-адресу, в результаті чого відстеження IP-адреси не представляється можливим.

Деякі великі провайдери, включаючи AOL, пропускають весь веб-трафік через мережу проксі [Джерело не вказано 846 днів] , Що також робить цей метод нездійсненним.


9.2. URL (рядок запиту)

Більш прогресивна методика заснована на вбудовуванні даних в URL. Зазвичай для цього використовується рядок запиту, але так само можуть задіятися та інші частини URL. Мови Java і PHP активно використовують ці механізми при відключених куки.

Веб-сервер додає рядок запиту до посиланням на веб-сторінку при її відправленні в браузері. Коли користувач переходить за посиланням, браузер повертає рядок запиту серверу.

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

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

Інший недолік рядка запиту проявляється в питаннях безпеки: зберігання ідентифікатора сесії в рядку запиту спрощує проведення атаки. Передача ідентифікатора в куки більш безпечна.


9.3. Приховані поля форми

Одним із способів відстеження сесії за допомогою виконуваної на стороні сервера програми є використання веб-форм з прихованими полями. Цей метод дуже схожий на рядок запиту URL і володіє майже тими ж перевагами та недоліками, а якщо параметри форми відправляються HTTP-методом GET, то поля фактично стануть частиною URL, який браузер відправить на сервер. Але більшість форм обробляється HTTP POST, при якій інформація не є ні частиною URL, ні куки.

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


9.4. HTTP-аутентифікація

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


9.5. Збереження на клієнтській стороні

Деякі веб-браузери дозволяють сторінці зберігати інформацію локально для подальшого вилучення. Internet Explorer, наприклад, підтримує збереження інформації в історії, обраному, XML -сховище, або дозволяє провести пряме збереження веб-сторінки на диск. [32]

Трохи відмінний механізм використовуються в браузерах, кешують файли javascript, використовувані в веб-сторінці. Наприклад, сторінка може містити посилання