HTTP cookie: Difference between revisions

Revision as of 11:47, 5 January 2024

Revision as of 18:44, 5 January 2024

Line 7:

'''HTTP cookies''' (also called '''web cookies''', '''Internet cookies''', '''browser cookies''', or simply '''cookies''') are small blocks of [[Data (computing)|data]] created by a [[web server]] while a [[User (computing)|user]] is [[browsing]] a [[website]] and placed on the user's computer or other device by the user's [[web browser]]. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session.

Cookies serve useful and sometimes essential functions on the [[World Wide Web|web]]. They enable web servers to store [[program state|stateful]] information (such as items added in the shopping cart in an [[Online shopping|online store]]) on the user's device or to track the user's browsing activity (including clicking particular buttons, [[access control|logging in]], or recording which [[Web browsing history|pages were visited in the past]]).<ref>{{Cite web|title=What are cookies? What are the differences between them (session vs. persistent)?|url=https://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/117925-technote-csc-00.html|id=117925|date=2018-07-17|website=Cisco|language=en}}</ref> They can also be used to save for subsequent use information that the user previously entered into [[Form (HTML)|form field]]s, such as names, addresses, [[password]]s, and [[payment card number]]s for subsequent use.

'''Authentication cookies''' are commonly used by web servers to [[Authentication|authenticate]] that a user is logged in, and with which [[Account verification|account]] they are logged in. Without the cookie, users would need to authenticate themselves by logging in on each page containing sensitive information that they wish to access. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is [[Encryption|encrypted]]. [[Vulnerability (computing)|Security vulnerabilities]] may allow a cookie's data to be read by an [[Security hacker|attacker]], used to gain access to [[Personal data|user data]], or used to gain access (with the user's credentials) to the website to which the cookie belongs (see [[cross-site scripting]] and [[cross-site request forgery]] for examples).<ref name="UjTred">{{cite web |url=http://news.cnet.com/8301-10789_3-9918582-57.html |first=Robert |last=Vamosi |title=Gmail cookie stolen via Google Spreadsheets |website=News.cnet.com |date=2008-04-14 |access-date=19 October 2017 |archive-url=https://web.archive.org/web/20131209210402/http://news.cnet.com/8301-10789_3-9918582-57.html |archive-date=9 December 2013 |url-status=live}}</ref>

Line 28:

The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk [[electronic mailing list|mailing list]]. A special working group within the [[Internet Engineering Task Force]] (IETF) was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by [[Brian Behlendorf]] and David Kristol respectively. But the group, headed by Kristol himself and Lou Montulli, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default.<ref name="RFC2109">{{Cite ietf|rfc=2109 |section=8.3 }}</ref> At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000.

RFC 2965 added a <code>Set-Cookie2</code> [[HTTP header|header field]], which informally came to be called "RFC 2965-style cookies" as opposed to the original <code>Set-Cookie</code> header field which was called "Netscape-style cookies".<ref name="AGgFj">{{cite web |url=https://staff.washington.edu/fmf/2009/06/19/setting-cookies/ |title=Setting Cookies |date=June 19, 2009 |website=staff.washington.edu |access-date=March 15, 2017 |archive-url=https://web.archive.org/web/20170316175133/https://staff.washington.edu/fmf/2009/06/19/setting-cookies/ |archive-date=March 16, 2017 |url-status=live}}</ref><ref name="V1mES">The edbrowse documentation version 3.5 said "Note that only Netscape-style cookies are supported. However, this is the most common flavor of cookie. It will probably meet your needs." This paragraph was removed in [http://edbrowse.org/usersguide.html#cook later versions of the documentation] {{Webarchive|url=https://web.archive.org/web/20170316024448/http://edbrowse.org/usersguide.html#cook |date=2017-03-16}} further to RFC 2965's deprecation.</ref> <code>Set-Cookie2</code> was seldom used, however, and was [[deprecate]]d in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world.<ref name="StateMgmt">{{cite web|last1=Hodges|first1=Jeff|last2=Corry|first2=Bil|title='HTTP State Management Mechanism' to Proposed Standard|url=http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html|website=The Security Practice|access-date=17 June 2016|date=6 March 2011|archive-url=https://web.archive.org/web/20160807062741/http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html|archive-date=7 August 2016|url-status=live}}</ref> No modern browser recognizes the <code>Set-Cookie2</code> header field.<ref name="TASE4">{{Cite web|title=Set-Cookie2 - HTTP {{!}} MDN|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie2|access-date=2021-03-08|website=developer.mozilla.org}}</ref>

==Terminology==

Line 51:

In 2016 [[Google Chrome]] version 51 introduced<ref name="T8177">{{Cite web|url=https://www.chromestatus.com/feature/4672634709082112|title='SameSite' cookie attribute, Chrome Platform tatus|website=Chromestatus.com|access-date=2016-04-23|archive-url=https://web.archive.org/web/20160509064447/https://www.chromestatus.com/feature/4672634709082112|archive-date=2016-05-09|url-status=live}}</ref> a new kind of cookie with attribute <code>SameSite</code>. The attribute <code>SameSite</code> can have a value of <code>Strict</code>, <code>Lax</code> or <code>None</code>.<ref name="oCqyo">{{Cite journal|url=https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00|title=Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00|last1=Goodwin|last2=West|first1=M.|newspaper=Ietf Datatracker|date=20 June 2016|access-date=2016-07-28|archive-url=https://web.archive.org/web/20160816182604/https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00|archive-date=2016-08-16|url-status=live}}</ref> With attribute <code>SameSite=Strict</code>, the browsers would only send cookies to a target ___domain that is the same as the origin ___domain. This would effectively mitigate [[cross-site request forgery]] (CSRF) attacks.<ref name="wi75q">{{Cite web|title=Using the Same-Site Cookie Attribute to Prevent CSRF Attacks|url=https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/|access-date=2021-04-05|website=www.netsparker.com|date=23 August 2016 |language=en}}</ref> With <code>SameSite=Lax</code>, browsers would send cookies with requests to a target ___domain even it is different from the origin ___domain, but only for ''safe'' requests such as GET (POST is unsafe) and not third-party cookies (inside iframe). Attribute <code>SameSite=None</code> would allow third-party (cross-site) cookies, however, most browsers require [[#Secure cookie|secure attribute]] on SameSite=None cookies.<ref name="vQf6D">{{Cite web|title=Require "Secure" for "SameSite=None". by miketaylr · Pull Request #1323 · httpwg/http-extensions|url=https://github.com/httpwg/http-extensions/pull/1323|access-date=2021-04-05|website=GitHub|language=en}}</ref>

The Same-site cookie is incorporated into [a new RFC draft for "Cookies: HTTP State Management Mechanism"<ref>{{Cite report |url=https://toolsdatatracker.ietf.org/htmldoc/draft-ietf-httpbis-rfc6265bis-/07/ a new RFC draft for "|title=Cookies: HTTP State Management Mechanism"] |last=West |first=Mike |last2=Wilander |first2=John |date=2020-12-07 |publisher=Internet Engineering Task Force |issue=draft-ietf-httpbis-rfc6265bis-07}}</ref> to update RFC 6265 (if approved).

Chrome, Firefox, Microsoftand Edge all started to support Same-site cookies.<ref name="sJzIz">{{Cite web|url=https://www.lambdatest.com/SameSite-cookie-attribute|title = Browser Compatibility Testing of 'SameSite' cookie attribute}}</ref> The key of rollout is the treatment of existing cookies without the SameSite attribute defined, Chrome has been treating those existing cookies as if SameSite=None, this would let all website/applications run as before. Google intended to change that default to SameSite=Lax in February 2020,<ref name="QPJhf">{{Cite web|title=SameSite Cookie Changes in February 2020: What You Need to Know|url=https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html|access-date=2021-04-05|website=Chromium Blog|language=en}}</ref> the change would break those applications/websites that rely on third-party/cross-site cookies, but without SameSite attribute defined. Given the extensive changes for web developers and [[COVID-19]] circumstances, Google temporarily rolled back the SameSite cookie change.<ref name="Ne4hV">{{Cite web|title=Temporarily rolling back SameSite Cookie Changes|url=https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html|access-date=2021-04-05|website=Chromium Blog|language=en}}</ref>

===Supercookie===