An idea for a new cookie attribute - Delete On Close

WhoAmI

Hi!

My name is Eitan Caspi.

I am a veteran Information Security expert from Israel, although I must
admit 

my experience with web technologies is not more than a few years old, so I 

hope I will not fault here too much.

 

Background

Cookies are an essential method in today's web technology (HTTP to be 

exact), helping us to enable consecutiveness in a client's session with a
web 

site or application.

>From a security perspective the cookie can be treated as a "cached identity"


that is saved on the client's side application (usually browser), thus
making it 

an attractive target for theft (resulting in identity theft), replay and
possible 

modification.

Hence the cookie needs defense measures, which today are made of the 

following main means, which I note here only the ones related to my idea - 

hence the usage of a cookie in the authentication process of the client to
the 

server:

1.            Time based deletion of the cookie

1.1.         The "expires" attribute - which "tells" the browser the exact
date and 

time in the future - it should delete the cookie. It is usually used by the 

web application/site to attempt and keep the cookie "alive" for a long 

term on the client side, so when the client returns later to the site, 

he/she is automatically identified, without the need to re-authenticate. 

This behavior of course makes such cookies a preferred target for 

theft and also an easier target as their "life span" is usually longer, 

giving the attacker more time to try and get them and more time to 

abuse them.  

The usage of this attribute entitles a cookie as a "Persistent Cookie"

1.2.         The "max-age"  attribute is similar to the "expires" as it is
also time 

based but it takes another approach and simply contain a value which 

is the number of seconds the cookie should "live" from the moment the 

browser received it - so instead a fixed date-time in the future, like 

"expires" use, it is a dynamic attribute that keeps the cookie alive in a 

constant known "future" time moving window, as long as the client is in 

connection with the site and keeps sending requests and accepting 

back responses with a cookie that use this attribute. 

You can think of this attribute as an "idle time"/"timeout" characteristic, 

calculated as "now + max-age-value". 

This attribute also makes the cookie somewhat "persistent".

1.2.1.     In the absence of either the "expires" attribute or the "max-age"


attribute - the user can (but this is not guaranteed) configure the 

browser to delete the cookie when the browser gets closed 

(notice - only the browser as a whole, not an in-browser 

window/tab). 

>From the security aspect this is better than the "expires" attribute 

since supposedly the cookie should have a shorter "life time" over 

the "Persistent Cookie", hence giving less time for the attacker to 

try and hijack the cookie, but the actual deletion of the cookie 

depends on the actual time the browser is exited, but this may 

happen only after a long time as many users keep their browser 

open for a long time as their "Window to the world". 

The process entitles a cookie as a "Session Cookie".

 

Although the benefits of the above defense measures, I feel we can enhance 

cookie security as I believe we still have a security gap in two aspects:

1.            We rely only on time based metrics, which limits the possible
ways that 

we can shorten the lifetime of the cookie if it is not actually used by the 

client - as we can also rely on user behavior to delete the cookie

2.            If we will use a metric that the server cannot calculate or
"know" about 

- to delete the cookie, the server does not "know" the relevant, real,  

identity has terminated its session, hence an attacker who stole the 

cookie - can still use the cookie to impersonate against the server

As a result of the above - I offer the following new cookie attributes
(names of 

course can be altered, there are only an initial suggestions):

 

Self-destructing cookie

Inspiration

In the past I used to work more with Firefox, and at one time I wanted to
have 

a better control from my side, the client side, so I will be able to delete 

sensitive cookies based on an action I will perform, like closing a browser
tab 

or window - and not being depended on the cookie's "time of death" the 

server/site has set. 

This goal sent me to find an existing solution and so I found a Firefox
plugin 

named "Self-Destructing Cookies - https://addons.mozilla.org/en-

US/firefox/addon/self-destructing-cookies/" which is developed by Ove (I
could 

not find more details about this person). This plugin gave me exactly what I


wanted and it made me happy. 

But then I thought - why do sites can only set the cookie's deletion event 

based on a time metric? Why not by a user event, like this plugin enables? 

Why not give the site owners a way to even more secure their cookies, by 

enabling them to specify a cookie deletion base on a user action? And this 

without the need to code, at the networking level. 

 

The idea

Background

Many times users login to web sites but do not bother to perform a neat log-

out operation, even when they only need to click a visible "log out" button


(which at time is "hidden" in a menu the client needs to open first) - they 

simply close the browser's tab/window, but the browser as whole remains 

open. 

Now, even if any of the above mentioned time based cookie attributes are in 

effect - the actual cookie deletion time may vary largely, especially the
for a 

"session" cookie, waiting for the browser's closure or for the needed time
to 

pass until the cookie is deleted at the client side.

This can lead to a situation where the cookie is deleted late (hence
exposing it 

to attacks for too long) or too early as the user still has the relevant
site open 

in another tab but the cookie has expired (functional fault).

So, while we have good time-based defense coverage (specific future date-

time ("expires") and delete-on-timeout ("max-age")), the user-action based 

defense relies only on a probably long term event like closing the browser,
so 

there is a gap in defense here, in my view.

 

Goal

The main goals of this idea is to allow sensitive web applications, mostly
for 

parts of the application that require login and authorization, to signal the


browser to delete the cookie as soon as the user is performing an action
that 

hints he/she no longer wishes to access the relevant web application - thus 

shortening the time frame in which the cookie is at risk of attack (stealing
and 

or re-use)

 

Realization

1.            General

1.1.         The core idea is that there will be a new cookie attribute that
will signal 

to the browser to delete the cookie in question as soon as the last or 

any of the browser's tab/window that is containing content from the 

relevant site/domain is closed

1.1.1.     An optional action will be to let the site "know" this cookies
has 

been deleted, meaning instructing the browser to send a system 

request to a logout URL of the site, a URL that will be supplied by 

the site as an additional, optional, cookie attribute

1.2.         I am aware my idea can be done by an app
script/code/browser-add-

on - but I wish to take this "deeper" into a wider scope, to catch more 

scenarios - as part of the server response, so it can be done also by 

the IT/IS employees, not depended on developers to change and 

maintain such a code

1.3.         Advantages

1.3.1.     This attribute will initiate the cookie's deletion based on a
user's 

actual action, not too far in time like the browser's closure and not 

time-arbitrary like "expires" and "max-age", thus filing the above 

mentioned gap since a tab closure hints that the user no longer 

wishes to use the mentioned site

1.3.1.1. The client side app (like the browser or an extension of it) 

can always add a GUI/configuration feature that will allow the 

user to control how he/she wishes to handle these attributes, 

follow them or ignore them - generally or per domain

1.3.2.     This attribute can of course be mentioned alongside both the 

time based attributes - and the browser will actually delete the 

cookie based the first triggered event - either this attribute or the 

"max-age" value (as it is mentioned as taking preference over 

"expires" as mentioned in RFC 6265, "HTTP State Management 

Mechanism" - "If a cookie has both the Max-Age and the Expires 

attribute, the Max-Age attribute has precedence and controls the 

expiration date of the cookie.", although my view is that the 

behavior should be that the first attribute, any of the three (the two 

time based and the one I suggest) that gets triggered first - will 

delete the cookie, to make sure the cookie is deleted as soon as 

possible).

1.3.3.     Of course, a browser's closure will be treated as closing the
last 

tab/window so all the cookies with this attribute should be deleted, 

thus having the same exact behavior as a non-explicit "session" 

cookie, so we keep consistency in this sense

1.3.3.1. If the browser did not shutdown neatly (e.g. because it 

has crashed or was "killed", possibly due to malicious activity) 

- on its next startup it will delete all the cookies with this 

attribute and send any logout request per the optional 

attribute - hence starting up "clean", preventing any attempt to 

retain authorization cookies accessible

1.4.         Disadvantages

1.4.1.     Extra complication as multiple cookie "kill" attributes needs to
be 

considered by the browser

2.            Use cases

2.1.         Any site that the app and/or owner wishes to minimize the risk
for the 

cookie and try to delete the cookie as soon as it is not needed - based 

on maximum metrics - time and now also user action, like banks, 

medical organizations, military and similar

2.2.         Here are some examples from the web to show the need:

2.2.1.     http://www.codeproject.com/Questions/423515/clearing-cookies-

on-closing-browser-tab

2.2.2.     http://stackoverflow.com/questions/1921941/close-kill-the-

session-when-the-browser-or-tab-is-closed

2.2.3.     http://stackoverflow.com/questions/805895/why-doesnt-closing-

a-tab-delete-a-session-cookie

3.            Implementation and notes

3.1.         Structure

3.1.1.     General

3.1.1.1. The attribute names and their values will NOT be case-

sensitive, to avoid errors

3.1.1.2. Following a successful login process, the web 

application/server/WAF/reverse proxy - will send to the 

client's side browser a cookie with the following cookie 

attribute(s):

3.1.2.     Samples - Building blocks

3.1.2.1. deleteonclose=

3.1.2.1.1.              In the overall concept of a cookie it is of course
an 

optional attribute, but for our goal - it is the must attribute

3.1.2.2. deleteonclose=last

3.1.2.2.1.              Instruct the browser to delete the cookie only when 

the last tab or window with a content from the relevant 

site is closed and when the browser is exited as a whole 

(less secure as it give the cookie more lifetime, but more 

operational friendly, as allowing more time to the user to 

return to site as an identified account)

3.1.2.3. deleteonclose=any  

(actually the first tab/window one to be closed, but I didn't 

want that folks may be confused thinking that "first" means 

the first tab/window opened based on a time metric)

3.1.2.3.1.              Instruct the browser to delete the cookie if any tab


or window with a content from the relevant site is closed 

(more secure as it give the cookie less lifetime, but less 

operational friendly, as the user will return to site as an 

un-identified account, as anonymous, being forced to do 

the login process again)

3.1.2.3.1.1.          Closing the browser will of course match 

this value as well

3.1.2.4. logout=

3.1.2.4.1.              This is the optional attribute - it will be used
ONLY 

if the deleteonclose attribute exists and formatted 

correctly, otherwise the browser will ignore it

3.1.2.4.2.              States the URL that the browser needs to send a 

system request to, with the relevant cookie, of course, 

just before the cookie is deleted because of the 

deleteonclose attribute

3.1.2.4.2.1.          The if the URL in the value is explicit and 

not relative (hence mentions a domain name) - the 

browser will accept it as a legit ONLY if the domain 

name fully match to the request header "host" 

attribute, which was at the request that originated / 

led to the relevant response, and this to avoid cross-

site redirection and adhere to the same-domain 

origin concept)

3.1.2.4.2.2.          If following this request the server has sent 

a reply - the browser will NOT process this 

response in any way and immediately discard it. 

This both because there is no real need for the 

browser to process it and to avoid possible attacks 

sourced by this server URL

3.1.2.4.3.              Possible values examples:

3.1.2.4.3.1.          Explicit http logout URL

3.1.2.4.3.1.1.      logout=http://site.com/logout.html 

3.1.2.4.3.2.          Explicit https logout URL

3.1.2.4.3.2.1.      logout=https://site.com/logout.html 

3.1.2.4.3.3.          Relative logout URL, meaning it will use the 

current host request attribute as the base for the 

URL and then add to it this value to make a valid 

and full logout URL

3.1.2.4.3.3.1.      logout=/site.com/logout.html

 

4.            In conclusion

4.1.         I know the above is very raw and initial but I hope you will
see it as a 

good idea and thus help make it better and eventually - make it a  

real-life HTTP cookie attribute for the world to use

4.2.         I believe adding these cookie attributes can tighten a bit more
the 

cookie defenses, adding a real-life-user-event-driven trigger to delete 

a cookie and also signal to the server that the relevant session had 

ended by the client side, hence minimizing it exposure window of the 

user's identity, hence making HTTP more secure

 

You can find my at: 

LinkedIn - https://www.linkedin.com/in/eitancaspi/ 

English Information Security blog - https://fudie.net

Page 1 of 8