Re: An idea for a new cookie attribute - Delete On Close

I believe Clear-Site-Data
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data>
enables
sites to tackle the use case you bring up, and have certain URL paths clear
the site's cookies. Note that if it's not CSRF protected, any malicious
site would be able to do the same.

On Fri, Aug 3, 2018 at 6:04 PM Eitan at Gmail <eitanc@gmail.com> wrote:

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