URI ідентифікації сеансу

1. WD-session-id-960221 W3C Робочий проект WD-session-id-960221
2. Статус цього документа
3. Анотація
4. Вступ
5. Реклама як дохід для постачальників веб-вмісту.
6. Проблеми конфіденційності
7. Ідентифікатори псевдосеансу.
8. Відносини з інформацією про стан (Cookies)
9. Формат URI
10. Приклади
11. Обмежена зв'язок ідентифікаторів сеансів.
12. Запобігання атакам відтворення
13. Питання впровадження
14. Інтеграція HTTP
15. Ідентифікатор сеансу
16. Приклад
17. WWW-Authenticate
18. Приклад
19. Міркування безпеки
20. Ненавмисні зв'язки
21. Небезпечні технології будівництва.
22. Подальша робота
23. Взаємодія з проксі та кешами.
24. Подяка
25. Список літератури

WD-session-id-960221

W3C Робочий проект WD-session-id-960221

Ця версія: http://www.w3.org/pub/WWW/TR/WD-session-id-960221.html Остання версія: http://www.w3.org/pub/WWW/TR/WD-session-id.html Автори: Філіп М. Халлам-Бейкер <[email protected]>
Dan Connolly> <[email protected]>

Статус цього документа

Це робочий проект W3C для розгляду членами W3C та іншими зацікавленими сторонами. Він є проектом документа і може бути оновлений, замінений або застарілий іншими документами в будь-який час. Недоречно використовувати робочі проекти W3C як довідковий матеріал або цитувати їх як інші, ніж "незавершене виробництво". Список поточних робочих проектів W3C можна знайти за адресою: http://www.w3.org/pub/WWW/TR

Примітка. Оскільки робочі чернетки часто змінюються, рекомендується звернутися до вищезгаданої URL-адреси, а не до URL-адрес самих робочих чернеток.

Анотація

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

Вступ

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

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

Реклама як дохід для постачальників веб-вмісту.

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

Відмінною особливістю Мережі є її інтерактивний характер. Гілл [Gill96] вказує на те, що інтерактивна природа Мережі може зробити традиційні моделі "цільової" реклами застарілими, замінивши їх моделями участі. Веб - це інформаційна система, і користувачі, які бажають придбати товари, скоріше за все, зможуть скористатися нею, щоб дізнатися деталі. Це може бути непотрібним для цілеспрямованої реклами (наприклад, небажана електронна пошта). Оскільки користувачі звикають до більш активних способів реклами, інтрузивні методи можуть стати непродуктивними.

Існує багато показників, які рекламодавець може використовувати для оцінки вартості розміщення в Інтернеті. До них відносяться:

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

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

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

Проблеми конфіденційності

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

Інтернет має сильно розвинений, але дуже непередбачуваний етичний сенс. Це середовище активних учасників, а не пасивних споживачів. Користувачі можуть публічно скаржитися на наявні помилки (чи виправдані, чи ні) через Usenet, що має читацьку аудиторію в кілька мільйонів. Питання конфіденційності, зокрема, часто є проблемами. Отже, доцільно підходити до питання конфіденційності особи.

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

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

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

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

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

Транзакції в протоколі HTTP 1.0 не перетинаються. Здійснюється єдиний запит, який призводить до одиничної відповіді, після якої операція завершена, а з'єднання TCP / IP закрито. HTTP / 1.1 дозволяє використовувати одне і те ж з'єднання TCP / IP для виконання декількох операцій.

Ідентифікатори псевдосеансу.

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

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

Відносини з інформацією про стан (Cookies)

Державна інформація [Kristol95] є запропонованим розширенням протоколу HTTP. Це уточнення Пропозиція Netscape "Cookies" [Netscape95]. Цей механізм дозволяє серверу генерувати маркер, який клієнт, який повертається з майбутніми запитами. Цей механізм вимагає, щоб клієнти зберігали дані для кожного відвідуваного сервера і, отже, не використовувалися з механізмом відстеження, якщо кількість сайтів, які використовують його, невелика. У ідентифікаторі сеансу ідентифікатори пропозиції URI генеруються клієнтами, а не серверами. Це забезпечує масштабованість, оскільки клієнту потрібно зберігати лише фіксовану інформацію про ідентифікатор, незалежно від кількості відвідуваних сайтів.

Формат URI

Ідентифікатори сеансу мають форму:

SID: тип : область : ідентифікатор [ - потік] [ : кількість]

Де поля тип , область , ідентифікатор . потік і лічильник визначаються наступним чином:

type Тип ідентифікатора сеансу. Це поле дозволяє визначити інші типи ідентифікаторів сеансу. Цей проект вказує ідентифікатор типу "ANON". realm Визначає область, в якій можлива зв'язок ідентифікатора. Області мають такий самий формат, як імена DNS. ідентифікатор Неструктурований випадковий ціле число, специфічне для області, створеної за допомогою процедури з незначною ймовірністю зіткнення. Ідентифікатор кодується з використанням бази 64. потік Необов'язкове розширення поля ідентифікатора, що використовується для диференціації одночасних використання одного ідентифікатора сеансу. Поле потоку є цілим числом, закодованим у шістнадцятковому форматі. count Необов'язковий Шістнадцяткове закодоване ціле число, що містить монотонно зростаюче значення лічильника. Клієнт повинен збільшити поле рахунку після кожної операції.

Приклади

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

SID: ANON: www.w3.org: j6oAOxCWZh / CD723LGeXlf-01: 34 SID: ANON: mc.ai.mit.edu: NRviSpoYm7mdkYB4W2471l-01: 35 SID: ANON: www.w3.org: j6oAOxCWZh / CD723LGeXlf-01: 36 SID: ANON: mc.ai.mit.edu: NRviSpoYm7mdkYB4W2471l-01: 37 SID: ANON: www.w3.org: j6oAOxCWZh / CD723LGeXlf-02: 01 SID: ANON: www.w3.org: j6oAOxCWZh / CD723LGeXlf-01 : 38

Обмежена зв'язок ідентифікаторів сеансів.

URI ідентифікатора сеансу дозволяють зв'язувати транзакції в межах однієї області . Область може вважатися наближеною до імені DNS. Імена DNS досить добре співвідносяться з адміністративними поділами. Це дозволяє контент-провайдеру відстежувати дії в межах сайтів у їхній мережі, але не дозволяє заздалегідь узгоджувати дані з різних сайтів без спеціальної авторизації користувача.

Запобігання атакам відтворення

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

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

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

Питання впровадження

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

Зручний спосіб побудови ідентифікаторів сеансів, які не вимагають окремого зберігання для кожного відвіданого поля, полягає у використанні коду автентифікації повідомлення (MAC), заснованого на криптографічно безпечної функції, наприклад, MD5 [Rivest92].

При ініціалізації клієнт отримує ключ значення. Це значення слід вибирати випадковим чином, щоб забезпечити принаймні 128 біт ергодичності. Коли область відвідана, значення поля ідентифікатора створюється за допомогою формули

ідентифікатор = MD5 (область + ключ) .

Клієнт повинен зберігати значення ключа і значення лічильника, пов'язані з кожним потоком.

Інтеграція HTTP

Ідентифікатори сеансів можуть бути включені в HTTP-повідомлення за допомогою заголовка Session-Id. Існуючий заголовок WWW-Authenticate розширюється, щоб дозволити використання ідентифікаторів сеансів як легкого механізму аутентифікації.

Ідентифікатор сеансу

Ідентифікатор сеансу: URI

Заголовок Session-Id може бути включений до HTTP-запиту або відповіді. Заголовок приймає один параметр, ідентифікатор URI.

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

Приклад

Наступний приклад показує HTTP-запит, що містить ідентифікатор сеансу.

GET / HTTP / 1.0 Прийняти: text / plain Прийняти: text / html Ідентифікатор сеансу: SID: ANON: w3.org: j6oAOxCWZh / CD723LGeXlf-01: 034 Агент користувача: libwww / 4.1

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

WWW-Authenticate

WWW-Authenticate: 1 # виклик

Заголовок WWW-Authenticate використовується сервером для запиту, щоб клієнт надав ідентифікатор сеансу, де не було надано жодного, або щоб вказати його для альтернативної області. Цей механізм дозволяє зв'язувати ідентифікатори між областями, але тільки під контролем користувача.

Приклад

Наступні дані показують сервер, який запитує ідентифікатор для області "w3.org".

HTTP / 1.1 401 Несанкціонований WWW-Authenticate: Session, realm = w3.org Сервер: libwww / 4.1

Клієнти не повинні автоматично відповідати на виклик WWW-Authenticate без вказівки користувача.

Клієнт може запропонувати користувачеві об'єкт, за допомогою якого запити ідентифікаторів сеансу в альтернативних назвах автоматично приймаються за умови, що вони сумісні. Сфери можуть вважатися сумісними, якщо вони є нетривіальним префіксом імені сервера DNS. Наприклад, запит на сервер www.w3.org для ідентифікатора сеансу в області w3.org буде вважатися сумісним, але запит на w3.com, mit.edu або org не буде. Імена DNS у доменів верхнього рівня com, edu, gov, mil та org зазвичай можна вважати нетривіальними префіксами (виключення мережі з цього списку є навмисним. Інші домени DNS можуть вважатися нетривіальними префіксами, якщо вони нижче другого рівня ієрархію DNS.

Міркування безпеки

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

Ненавмисні зв'язки

Згода між сайтами може дозволити зв'язувати ідентифікатори сеансів між сферами. Сервер може дозволити зв'язок між ідентифікаторами в межах своєї області, а інший - шляхом включення компонента ідентифікатора до URI. Сервер www.w3.org отримує ідентифікатор сеансу SID: ANON: www.w3.org: j6oAOxCWZh / CD723LGeXlf-01: 34 може побудувати ідентифікатор http://ai.mit.edu/link/j6oAOxCWZh/CD723LGeXlf. Якщо посилання було виконано, сервер ai.mit.edu зможе відстежувати діяльність користувача в обох областях.

Небезпечні технології будівництва.

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

Подальша робота

Агенти даних про утиліти.

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

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

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

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

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

Взаємодія з проксі та кешами.

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

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

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

Подяка

Дейв Раггетт зробив оригінальну пропозицію використовувати анонімний ідентифікатор сеансу для захоплення демографічних даних. Рохіт Харе і Ден Коннолі допомагали уточнити багато ідей. Роджер Гурвіц і Джон Маллери зробили багато корисних коментарів про ранні версії цього проекту.

Список літератури

[Netscape95] Корпорація Netscape Communications Файли cookie з постійним станом клієнта [Hallam96] Філіп М. Халлам-Бейкер Розширений формат файлу журналу [Kristol95] Kristol, D. Запропонований механізм HTTP-інформації про стан [Коннолі96] Ден Коннолі Пропозиції щодо збору споживчої демографії [Hallam93] Філіп М. Халлам-Бейкер Дизайнерська довідка про HTTP-реферерне поле. Пам'ятка Тіму Бернерсу-Лі. [Smith96] Ніл Сміт, адреса в MIT Семінар з методології Інтернет-опитування та веб-демографії 29-30 січня 1996 року. [Rivest92] Rivest, R., "Алгоритм обміну повідомленнями MD4" , RFC 1321, MIT і RSA Data Security, Inc., квітень 1992 р. [Berners-Lee96] Тім Бернерс-Лі, Рой Т. Філдінг і Хенрік Фрістік Нільсен. Протокол передачі гіпертексту - HTTP / 1.0 [Gill96] Ніл Сміт, адреса в MIT Семінар з методології Інтернет-опитування та веб-демографії 29-30 січня 1996 року. [RFC1034] P. Mockapetris. Система доменних імен . (RFC1034, RFC1035) Листопад 1987 [Hallam-Baker94] Філіп М. Халам-Бейкер Шен Безпечне середовище гіпертексту, примітки до дизайну. Група технологій програмування CERN.