Cookie Extension Limiting Its Availability to User Agent Components

Internet-Draft	Cookies Local Scope	August 2021
Pietrak	Expires 19 February 2022	[Page]

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.¶

Copyright Notice

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.¶

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¶
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:¶

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.1. Radius attribute names

Cookie Radius attribute will have the following names:¶

SetRadius:: when send from the server to web browser.¶
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".¶

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.¶

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.¶

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.¶