Internet DRAFT - draft-pietrak-cookie-scope
draft-pietrak-cookie-scope
Network Working Group R. Pietrak
Internet-Draft 18 August 2021
Intended status: Standards Track
Expires: 19 February 2022
Cookie Extension Limiting Its Availability to User Agent Components
draft-pietrak-cookie-scope-02
Abstract
This memo addresses cookies security by introduction of an additional
constraints, web application designer may impose on cookie
availability for localhost applications components. Here proposed
new cookie attribute attempts to provide that missing functionality
while retaining all currently known use scenarios of cookies.
However, this new attribute is designed to be more useful for banking
applications, then for social media networks.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 February 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pietrak Expires 19 February 2022 [Page 1]
Internet-Draft Cookies Local Scope August 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Cookie Radius attribute . . . . . . . . . . . . . . . . . . . 4
3.1. Radius attribute names . . . . . . . . . . . . . . . . . 4
3.2. Radius values . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Radius interaction with other attributes . . . . . . . . 6
3.4. application altering Radius . . . . . . . . . . . . . . . 7
4. Examples of use scenarios . . . . . . . . . . . . . . . . . . 7
5. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Implementation . . . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
As of current standard, HTTP state management mechanism RFC 6265
[refs.RFC6265], provide tools (in the form of cookie attributes) to
limit the dissemination of any particular cookie. Those constraints
are:
* Cookie domain
* Cookie expiration time
Pietrak Expires 19 February 2022 [Page 2]
Internet-Draft Cookies Local Scope August 2021
* HttpOnly attribute
* Secure attribute
But, current standard doesn't provide means to control the scope
cookies are available to localhost components, like user agent
software. These days search engines provide host of evidence that
programmers continuously look for such means. Usually, the question
is: "How do I limit my session cookie to just a single tab?".
The questions comes from evident need to move away out off user
session-ID (acquired after login/pass verification) visible in plain
sight as part of URL referring to the access limited pages. Usually,
plans to do such migrations are evaluated under strict requirement,
that current functionality remains unaltered. Here the required
functionality usually boils down to having such session-ID not shared
among interface components which weren't involved in credentials
verification. Meaning, that only the tab that provided credentials
(login/pass) will be authorized to access those particular resources.
In other words: since currently every window and every tab may have a
different URL retrieved, it should also be possible for it to have
different (from other tabs) session login credentials.
This is considered a desired (or even required) feature.
As of now, storing such login session credentials within a cookie
(which is also widely used to hold session credentials) alters this
functionality, and so is not acceptable for those migrations. The
functionality is lost, because a cookie set in one tab of web browser
will be immediately available to all other tabs.
On the other hand, current functionality of sharing all cookies
between all application components is desired by other web
application programmers. This memo introduces cookie attribute,
which will maintain current cookie behavior, while allowing for
currently missing cookie scope limitations to be explicitly set by
web application programmer.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119
[refs.RFC2119] when, and only when, they appear in all capitals, as
shown here.
The following other terms will be used in this memo according to
definitions below:
Pietrak Expires 19 February 2022 [Page 3]
Internet-Draft Cookies Local Scope August 2021
user: Within a computer system the term "user" means any set of
components holding the same security credentials. These
credentials may originate (or be derived) from a physical person
giving them out to a login application, or they may originate from
kernel maintained vault of credentials designated for system
components when system (unattended) application actions are due.
System services like ntp service, or MTA (mail transport agent)
are examples of the later case.
application: Any programmatic component of a computer system.
app-window: Any input/output channel, that an application may have
an access to independently from other such channels. An example
of such channel is GUI window, which gets data (like graphics)
from an application, while all other windows of that same
application does not get disturbed by that data stream. Every
HTTP data stream, from open to close is considered a separate
window, with the exception below, where "tabs" are defined. Human
Interface Devices (HID, like: keyboard, mice, microphone,
earphones, etc) happen to get bond to one particular app-window.
This state of bonding is refered to as window-focus.
window: A synonym to app-window.
window-tab: Any part of a window, that holds and presents (or
processes) one HTML document, including all objects that may be
retrieved separately (separate HTTP connections), but are a part
(functionally or aesthetically) of the main document. It's valid
to say, that a tab is whatever is necessary to present (or
process) whatever server returns in response for a single user
click, including all the subcomponents, that HTML defines to be
retrieved as a result of that click. When HID is bond to one
window-tab, no other windows or tabs get events from/to that HID
device.
tab: A synonym to window-tab
viewport: A single window-tab currently selected/bond
(activated/focused/visible) to/by the user.
3. Cookie Radius attribute
3.1. Radius attribute names
Cookie Radius attribute will have the following names:
SetRadius: when send from the server to web browser.
Pietrak Expires 19 February 2022 [Page 4]
Internet-Draft Cookies Local Scope August 2021
RadiusSet: when returned from web browser to the server.
This is to let server distinguish those web browsers that actually
support cookie Radius limitations from those that blindly return
cookies as provided.
3.2. Radius values
Cookie Radius attribute will have only one of the following four
values, and system behavior for each of them is the following:
World: Cookie will be available to all user applications. Every web
browsers launched by a particular user will see that cookie. When
an application does not implement access to OS defined store for
such cookies, this value MUST be implemented as synonym missing
Radius attribute, which in turn MUST be implemented as synonym to
SetRadius=Application. Still, even if such store is defined by
the OS, application MAY choose to implement World value of Radius
attribute as synonym to SetRadius=Application. Session expiration
of such cookie is ment to be interpretted as end of user login
session on that computer.
Application: Cookie will be available to all the windows and tabs of
a single application that received that cookie. This is the
default value of cookie Radius attribute. This value represent
today's implementations and current practices of cookie handling
by web applications. Nothing should be changed in handling of a
cookie with this Radius value as compared to todays
implementation. Session expiration of such cookie is ment to be
interpretted as the moment user quit the application that received
such cookie.
Viewport: Cookie will not be available to any other system
component, but the tab, that received it. Session expiration of
such cookie is ment to be interpretted as the moment user closed
the particular tab that received such cookie, also when window
containing such tab is closed. When application does not allow
for multiple tabs, the later applies.
When cookie Radius attribute is not defined by a cookie, it MUST be
assumed to have a value of "Application". When cookie Radius
attribute is defined, but it's value is unrecognized, applications
MUST assume it's value is "Viewport".
Pietrak Expires 19 February 2022 [Page 5]
Internet-Draft Cookies Local Scope August 2021
3.3. Radius interaction with other attributes
HttpOnly cookie attribute is completely independent and
implementations WILL NOT correlate values of HttpOnly attribute with
any value of cookie Radius attribute.
Cookie "domain" interferes with cookie Radius only when its value is
"Viewport". In that case (either explicitly set or assumed as
default), "domain" is set to domain of URL retrieved irrespectively
of setting within the cookie. Consequently availability of such
cookie is not only limited to a single viewport, but also to a
"domain" the tab content originated from.
In other words, "Viewport" cookies never traverse domains.
Implementation MAY choose to register origin of a document with
SetRadius=Viewport and do a filtering-away of subcomponents from its
fetch-list based on that value, instead of changing cookie domain and
relay on standard cookie dispatch mechanism. Such implementation
will unnecessarily limit document contents to single domain, while
what is actually required is to prevent SetRadius=Viewport cookies
from being exposed to other domains. Such unnecessary limitation is
undesired, but allowed.
It must be pointed out here, that the above "domain" restriction is
in fact the core feature of here proposed new Radius cookie
attribute. For a cookie with SetRadius=Viewport to be functionally
equivalent to session token being placed inside document URL, it is
required, that no remote party (like an embedded picture from a
different "domain") other then the server of the master document,
will ever get any piece of information that originally was part of
the main document session security token in its URL.
This is a security feature.
Cookies with Radius set to Viewport MUST expire when their Viewport
is closed. This SHOULD NOT influence application normal reaction to
server provided "expires" or "max-age" attributes, only in that for
cookies with SetRadius=Viewport, Viewport close event takes
precedence over any of them.
Pietrak Expires 19 February 2022 [Page 6]
Internet-Draft Cookies Local Scope August 2021
3.4. application altering Radius
User agent MAY let users further tighten the scope of a cookie below
the radius declared in cookie Radius attribute, but it MUST NOT allow
user to expand the radius. That is particularly important for
"HttpOnly=false" cookies. "SetRadius=Viewport; HttpOnly=false"
cookies are visible to the scripting engine, and can be modified.
However implementation MUST NOT let scripts expand their Radius, too.
The only action allowed for both application controls and scripting
engine is the reduction of the Radius. After Radius is reduced,
there MUST NOT be any local to application way to get back the
initial radius. The only way to expand cookie Radius (back) is to
refresh the Viewport from server and relay on server to ignore the
currently reported new RadiusSet=value - which it may or may not do,
depending on the application.
Note, that in the above scenario, server may respond with a different
document asking user for confirmation of the decision to reduce the
Radius.
4. Examples of use scenarios
The following examples are discussed here to further define the
intended use of the cookie Radius attribute:
* popup windows WILL NOT have access to cookies with Viewport value
of their Radius. One exception to that rule is a popup window
that is a result of user click on anchor document tag. No matter
if that tag has or has not it's target diverted from "_self", any
Viewport that resulted from such click WILL get all the Viewport
cookies original document had.
* window.open(<href>, <target>) request from a document with cookie
having SetRadius=Viewport will only be send to the server, if and
only if <target> is equal to "_self" and <href> is equal to the
domain of current document (and thus to that cookie). This
constraint in actions (as compared to popup windows above) is here
to limit the influence of scripting in background - limit the
actions without user explicit consent.
* Parts of document created with document.write() action, will not
be interpreted any differently. This is because for all documents
with SetRadius=Viewport cookies, the script attempting that surely
came from the same domain/origin as the modified document itself.
Pietrak Expires 19 February 2022 [Page 7]
Internet-Draft Cookies Local Scope August 2021
Actual implementations of SetRadius=Viewport cookies MAY use a
dedicated part of sessionStore application repository to satisfy the
requirement to flush those cookies at session end and to block other
Viewports from accessing it.
5. Security
5.1. General
The actual impact of the proposed cookie attribute can only be truly
evaluated after its wide implementation and use in other then here
presented scenarios. The potential to limit the leakage of security
data (login credentials) between application components may help
improve internet security.
5.2. Implementation
Functionally, cookies with SetRadius=Viewport can be quite closely
implemented with document.cookie and window.sessionStore like:
* on successful login, server responses with security tokens on a
SetRadius=Viewport cookie.
* Content of that cookie is put into the sessionStore.
* every anchor would get an onclick() event hook, which will create
session cookie, which in turn will get dispatched to server as all
other relevant cookies.
* once response page is loaded, relevant (but different) function
will delete the cookie from the application.
Only in such implementation the cookie created right before anchor
triggering a GET request is available to all other windows and tags
of the application, and not only it leaks security information, but
also can influence other documents in other windows and tabs by
substituting their security tokens of the same name, with value not
belonging to them.
Such implementation cannot be accepted as a workaround for missing
Radius cookie attribute.
6. Informative References
[refs.RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Pietrak Expires 19 February 2022 [Page 8]
Internet-Draft Cookies Local Scope August 2021
[refs.RFC6265]
Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011, <https://www.rfc-editor.org/rfc/rfc6265>.
Author's Address
Rafal Pietrak
Email: cookie.rp@ztk-rp.eu
Pietrak Expires 19 February 2022 [Page 9]
