Content deleted Content added
updating cites |
|||
Line 20:
===History===
Magic cookies were already used in computing when computer programmer [[Lou Montulli]] had the idea of using them in web communications in June 1994.<ref name="N4WV7">{{cite news |url=https://www.nytimes.com/2001/09/04/technology/04COOK.html |work=The New York Times |first=John |last=Schwartz |title=Giving Web a Memory Cost Its Users Privacy |date=2001-09-04 |access-date=2017-02-19 |archive-url=https://web.archive.org/web/20111118090113/http://www.nytimes.com/2001/09/04/technology/04COOK.html |archive-date=2011-11-18 |url-status=live}}</ref> At the time, he was an employee of [[Netscape Communications]], which was developing an [[e-commerce]] application for [[MCI Inc.|MCI]]. [[Vint Cerf]] and [[John Klensin]] represented MCI in technical discussions with Netscape Communications. MCI did not want its servers to have to retain partial transaction states, which led them to ask Netscape to find a way to store that state in each user's computer instead. Cookies provided a solution to the problem of reliably implementing a [[Shopping cart software|virtual shopping cart]].<ref name="kesan">{{cite journal|last1=Kesan
Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of [[Netscape Navigator|Mosaic Netscape]], released on October 13, 1994,<ref name="JgNeY">{{cite web |url=http://wp.netscape.com/newsref/pr/newsrelease1.html |title=Press Release: Netscape Communications Offers New Network Navigator Free On The Internet |access-date=2010-05-22 |archive-url = https://web.archive.org/web/20061207145832/http://wp.netscape.com/newsref/pr/newsrelease1.html |archive-date=2006-12-07}}</ref><ref name="8YpTv">{{cite web |url=https://groups.google.com/group/comp.infosystems.www.users/msg/9a210e5f72278328 |title=Usenet Post by Marc Andreessen: Here it is, world! |date=1994-10-13 |access-date=2010-05-22 |archive-url=https://web.archive.org/web/20110427123350/http://groups.google.com/group/comp.infosystems.www.users/msg/9a210e5f72278328 |archive-date=2011-04-27 |url-status=live}}</ref> supported cookies.<ref name="
The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of their presence.{{cn|date=October 2022|reason=This is most likely incorrect, as at least Internet Explorer had very prominent cookie warnings and required explicit permission to accept any.}} The public learned about cookies after the ''[[Financial Times]]'' published an article about them on February 12, 1996.<ref name="B3JMd">{{cite news|last=Jackson|first=T|title=This Bug in Your PC is a Smart Cookie|newspaper=Financial Times|date=1996-02-12}}</ref> In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. [[Federal Trade Commission]] hearings in 1996 and 1997.<ref name="UjTred" />
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
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>
Line 34:
===Session cookie===
A ''session cookie'' (also known as an ''in-memory cookie'', ''transient cookie'' or ''non-persistent cookie'') exists only in temporary memory while the user navigates a website.<ref name="mscookie">
Session cookies expire or are deleted when the user closes the web browser.<ref name="HwxT6">{{cite web |url=http://msdn.microsoft.com/en-us/library/ms526029(v=vs.90).aspx |title=Maintaining session state with cookies |work=Microsoft Developer Network |access-date=22 October 2012 |archive-url=https://web.archive.org/web/20121014110456/http://msdn.microsoft.com/en-us/library/ms526029(v=vs.90).aspx |archive-date=14 October 2012 |url-status=live}}</ref> Session cookies are identified by the browser by the absence of an expiration date assigned to them.
Line 109:
Cookies are arbitrary pieces of data, usually chosen and first sent by the web server, and stored on the client computer by the web browser. The browser then sends them back to the server with every request, introducing [[state (computer science)|states]] (memory of previous events) into otherwise stateless [[HTTP]] transactions. Without cookies, each retrieval of a [[web page]] or component of a web page would be an isolated event, largely unrelated to all other page views made by the user on the website. Although cookies are usually set by the web server, they can also be set by the client using a scripting language such as [[JavaScript]] (unless the cookie's <code>HttpOnly</code> flag is set, in which case the cookie cannot be modified by scripting languages).
The cookie specifications<ref name="httponlyrfc">
* Can support cookies as large as 4,096 [[byte]]s in size.
* Can support at least 50 cookies per [[Internet ___domain|___domain]] (i.e. per website).
Line 157:
The <code>Domain</code> and <code>Path</code> attributes define the scope of the cookie. They essentially tell the browser what website the cookie belongs to. For security reasons, cookies can only be set on the current resource's top ___domain and its subdomains, and not for another ___domain and its subdomains. For example, the website <code>example.org</code> cannot set a cookie that has a ___domain of <code>foo.com</code> because this would allow the website <code>example.org</code> to control the cookies of the ___domain <code>foo.com</code>.
If a cookie's <code>Domain</code> and <code>Path</code> attributes are not specified by the server, they default to the ___domain and path of the resource that was requested.<ref name="uMnRY">{{cite
Below is an example of some <code>Set-Cookie</code> header fields in the HTTP response of a website after a user logged in. The HTTP request was sent to a webpage within the <code>docs.foo.com</code> subdomain:
Line 168:
</syntaxhighlight>
The first cookie, <code>LSID</code>, has no <code>Domain</code> attribute, and has a <code>Path</code> attribute set to <code>/accounts</code>. This tells the browser to use the cookie only when requesting pages contained in <code>docs.foo.com/accounts</code> (the ___domain is derived from the request ___domain). The other two cookies, <code>HSID</code> and <code>SSID</code>, would be used when the browser requests any subdomain in <code>.foo.com</code> on any path (for example <code>www.foo.com/bar</code>). The prepending dot is optional in recent standards, but can be added for compatibility with RFC 2109 based implementations.<ref name="gxcF2">{{cite
====Expires and Max-Age====
The <code>Expires</code> attribute defines a specific date and time for when the browser should delete the cookie. The date and time are specified in the form <code>Wdy, DD Mon YYYY HH:MM:SS GMT</code>, or in the form <code>Wdy, DD Mon YY HH:MM:SS GMT</code> for values of YY where YY is greater than or equal to 0 and less than or equal to 69.<ref name="QKuwv">{{cite
Alternatively, the <code>Max-Age</code> attribute can be used to set the cookie's expiration as an interval of seconds in the future, relative to the time the browser received the cookie. Below is an example of three <code>Set-Cookie</code> header fields that were received from a website after a user logged in:
Line 190:
The <code>Secure</code> attribute is meant to keep cookie communication limited to encrypted transmission, directing browsers to use cookies only via [[HTTPS|secure/encrypted]] connections. However, if a web server sets a cookie with a secure attribute from a non-secure connection, the cookie can still be intercepted when it is sent to the user by [[man-in-the-middle attack]]s. Therefore, for maximum security, cookies with the Secure attribute should only be set over a secure connection.
The <code>HttpOnly</code> attribute directs browsers not to expose cookies through channels other than HTTP (and HTTPS) requests. This means that the cookie cannot be accessed via client-side scripting languages (notably [[JavaScript]]), and therefore cannot be stolen easily via [[cross-site scripting]] (a pervasive attack technique).<ref name="Symantec-2007-2nd-exec">{{cite
==Browser settings==
Line 223:
In 2002, the European Union launched the [[Directive on Privacy and Electronic Communications]] (e-Privacy Directive), a policy requiring end users' consent for the placement of cookies, and similar technologies for storing and accessing information on users' equipment.<ref name="JISC">{{cite web|title=EU Cookie Directive, Directive 2009/136/EC|url=http://www.jisclegal.ac.uk/ManageContent/ViewDetail/ID/1347/EU-Cookie-Directive--Directive-2009136EC.aspx|publisher=JISC Legal Information|access-date=31 October 2012|archive-url=https://web.archive.org/web/20121218093525/http://www.jisclegal.ac.uk/ManageContent/ViewDetail/ID/1347/EU-Cookie-Directive--Directive-2009136EC.aspx|archive-date=18 December 2012|url-status=live}}</ref><ref name="ICO reference">{{cite book|title=Privacy and Electronic Communications Regulations|year=2012|publisher=Information Commissioner's Office|url=http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/~/media/documents/library/Privacy_and_electronic/Practical_application/cookies_guidance_v3.ashx|access-date=2012-10-31|archive-url=https://web.archive.org/web/20121030103207/http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/~/media/documents/library/Privacy_and_electronic/Practical_application/cookies_guidance_v3.ashx|archive-date=2012-10-30|url-status=dead}}</ref> In particular, Article 5 Paragraph 3 mandates that storing technically unnecessary data on a user's computer can only be done if the user is provided information about how this data is used, and the user is given the possibility of denying this storage operation. The Directive does not require users to authorise or be provided notice of cookie usage that are functionally required for delivering a service they have requested, for example to retain settings, store log-in sessions, or remember what is in a user's shopping basket.<ref>{{Cite web|date=2021-01-01|title=Cookies and similar technologies|url=https://ico.org.uk/for-organisations/guide-to-pecr/cookies-and-similar-technologies/|access-date=2021-06-06|website=ico.org.uk|language=en}}</ref>
In 2009, the law was amended by Directive 2009/136/EC, which included a change to Article 5, Paragraph 3. Instead of having an option for users to opt out of cookie storage, the revised Directive requires consent to be obtained for cookie storage.<ref name="ICO reference" /> The definition of consent is cross-referenced to the definition in European data protection law, firstly the Data Protection Directive 1995 and subsequently the [[General Data Protection Regulation]] (GDPR). As the definition of consent was strengthened in the text of the GDPR, this had the effect of increasing the quality of consent required by those storing and accessing information such as cookies on users devices. In a case decided under the Data Protection Directive however, the [[Court of Justice of the European Union]] later confirmed however that the previous law implied the same strong quality of consent as the current instrument.<ref name="eur-lex.europa.eu">{{Cite web|title=EUR-Lex - 62017CN0673 - EN - EUR-Lex|url=https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:62017CN0673|access-date=2021-06-06|website=eur-lex.europa.eu}}</ref> In addition to the requirement of consent which stems from storing or accessing information on a user's terminal device, the information in many cookies will be considered personal data under the GDPR alone, and will require a legal basis to process. This has been the case since the 1995 Data Protection Directive, which used an identical definition of personal data, although the GDPR in interpretative Recital 30 clarifies that cookie identifiers are included. While not all data processing under the GDPR requires consent, the characteristics of behavioural advertising mean that it is difficult or impossible to justify under any other ground.<ref name="Veale">{{
Consent under the combination of the GDPR and e-Privacy Directive has to meet a number of conditions in relation to cookies.<ref name=":0">{{Cite journal|last1=Nouwens|first1=Midas|last2=Liccardi|first2=Ilaria|last3=Veale|first3=Michael|last4=Karger|first4=David|last5=Kagal|first5=Lalana|date=2020-04-21|title=Dark Patterns after the GDPR: Scraping Consent Pop-ups and Demonstrating their Influence|url=https://dl.acm.org/doi/10.1145/3313831.3376321|journal=Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems|series=Chi '20|language=en|___location=Honolulu HI USA|publisher=ACM|pages=1–13|doi=10.1145/3313831.3376321|arxiv=2001.02479|isbn=978-1-4503-6708-0|hdl=1721.1/129999|s2cid=210064317|hdl-access=free}}</ref> It must be freely given and unambiguous: preticked boxes were banned under both the Data Protection Directive 1995<ref name="eur-lex.europa.eu"/> and the GDPR (Recital 32).<ref name=":1">{{Cite web|title=EUR-Lex - 32016R0679 - EN - EUR-Lex|url=https://eur-lex.europa.eu/eli/reg/2016/679/oj|access-date=2021-06-06|website=eur-lex.europa.eu|language=en}}</ref> The GDPR is specific that consent must be as 'easy to withdraw as to give',<ref name=":1" /> meaning that a reject-all button must be as easy to access in terms of clicks and visibility as an 'accept all' button.<ref name=":0" /> It must be specific and informed, meaning that consent relates to particular purposes for the use of this data, and all organisations seeking to use this consent must be specifically named.<ref name=":2">{{Cite book|last=Information Commissioner's Office|url=https://cy.ico.org.uk/media/about-the-ico/documents/2615156/adtech-real-time-bidding-report-201906-dl191220.pdf|title=Update Report into Adtech and Real Time Bidding|year=2019}}</ref><ref>{{Cite web|url=https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038783337|access-date=2021-06-06|title=Délibération n° 2019-093 du 4 juillet 2019 portant adoption de lignes directrices relatives à l'application de l'article 82 de la loi du 6 janvier 1978 modifiée aux opérations de lecture ou écriture dans le terminal d'un utilisateur (notamment aux cookies et autres traceurs) (rectificatif)|website=www.legifrance.gouv.fr}}</ref> The [[Court of Justice of the European Union]] has also ruled that consent must be 'efficient and timely', meaning that it must be gained before cookies are laid and data processing begins instead of afterwards.<ref>{{Cite web|title=EUR-Lex - 62017CC0040 - EN - EUR-Lex|url=https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:62017CC0040|access-date=2021-06-06|website=eur-lex.europa.eu}}</ref>
Line 262:
If an attacker is able to cause a [[DNS server]] to cache a fabricated DNS entry (called [[DNS cache poisoning]]), then this could allow the attacker to gain access to a user's cookies. For example, an attacker could use DNS cache poisoning to create a fabricated DNS entry of <code>f12345.www.example.com</code> that points to the [[IP address]] of the attacker's server. The attacker can then post an image URL from his own server (for example, <code><nowiki>http://f12345.www.example.com/img_4_cookie.jpg</nowiki></code>). Victims reading the attacker's message would download this image from <code>f12345.www.example.com</code>. Since <code>f12345.www.example.com</code> is a sub-___domain of <code>www.example.com</code>, victims' browsers would submit all <code>example.com</code>-related cookies to the attacker's server.
If an attacker is able to accomplish this, it is usually the fault of the [[Internet Service Provider]]s for not properly securing their DNS servers. However, the severity of this attack can be lessened if the target website uses secure cookies. In this case, the attacker would have the extra challenge<ref name="certificatehack">{{cite web | last=Zetter | first=Kim | title=Hack Obtains 9 Bogus Certificates for Prominent Websites; Traced to Iran - Threat Level - Wired.com
===Cross-site scripting: cookie theft===
| |||