Use of HTTP State Management
RFC 2964 (BCP 44) определяет рекомендуемые и недопустимые способы применения механизма управления состоянием HTTP, описанного в RFC 2965 и его предшественнике RFC 2109. Он допускает сохранение состояния между пользователем и сервисом при информированности и согласии пользователя, возможности удалить состояние, запрете раскрывать сведения третьим лицам без явного согласия, а также при условии, что состояние не содержит чувствительных данных и не может использоваться для получения чувствительных данных, иначе недоступных перехватчику. Документ запрещает (MUST NOT) использовать механизм для раскрытия третьим лицам сведений о пользователе или его просмотре без явного согласия. Он не рекомендует (SHOULD NOT) применять его как механизм аутентификации для защиты данных от неавторизованных сторон; аутентифицировать им запросы с нежелательными последствиями также не следует (SHOULD NOT), кроме случая, когда пользователь осведомлён о таких последствиях и явно согласен на такое применение.
Network Working Group K. Moore
Request for Comments: 2964 University of Tennessee
BCP: 44 N. Freed
Категория: Лучшая современная практика Innosoft
Октябрь 2000
Использование управления состоянием HTTP
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2000). Все права защищены.
Примечание IESG
IESG отмечает, что этот механизм внутренне использует домен верхнего
уровня (TLD) .local при обработке имён хостов, не содержащих точек, и
что этот механизм может работать не ожидаемым образом, если когда-либо
будет зарегистрирован фактический TLD .local.
Аннотация
Механизмы, описанные в «HTTP State Management Mechanism» (RFC-
2965), и его предшественнике (RFC-2109), могут использоваться для
множества различных целей. Однако некоторые текущие и потенциальные
применения протокола вызывают споры, поскольку они имеют существенные
последствия для приватности и безопасности пользователей. Этот
меморандум определяет конкретные применения протокола управления
состоянием Hypertext Transfer Protocol (HTTP), которые либо (a) не
рекомендуются IETF, либо (b) считаются вредоносными и не поощряются.
Этот меморандум также подробно рассматривает дополнительные аспекты
приватности, которые не охватываются спецификацией протокола управления
состоянием HTTP.
1. Введение
Механизм управления состоянием HTTP одновременно полезен и вызывает
споры. Он полезен, поскольку многочисленные приложения HTTP выигрывают
от возможности сохранять состояние между транзакциями HTTP, не кодируя
такое состояние в URL. Он вызывает споры, поскольку этот механизм
использовался для достижения целей, для которых не был разработан и к
которым плохо приспособлен. Некоторые из этих применений привлекли
значительную общественную критику, поскольку угрожают нарушить
приватность веб-пользователей, в частности путём раскрытия потенциально
конфиденциальной информации третьим сторонам, таким как веб-сайты,
которые пользователь посещал. Существуют также иные применения
управления состоянием HTTP, которые неуместны, хотя и не угрожают
приватности пользователя.
Поэтому этот меморандум определяет применения протокола управления
состоянием HTTP, установленного в RFC-2965, которые не рекомендуются
IETF либо считаются вредоносными и потому не поощряются.
В этом документе иногда используются термины, написанные прописными
буквами. Когда термины «MUST», «MUST NOT», «SHOULD», «SHOULD NOT» и
«MAY» появляются в верхнем регистре, они используются для обозначения
конкретных требований этой спецификации. Обсуждение значений терминов
«MUST», «SHOULD» и «MAY» приведено в [RFC-1123]; термины «MUST NOT» и
«SHOULD NOT» являются логическими расширениями этого употребления.
2. Применения управления состоянием HTTP
Цель управления состоянием HTTP состоит в том, чтобы позволить службе,
основанной на HTTP, создавать сохраняющиеся в нескольких транзакциях HTTP
сеансы с сохранением состояния. Один сеанс может включать транзакции с
несколькими серверными хостами. В одном сеансе могут также участвовать
несколько клиентских хостов, когда данные сеанса конкретного пользователя
совместно используются клиентскими хостами (например, через сетевую
файловую систему). Иными словами, «сеанс» сохраняет состояние между
«пользователем» и «службой», а не между конкретными хостами.
Важно понимать, что аналогичные возможности могут быть достигнуты и с
использованием «обычного» протокола HTTP и/или динамически создаваемого
HTML, без расширений управления состоянием. Например, информация о
состоянии может передаваться от службы пользователю путём встраивания
идентификатора сеанса в один или несколько URL, которые появляются в
перенаправлениях HTTP или динамически создаваемом HTML; а информация о
состоянии может возвращаться от пользователя службе, когда такие URL
появляются в запросе GET или POST. Формы HTML также могут использоваться
для передачи информации о состоянии от службы пользователю и обратно без
ведома пользователя о происходящем.
Однако средство управления состоянием HTTP действительно предоставляет
расширение функциональности по сравнению с обычными HTTP и HTML. На
практике эта дополнительная функциональность включает:
(1) Возможность обмениваться между пользователями URL ресурсов,
доступ к которым был получен во время сеансов с сохранением
состояния, без раскрытия информации о состоянии, связанной с
этими сеансами. (Например: «Вот URL записи веб-каталога FooCorp
о тех сандалиях, которые ты хотел.»)
(2) Возможность поддерживать состояние сеанса без «нарушения работы
кэша». То есть отделение состояния сеанса от URL позволяет
веб-кэшу поддерживать только одну копию именованного ресурса.
Если состояние поддерживается в URL, специфичных для сеанса,
кэшу, вероятно, пришлось бы поддерживать несколько идентичных
копий ресурса.
(3) Возможность реализовывать сеансы с минимальной конфигурацией
сервера и минимальными накладными расходами протокола по сравнению
с другими способами поддержания состояния сеанса.
(4) Возможность связывать пользователя с состоянием сеанса всякий раз,
когда пользователь обращается к службе, независимо от того,
входит ли пользователь через конкретную «домашнюю страницу» или
«портал».
(5) Возможность сохранять информацию о сеансе в постоянном хранилище,
чтобы «сеанс» мог поддерживаться между запусками клиента,
перезагрузками системы и сбоями клиента или системы.
2.1. Рекомендуемые применения
Использование управления состоянием HTTP уместно всякий раз, когда
желательно поддерживать состояние между пользователем и службой через
несколько транзакций HTTP, при условии, что:
(1) пользователь знает, что состояние сеанса поддерживается, и
соглашается на это;
(2) пользователь имеет возможность в любое время удалить состояние,
связанное с таким сеансом;
(3) информация, полученная благодаря возможности отслеживать
использование пользователем службы, не раскрывается другим
сторонам без явно выраженного согласия пользователя; и
(4) сама информация о сеансе не может содержать конфиденциальную
информацию и не может использоваться для получения
конфиденциальной информации, которая иначе недоступна
перехватчику.
Этот последний пункт важен, поскольку cookies обычно передаются в
открытом виде и, следовательно, легко доступны перехватчикам.
Примером такого рекомендуемого применения могла бы быть «корзина
покупок», существование которой явно доводится до сведения пользователя,
пользователь может явно «очистить» свою корзину покупок (либо запросив
её очистку, либо купив эти товары) и тем самым вызвать отбрасывание
совместно используемого состояния, а служба заявляет, что не будет
раскрывать привычки пользователя в покупках или просмотре третьим
сторонам без согласия пользователя.
Обратите внимание, что протокол управления состоянием HTTP фактически
позволяет поставщику службы отказаться предоставлять службу либо
предоставлять её на пониженном уровне, если пользователь или клиент
пользователя не выполняет запрос на поддержание состояния сеанса. При
отсутствии противоречащего этому законодательного запрета сервер МОЖЕТ
(MAY) отказаться предоставлять службу либо предоставлять её на
пониженном уровне при этих условиях. В качестве чисто практического
соображения службы, спроектированные для использования управления
состоянием HTTP, могут быть неспособны работать правильно, если клиент
его не предоставляет. Такие серверы СЛЕДУЕТ (SHOULD) корректно
обрабатывать такие условия и объяснять пользователю, почему полный
уровень службы недоступен.
2.2. Проблематичные применения
Следующие применения управления состоянием HTTP считаются неуместными
и противоречащими этой спецификации:
2.2.1. Раскрытие информации третьим сторонам
Управление состоянием HTTP НЕ ДОЛЖНО (MUST NOT) использоваться для
раскрытия информации о пользователе или привычках пользователя при
просмотре другим сторонам, помимо пользователя или службы, без явно
выраженного согласия пользователя. Такое использование запрещено даже
в том случае, если имя пользователя или иной внешне назначенный
идентификатор не раскрываются другим сторонам, поскольку сам механизм
управления состоянием предоставляет идентификатор, который может
использоваться для сбора информации о пользователе.
Поскольку такие практики побуждают пользователей обходить механизмы
управления состоянием HTTP, они, как правило, снижают эффективность
управления состоянием HTTP и поэтому считаются вредными для работы веба.
2.2.2. Использование в качестве механизма аутентификации
В целом неуместно использовать протокол управления состоянием HTTP в
качестве механизма аутентификации. Управление состоянием HTTP не
разрабатывалось с учётом такого использования, а меры защиты учётных
данных аутентификации отсутствуют как в спецификации протокола, так и в
широко развёрнутых клиентах и серверах HTTP. Большинство сеансов HTTP не
зашифровано, и поэтому «cookies» могут быть раскрыты пассивным
перехватчикам. Кроме того, клиенты и серверы HTTP обычно хранят «cookies»
в открытом тексте с небольшой защитой от раскрытия или вовсе без неё.
Поэтому управление состоянием HTTP НЕ СЛЕДУЕТ (SHOULD NOT) использовать
в качестве механизма аутентификации для защиты информации от раскрытия
неавторизованным сторонам, даже если сеансы HTTP зашифрованы.
Запрет на использование управления состоянием HTTP для аутентификации
включает как его использование для защиты информации, предоставляемой
службой, так и его использование для защиты потенциально
конфиденциальной информации о пользователе, вверенной заботе службы.
Например, было бы неуместно раскрывать имя, адрес, номер телефона или
платёжную информацию пользователя клиенту, который лишь предъявил cookie,
ранее связанный с этим пользователем.
Аналогично, управление состоянием HTTP НЕ СЛЕДУЕТ (SHOULD NOT)
использовать для аутентификации пользовательских запросов, если
неавторизованные запросы могут иметь нежелательные побочные последствия
для пользователя, кроме случая, когда пользователь осведомлён о
возможности таких побочных последствий и явно соглашается на такое
использование. Например, служба, позволяющая пользователю заказать товар
одним «щелчком», полностью основываясь на сохранённых «cookies»
пользователя, могла бы причинить пользователю неудобство, потребовав от
неё оспаривать списания с её кредитной карты и/или возвращать нежелательный
товар в случае раскрытия cookies третьим сторонам.
Некоторые применения управления состоянием HTTP для идентификации
пользователей могут быть относительно безвредными, например если вся
информация, которая может быть так раскрыта, принадлежит службе и служба
понесёт небольшой ущерб от раскрытия такой информации.
3. Соображения относительно пользовательского интерфейса для управления состоянием HTTP
Управление состоянием HTTP вызывает значительные споры из-за своей
способности раскрывать третьим сторонам информацию о привычках
пользователя при просмотре без ведома или согласия пользователя. Хотя
такое раскрытие возможно, оно является скорее не недостатком самого
протокола, а следствием неспособности реализаций клиентов HTTP (и
некоторых поставщиков служб на основе HTTP) защищать интересы
пользователей.
Как подразумевается выше, существуют иные способы поддерживать состояние
сеанса, помимо использования управления состоянием HTTP, а следовательно,
и иные способы отслеживать привычки пользователей при просмотре. В
действительности трудно представить, как протокол HTTP или клиент HTTP
могли бы реально помешать службе раскрывать другим сторонам «след щелчков»
пользователя, если служба решила бы это сделать. Поэтому защита такой
информации от ненадлежащего раскрытия должна быть обязанностью службы.
Реализации клиентов HTTP по своей природе не могут обеспечить такую
защиту, хотя они могут реализовать контрмеры, затрудняющие использование
управления состоянием HTTP как механизма, посредством которого такая
информация раскрывается.
Можно утверждать, что клиенты HTTP в целом должны обеспечивать большую
защиту от ненадлежащего раскрытия информации отслеживания независимо от
того, облегчалось ли раскрытие использованием управления состоянием HTTP
или каким-либо иным средством. Однако вопросы, связанные с другими
механизмами, выходят за рамки этого меморандума.
3.1. Возможности, требуемые от клиента HTTP
Готовность пользователя согласиться на использование управления
состоянием HTTP, вероятно, различается от службы к службе в зависимости
от того, доверяет ли пользователь службе надлежащее использование
информации и ограничение её раскрытия другим сторонам. Поэтому у
пользователя СЛЕДУЕТ (SHOULD) быть возможность управлять тем,
поддерживает ли его клиент запрос службы на использование управления
состоянием HTTP, для каждой службы отдельно. В частности:
(1) Клиенты НЕ ДОЛЖНЫ (MUST NOT) отвечать на запросы управления
состоянием HTTP, если это явно не включено пользователем. (2) Клиентам СЛЕДУЕТ (SHOULD) предоставлять эффективный интерфейс, позволяющий
пользователям до того, как клиент предоставит серверу какую-либо
информацию о состоянии, просматривать и одобрять либо отклонять
любые конкретные запросы сервера на хранение информации о состоянии.
(3) Клиентам СЛЕДУЕТ (SHOULD) предоставлять эффективный интерфейс, позволяющий
пользователям предписывать своим клиентам игнорировать все запросы
конкретной службы на хранение информации о состоянии — для каждой
службы отдельно — немедленно в ответ на любой конкретный запрос
сервера, до того, как клиент предоставит серверу какую-либо
информацию о состоянии.
(4) Клиентам СЛЕДУЕТ (SHOULD) предоставлять эффективный интерфейс, позволяющий
пользователю отключать будущую передачу любой информации о состоянии
службе и/или удалять любую сохранённую информацию о состоянии для этой
службы, даже если пользователь ранее одобрил запрос службы на хранение
информации о состоянии.
(5) Клиентам СЛЕДУЕТ (SHOULD) предоставлять эффективный интерфейс, позволяющий
пользователю отменить ранее сделанный запрос не сохранять информацию
об управлении состоянием для данной службы.
3.2. Ограничения алгоритма сопоставления доменов
Алгоритм сопоставления доменов в разделе 2 RFC-2965 предназначен как
эвристический метод, позволяющий клиенту «угадать», являются ли два домена
частями одной и той же службы. Существует немного правил относительно того,
как могут использоваться доменные имена, а структура доменных имён и способы
их делегирования различаются от одного домена верхнего уровня к другому
(то есть клиент не может определить, какая часть домена была назначена
службе).
Moore & Freed Best Current Practice [Страница 6]
RFC 2964 Use of HTTP State Management Октябрь 2000
Поэтому НИКАКОЙ алгоритм сравнения строк (включая алгоритм сопоставления
доменов) не может считаться надёжным для различения домена, принадлежащего
конкретной службе, и домена, принадлежащего другой стороне.
Как указано выше, каждая служба в конечном счёте несёт ответственность за
обеспечение того, чтобы информация о пользователе не раскрывалась
ненадлежащим образом третьим сторонам. Раскрытие информации третьим сторонам
посредством управления состоянием путём тщательного выбора доменных имён или
назначения доменных имён хостам, поддерживаемым третьими сторонами, является
по меньшей мере столь же ненадлежащим, как раскрытие той же информации
другими способами.
4. Вопросы безопасности
Вся эта памятка посвящена вопросам безопасности.
5. Адреса авторов
Keith Moore
University of Tennessee Computer Science Department
1122 Volunteer Blvd, Suite 203
Knoxville TN, 37996-3450
EMail: moore@cs.utk.edu
Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 81790
EMail: ned.freed@innosoft.com
6. Ссылки
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
Moore & Freed Best Current Practice [Страница 7]
RFC 2964 Use of HTTP State Management Октябрь 2000
7. Полное заявление об авторских правах
Copyright (C) The Internet Society (2000). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим
лицам, а производные работы, которые комментируют или иным образом объясняют
его либо содействуют его реализации, могут подготавливаться, копироваться,
публиковаться и распространяться полностью или частично без каких-либо
ограничений при условии, что указанное выше уведомление об авторских правах и
этот абзац включены во все такие копии и производные работы. Однако сам этот
документ не может быть каким-либо образом изменён, например путём удаления
уведомления об авторских правах или ссылок на Internet Society либо другие
интернет-организации, кроме случаев, когда это необходимо для разработки
интернет-стандартов, и в таком случае должны соблюдаться процедуры в
отношении авторских прав, определённые в процессе разработки интернет-
стандартов, либо когда это требуется для его перевода на языки, отличные от
английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут
отозваны Internet Society либо его правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ», И THE INTERNET SOCIETY И THE INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО
ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ
НЕ НАРУШИТ КАКИЕ-ЛИБО ПРАВА, ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ
ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время обеспечивается Internet
Society.
Moore & Freed Best Current Practice [Страница 8]
Network Working Group K. Moore
Request for Comments: 2964 University of Tennessee
BCP: 44 N. Freed
Category: Best Current Practice Innosoft
October 2000
Use of HTTP State Management
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
IESG Note
The IESG notes that this mechanism makes use of the .local top-level
domain (TLD) internally when handling host names that don't contain
any dots, and that this mechanism might not work in the expected way
should an actual .local TLD ever be registered.
Abstract
The mechanisms described in "HTTP State Management Mechanism" (RFC-
2965), and its predecessor (RFC-2109), can be used for many different
purposes. However, some current and potential uses of the protocol
are controversial because they have significant user privacy and
security implications. This memo identifies specific uses of
Hypertext Transfer Protocol (HTTP) State Management protocol which
are either (a) not recommended by the IETF, or (b) believed to be
harmful, and discouraged. This memo also details additional privacy
considerations which are not covered by the HTTP State Management
protocol specification.
1. Introduction
The HTTP State Management mechanism is both useful and controversial.
It is useful because numerous applications of HTTP benefit from the
ability to save state between HTTP transactions, without encoding
such state in URLs. It is controversial because the mechanism has
been used to accomplish things for which it was not designed and is
not well-suited. Some of these uses have attracted a great deal of
public criticism because they threaten to violate the privacy of web
Moore & Freed Best Current Practice [Page 1]
RFC 2964 Use of HTTP State Management October 2000
users, specifically by leaking potentially sensitive information to
third parties such as the Web sites a user has visited. There are
also other uses of HTTP State Management which are inappropriate even
though they do not threaten user privacy.
This memo therefore identifies uses of the HTTP State Management
protocol specified in RFC-2965 which are not recommended by the IETF,
or which are believed to be harmful and are therefore discouraged.
This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
appear capitalized, they are being used to indicate particular
requirements of this specification. A discussion of the meanings of
the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123]; the
terms "MUST NOT" and "SHOULD NOT" are logical extensions of this
usage.
2. Uses of HTTP State Management
The purpose of HTTP State Management is to allow an HTTP-based
service to create stateful "sessions" which persist across multiple
HTTP transactions. A single session may involve transactions with
multiple server hosts. Multiple client hosts may also be involved in
a single session when the session data for a particular user is
shared between client hosts (e.g., via a networked file system). In
other words, the "session" retains state between a "user" and a
"service", not between particular hosts.
It's important to realize that similar capabilities may also be
achieved using the "bare" HTTP protocol, and/or dynamically-generated
HTML, without the State Management extensions. For example, state
information can be transmitted from the service to the user by
embedding a session identifier in one or more URLs which appear in
HTTP redirects, or dynamically generated HTML; and the state
information may be returned from the user to the service when such
URLs appear in a GET or POST request. HTML forms can also be used to
pass state information from the service to the user and back, without
the user being aware of this happening.
However, the HTTP State Management facility does provide an increase
in functionality over ordinary HTTP and HTML. In practice, this
additional functionality includes:
(1) The ability to exchange URLs between users, of resources
accessed during stateful sessions, without leaking the state
information associated with those sessions. (e.g. "Here's the
URL for the FooCorp web catalog entry for those sandals that
you wanted.")
Moore & Freed Best Current Practice [Page 2]
RFC 2964 Use of HTTP State Management October 2000
(2) The ability to maintain session state without "cache-busting".
That is, separating the session state from the URL allows a web
cache to maintain only a single copy of the named resource. If
the state is maintained in session-specific URLs, the cache
would likely have to maintain several identical copies of the
resource.
(3) The ability to implement sessions with minimal server
configuration and minimal protocol overhead, as compared to
other techniques of maintaining session state.
(4) The ability to associate the user with session state whenever a
user accesses the service, regardless of whether the user
enters through a particular "home page" or "portal".
(5) The ability to save session information in stable storage, so
that a "session" can be maintained across client invocations,
system reboots, and client or system crashes.
2.1. Recommended Uses
Use of HTTP State Management is appropriate whenever it is desirable
to maintain state between a user and a service across multiple HTTP
transactions, provided that:
(1) the user is aware that session state is being maintained and
consents to it,
(2) the user has the ability to delete the state associated with
such a session at any time,
(3) the information obtained through the ability to track the
user's usage of the service is not disclosed to other parties
without the user's explicit consent, and
(4) session information itself cannot contain sensitive information
and cannot be used to obtain sensitive information that is not
otherwise available to an eavesdropper.
This last point is important because cookies are usually sent in the
clear and hence are readily available to eavesdroppers.
An example of such a recommended use would be a "shopping cart",
where the existence of the shopping cart is explicitly made known to
the user, the user can explicitly "empty" his or her shopping cart
(either by requesting that it be emptied or by purchasing those
Moore & Freed Best Current Practice [Page 3]
RFC 2964 Use of HTTP State Management October 2000
items) and thus cause the shared state to be discarded, and the
service asserts that it will not disclose the user's shopping or
browsing habits to third parties without the user's consent.
Note that the HTTP State Management protocol effectively allows a
service provider to refuse to provide a service, or provide a reduced
level of service, if the user or a user's client fails to honor a
request to maintain session state. Absent legal prohibition to the
contrary, the server MAY refuse to provide the service, or provide a
reduced level of service, under these conditions. As a purely
practical consideration, services designed to utilize HTTP State
Management may be unable to function properly if the client does not
provide it. Such servers SHOULD gracefully handle such conditions
and explain to the user why the full level of service is not
available.
2.2. Problematic Uses
The following uses of HTTP State Management are deemed inappropriate
and contrary to this specification:
2.2.1. Leakage of Information to Third Parties
HTTP State Management MUST NOT be used to leak information about the
user or the user's browsing habits to other parties besides the user
or service, without the user's explicit consent. Such usage is
prohibited even if the user's name or other externally-assigned
identifier are not exposed to other parties, because the state
management mechanism itself provides an identifier which can be used
to compile information about the user.
Because such practices encourage users to defeat HTTP State
Management mechanisms, they tend to reduce the effectiveness of HTTP
State Management, and are therefore considered detrimental to the
operation of the web.
2.2.2. Use as an Authentication Mechanism
It is generally inappropriate to use the HTTP State Management
protocol as an authentication mechanism. HTTP State Management is
not designed with such use in mind, and safeguards for protection of
authentication credentials are lacking in both the protocol
specification and in widely deployed HTTP clients and servers. Most
HTTP sessions are not encrypted and "cookies" may therefore be
exposed to passive eavesdroppers. Furthermore, HTTP clients and
servers typically store "cookies" in cleartext with little or no
protection against exposure. HTTP State Management therefore SHOULD
Moore & Freed Best Current Practice [Page 4]
RFC 2964 Use of HTTP State Management October 2000
NOT be used as an authentication mechanism to protect information
from being exposed to unauthorized parties, even if the HTTP sessions
are encrypted.
The prohibition against using HTTP State Management for
authentication includes both its use to protect information which is
provided by the service, and its use to protect potentially sensitive
information about the user which is entrusted to the service's care.
For example, it would be inappropriate to expose a user's name,
address, telephone number, or billing information to a client that
merely presented a cookie which had been previously associated with
the user.
Similarly, HTTP State Management SHOULD NOT be used to authenticate
user requests if unauthorized requests might have undesirable side-
effects for the user, unless the user is aware of the potential for
such side-effects and explicitly consents to such use. For example,
a service which allowed a user to order merchandise with a single
"click", based entirely on the user's stored "cookies", could
inconvenience the user by requiring her to dispute charges to her
credit card, and/or return the unwanted merchandise, in the event
that the cookies were exposed to third parties.
Some uses of HTTP State Management to identify users may be
relatively harmless, for example, if the only information which can
be thus exposed belongs to the service, and the service will suffer
little harm from the exposure of such information.
3. User Interface Considerations for HTTP State Management
HTTP State Management has been very controversial because of its
potential to expose information about a user's browsing habits to
third parties, without the knowledge or consent of the user. While
such exposure is possible, this is less a flaw in the protocol itself
than a failure of HTTP client implementations (and of some providers
of HTTP-based services) to protect users' interests.
As implied above, there are other ways to maintain session state than
using HTTP State Management, and therefore other ways in which users'
browsing habits can be tracked. Indeed, it is difficult to imagine
how the HTTP protocol or an HTTP client could actually prevent a
service from disclosing a user's "click trail" to other parties if
the service chose to do so. Protection of such information from
inappropriate exposure must therefore be the responsibility of the
service. HTTP client implementations inherently cannot provide such
protection, though they can implement countermeasures which make it
more difficult for HTTP State Management to be used as the mechanism
by which such information is exposed.
Moore & Freed Best Current Practice [Page 5]
RFC 2964 Use of HTTP State Management October 2000
It is arguable that HTTP clients should provide more protection in
general against inappropriate exposure of tracking information,
regardless of whether the exposure were facilitated by use of HTTP
State Management or by some other means. However, issues related to
other mechanisms are beyond the scope of this memo.
3.1. Capabilities Required of an HTTP Client
A user's willingness to consent to use of HTTP State Management is
likely to vary from one service to another, according to whether the
user trusts the service to use the information appropriately and to
limit its exposure to other parties. The user therefore SHOULD be
able to control whether his client supports a service's request to
use HTTP State Management, on a per-service basis. In particular:
(1) Clients MUST NOT respond to HTTP State Management requests
unless explicitly enabled by the user.
(2) Clients SHOULD provide an effective interface which allows
users to review, and approve or refuse, any particular requests
from a server to maintain state information, before the client
provides any state information to the server.
(3) Clients SHOULD provide an effective interface which allows
users to instruct their clients to ignore all requests from a
particular service to maintain state information, on a per-
service basis, immediately in response to any particular
request from a server, before the client provides any state
information to the server.
(4) Clients SHOULD provide an effective interface which allows a
user to disable future transmission of any state information to
a service, and/or discard any saved state information for that
service, even though the user has previously approved a
service's request to maintain state information.
(5) Clients SHOULD provide an effective interface which allows a
user to terminate a previous request not to retain state
management information for a given service.
3.2. Limitations of the domain-match algorithm
The domain-match algorithm in RFC-2965 section 2 is intended as a
heuristic to allow a client to "guess" whether or not two domains are
part of the same service. There are few rules about how domain names
can be used, and the structure of domain names and how they are
delegated varies from one top-level domain to another (i.e. the
client cannot tell which part of the domain was assigned to the
Moore & Freed Best Current Practice [Page 6]
RFC 2964 Use of HTTP State Management October 2000
service). Therefore NO string comparison algorithm (including the
domain-match algorithm) can be relied on to distinguish a domain that
belongs to a particular service, from a domain that belongs to
another party.
As stated above, each service is ultimately responsible for ensuring
that user information is not inappropriately leaked to third parties.
Leaking information to third parties via State Management by careful
selection of domain names, or by assigning domain names to hosts
maintained by third parties, is at least as inappropriate as leaking
the same information by other means.
4. Security Considerations
This entire memo is about security considerations.
5. Authors' Addresses
Keith Moore
University of Tennessee Computer Science Department
1122 Volunteer Blvd, Suite 203
Knoxville TN, 37996-3450
EMail: moore@cs.utk.edu
Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 81790
EMail: ned.freed@innosoft.com
6. References
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997.
Moore & Freed Best Current Practice [Page 7]
RFC 2964 Use of HTTP State Management October 2000
7. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Moore & Freed Best Current Practice [Page 8]