什么是浏览器Cookie？

Cookie是网站服务器在用户访问时发送给浏览器的文本文件，包含数据片段。浏览器将这些数据保存在设备上，并在后续向该网站发出的每个请求中将其发送回服务器。这是网站识别用户并使其体验更流畅的方式。

让我们仔细看看哪些数据最终会进入Cookie。

首先是关于用户在网站上的操作和会话参数的信息：点击、访问过的页面、在网站上停留的时间、语言、地区、添加到购物车的商品、个人资料设置（如主题）等。这还包括关于用户设备的数据：型号、操作系统和浏览器类型。

用户的登录凭据和安全令牌也会被收集，以识别身份并方便登录。尽管不建议将此类信息存储在Cookie中，但这种情况仍可能发生，例如当用户勾选"记住我"时。如果安全令牌被放置在JS脚本可访问的Cookie中，它们可能会变得易受攻击。

另一个重要的信息类型是存储在Cookie中的会话ID：这是用户访问网站时分配的唯一代码。这是会话劫持攻击的主要目标，因为它允许攻击者冒充用户。值得注意的是，会话ID可以存储在Cookie中，如果用户禁用了Cookie，它甚至可以直接写入页面的URL中。

除了上述信息，Cookie还可以保存一些主要的个人数据，例如电话号码、地址，甚至银行卡详细信息。它们还可能无意中存储用户在网站上输入的机密公司信息，包括客户详细信息、项目信息和内部文件。

这些数据类型中有许多被认为是敏感的。这意味着如果它们暴露给错误的人，可能会对用户或组织造成伤害。虽然像设备类型和访问过的页面之类的内容通常不被视为机密，但它们仍然创建了用户的详细档案。这些信息可能被攻击者用于网络钓鱼诈骗甚至勒索。

Cookie的主要类型

按存储时间分类

Cookie通常根据存储时间进行分类。主要有两种类型：临时性和持久性。

临时性或会话Cookie在访问网站期间使用，并在用户离开后立即删除。它们使用户无需在同一个站点的每个新页面上重新登录或重新选择语言和地区设置。在单个会话期间，这些值存储在Cookie中，因为它们确保对账户的无间断访问以及网站功能对注册用户的正常运行。此外，临时Cookie还包括诸如订单表单中的条目和访问过的页面等内容。如果用户选择"记住我的选择"或"保存设置"等选项，这些信息最终可能会进入持久性Cookie。值得注意的是，如果浏览器设置为自动恢复上一个会话（加载先前打开的标签页），会话Cookie将不会被删除。在这种情况下，系统将用户在该网站上的所有活动视为一个会话。

持久性Cookie与临时性Cookie不同，即使用户离开网站，它们也会保留下来。网站所有者为其设置过期日期，通常最多一年。但是，用户可以随时通过清除浏览器Cookie来删除它们。这些Cookie通常用于存储登录凭据、电话号码、地址或支付详细信息。它们也用于广告以确定用户的偏好。敏感的持久性Cookie通常具有特殊的HttpOnly属性。这可以防止浏览器访问其内容，因此数据在用户每次访问网站时直接发送到服务器。

值得注意的是，根据用户在网站上的操作，凭据可能存储在临时性或持久性Cookie中。例如，当用户仅浏览网站时，用户名和密码可能存储在会话Cookie中。但如果用户勾选"记住我"框，这些相同的详细信息将改为保存在持久性Cookie中。

按来源分类

根据来源，Cookie分为第一方和第三方。前者由网站创建和存储，后者由其他网站创建和存储。让我们仔细看看这些Cookie类型。

第一方Cookie通常用于使网站正常运行并将用户识别为用户。然而，它们也可以执行分析或营销功能。在这种情况下，它们通常被认为是可选的——除非其目的是在特定会话期间跟踪用户行为。

第三方Cookie由用户正在访问的网站与之通信的其他网站创建。这些Cookie最常见的用途是广告横幅。例如，在网站上放置横幅广告的公司可以使用第三方Cookie来跟踪用户行为：用户点击广告的次数等等。这些Cookie也被分析服务如Google Analytics或Yandex Metrica使用。

社交媒体Cookie是另一种属于此类的Cookie。这些由小部件和按钮设置，例如"分享"或"点赞"。它们处理与社交媒体平台的任何交互，因此它们可能存储用户的登录凭据和用户设置以使这些交互更快。

按重要性分类

另一种对Cookie进行分类的方法是将它们分为必需的和可选的。

必需或基本Cookie对于网站的基本功能或提供用户特别要求的服务是必要的。这包括在单次访问期间跟踪用户活动的临时Cookie。它还包括安全Cookie，例如网站用于识别用户和发现任何欺诈活动的身份验证Cookie。值得注意的是，存储用户同意保存Cookie的Cookie如果由网站所有者确定，也可能被视为必需，因为它们对于确保资源符合用户选择的隐私设置是必要的。

使用基本Cookie的需求主要适用于具有复杂结构和各种小部件的网站。想想需要一个购物车和支付系统的电子商务网站，或者必须将图像保存到用户设备的照片应用程序。

存储在必需Cookie中的一个关键数据是上述会话ID，它帮助网站识别用户。如果不允许此ID保存在Cookie中，一些网站会将其直接放在页面的URL中。这是一种风险更高的做法，因为URL未加密。它们对分析服务、跟踪工具甚至与用户在同一网络上的其他用户也是可见的，这使得它们容易受到跨站脚本（XSS）攻击。这是许多网站出于用户自身安全考虑而不允许用户禁用必需Cookie的一个主要原因。

可选Cookie是那些为营销、分析和性能目的跟踪用户在线行为的Cookie。此类包括由社交媒体平台创建的第三方Cookie，以及帮助网站运行更快并在服务器之间平衡负载的性能Cookie。例如，这些Cookie可以跟踪损坏的链接以提高网站的整体速度和可靠性。

本质上，大多数可选Cookie是对网站运行不关键的第三方Cookie。然而，此类也可能包括一些用于网站分析或收集用户偏好信息以向用户显示个性化内容的第一方Cookie。

虽然这些Cookie通常不以可读形式存储用户的个人信息，但它们收集的数据仍可被分析工具用于构建具有足够识别信息的详细用户档案。例如，通过分析用户访问的网站，公司可以对用户的年龄、健康状况、位置等进行有根据的猜测。

一个主要担忧是可选Cookie有时可以从自动填充表单中捕获敏感信息，例如姓名、家庭住址，甚至银行卡详细信息。这正是为什么许多网站现在让用户选择接受或拒绝收集这些数据。

特殊类型的Cookie

让我们也重点介绍通过两种类似技术管理的特殊子类型的Cookie，这些技术实现了非标准的存储和检索方法。

超级Cookie是一种跟踪技术，将Cookie嵌入网站头部并将其存储在非标准位置，例如HTML5本地存储、浏览器插件存储或浏览器缓存中。因为它们不在通常的位置，简单地清除浏览器的历史和Cookie无法摆脱它们。

超级Cookie用于个性化广告和收集关于用户的分析数据（例如，由互联网服务提供商收集）。从隐私角度来看，超级Cookie是一个主要担忧。它们是一种持久且难以控制的跟踪机制，可以在未经用户同意的情况下监控用户活动，这使得选择退出变得困难。

另一种不寻常的跟踪方法是Evercookie，一种僵尸Cookie。即使在删除后，Evercookie也可以通过JavaScript恢复。恢复过程依赖于唯一的用户标识符（如果可用），以及存储在所有可能的浏览器存储位置中的Cookie痕迹。

Cookie使用如何受到监管

Cookie的收集和管理受世界各地不同法律的约束。让我们回顾一下全球实践中的关键标准。

• 欧盟的《通用数据保护条例》（GDPR）和《电子隐私指令》（Cookie法）。根据欧盟法律，基本Cookie不需要用户同意。这为一些网站创造了一个漏洞。用户可能点击"拒绝所有"，但该按钮可能仅拒绝非基本Cookie，允许其他Cookie仍然被收集。
• 巴西的《个人数据保护通用法》（LGPD）。该法律规范巴西境内用户数据的收集、处理和保护。它在很大程度上受到GDPR原则的启发，并同样要求用户免费、明确和清晰地同意使用其个人数据。然而，LGPD将更广泛的信息归类为个人数据，包括生物识别和遗传数据。值得注意的是，遵守GDPR并不自动意味着遵守LGPD，反之亦然。
• 美国的《加州消费者隐私法案》（CCPA）。CCPA将Cookie视为个人信息的一种形式。这意味着它们的收集和存储必须遵循某些规则。例如，任何加州居民都有权停止跨站点Cookie跟踪，以防止其个人数据被出售。服务提供商必须让用户选择收集哪些数据以及如何使用这些数据。
• **英国的《隐私和电子通信条例》（PECR，或EC指令）**与Cookie法类似。PECR规定，网站在两种情况下才能在用户设备上保存信息：当这对于网站运行或提供服务绝对必要时，或者用户已明确同意此操作时。
• 俄罗斯的联邦法律第152-FZ号"关于个人数据"。该法律广义地将个人数据定义为任何直接或间接与个人相关的信息。由于Cookie可能属于此定义，因此它们可能受该法律监管。这意味着网站必须获得用户的明确同意才能处理其数据。

在俄罗斯，网站所有者必须告知用户技术Cookie的使用情况，但不需要获得收集此信息的同意。对于所有其他类型的Cookie，需要用户同意。通常，用户在首次访问网站时自动给予此同意，如默认Cookie警告中所述。

一些网站使用横幅或弹出窗口请求同意，有些甚至让用户选择他们愿意在设备上存储哪些Cookie。

除了这些法律，网站所有者还制定了使用第一方Cookie的自己的规则。同样，第三方Cookie由第三方服务（如Google Analytics）的所有者管理。这些方决定将何种信息放入Cookie以及其格式。他们还确定Cookie的生命周期和安全设置。为了理解这些设置为何如此重要，让我们看看恶意行为者可以攻击最关键类型的Cookie（包含会话ID的Cookie）的几种方式。

会话劫持方法

如上所述，包含会话ID的Cookie极其敏感。它们是网络犯罪分子的主要目标。在现实世界的攻击中，已经记录了不同的窃取会话ID的方法。这种做法被称为会话劫持。下面，我们将看几种会话劫持类型。

会话嗅探

窃取带有会话ID的Cookie的一种方法是会话嗅探，这涉及拦截用户和网站之间的流量。对于使用开放HTTP协议而不是加密流量的HTTPS的网站，这种威胁是一个担忧。使用HTTP时，Cookie在HTTP请求的头部中以纯文本形式传输，这使得它们容易被拦截。

针对未加密HTTP流量的攻击主要发生在公共Wi-Fi网络上，特别是那些没有密码和强安全协议如WPA2或WPA3的网络。这些协议使用AES加密来保护Wi-Fi网络上的流量，WPA3是目前最安全的版本。虽然WPA2/WPA3保护限制了拦截HTTP流量的能力，但只有实施HTTPS才能真正防止会话嗅探。

这种窃取会话ID Cookie的方法在今天相当罕见，因为大多数网站现在使用HTTPS加密。然而，这种攻击类型的流行是大规模转向在用户会话期间对所有连接使用HTTPS（称为HTTPS everywhere）的主要原因。

跨站脚本（XSS）

跨站脚本（XSS）利用网站代码中的漏洞将恶意脚本（通常用JavaScript编写）注入其网页。然后，每当受害者访问该站点时，此脚本就会运行。XSS攻击的工作原理如下：攻击者在目标网站的源代码中发现一个漏洞，允许他们注入恶意脚本。例如，该脚本可能隐藏在URL参数或页面评论中。当用户打开受感染的页面时，脚本在其浏览器中执行并获得对站点数据的访问权限，包括包含会话ID的Cookie。

会话固定

在会话固定攻击中，攻击者诱骗用户的浏览器使用预定的会话ID。因此，攻击者为在受害者访问网站并执行身份验证后拦截会话数据奠定了基础。

过程如下。攻击者访问一个网站并从服务器获取一个有效但未经身份验证的会话ID。然后他们诱骗用户使用该特定的会话ID。一种常见的方法是通过发送一个已经将会话ID嵌入URL的链接，像这样：http://example.com/?SESSIONID=ATTACKER_ID。当用户点击链接并登录时，网站将攻击者的会话ID与用户经过身份验证的会话关联起来。然后攻击者可以使用被劫持的会话ID接管用户的账户。

现代、配置良好的网站比类似XSS的攻击更不容易受到会话固定的影响，因为大多数当前的Web框架在用户登录后会自动更改用户的会话ID。然而，这种会话ID利用攻击的存在本身就凸显了网站安全地管理用户会话的整个生命周期（尤其是在登录时刻）是多么重要。

跨站请求伪造（CSRF）

与会话固定或嗅探攻击不同，跨站请求伪造（CSRF或XSRF）利用网站对用户浏览器的信任。攻击者在用户不知情的情况下，强制用户的浏览器在用户已登录的网站上执行不需要的操作——例如更改密码或删除数据。

对于这种类型的攻击，攻击者创建一个恶意网页或包含有害链接、HTML代码片段或脚本的电子邮件消息。此代码包含对易受攻击网站的请求。用户打开页面或电子邮件消息，用户的浏览器自动将隐藏的请求发送到目标站点。该请求包括恶意操作和该站点所有必要的（例如，临时的）Cookie。因为网站看到有效的Cookie，它将请求视为合法请求并执行它。

中间人（MitM）攻击的变体

中间人（MitM）攻击是指网络犯罪分子不仅窥探还将受害者的所有流量通过自己的系统重定向，从而获得读取和更改正在传输的数据的能力。这些攻击的例子包括DNS欺骗或创建看起来合法的虚假Wi-Fi热点。在MitM攻击中，攻击者成为用户和网站之间的中间人，这使他们能够拦截数据，例如包含会话ID的Cookie。

使用较旧HTTP协议的网站特别容易受到MitM攻击。然而，使用更安全的HTTPS协议的网站也并非完全安全。恶意行为者可能会尝试用假的SSL/TLS证书欺骗用户的浏览器。用户的浏览器旨在警告用户有关可疑的无效证书，但如果用户忽略该警告，攻击者可以解密其流量。网络犯罪分子还可以使用称为SSL剥离的技术强制用户的连接从HTTPS切换到HTTP。

可预测的会话ID

网络犯罪分子并不总是必须窃取用户的会话ID——有时他们可以猜出它。如果会话ID是根据具有弱的非加密字符的可预测模式创建的，他们就可以弄清楚用户的会话ID。例如，会话ID可能包含用户的IP地址或连续数字，并且可能使用使用容易预测的随机序列的弱算法来生成它。

为了执行这种类型的攻击，恶意行为者将收集足够数量的会话ID示例。他们分析模式以找出用于创建ID的算法，然后应用该知识来预测用户当前或下一个会话ID。

Cookie抛掷

这种攻击方法利用了浏览器对由单个域的子域设置的Cookie的处理。如果恶意行为者控制了一个子域，他们可以尝试操纵更高级别的Cookie，特别是会话ID。例如，如果为sub.domain.com设置了一个Cookie，其Domain属性设置为.domain.com，则该Cookie对整个域也有效。

这让攻击者可以"抛掷"他们自己的恶意Cookie，其名称与主域的Cookie（如Session_id）相同。当用户的浏览器向主服务器发送请求时，它会包含所有相关的Cookie。服务器可能会错误地处理黑客的会话ID，让他们访问用户的会话。即使用户自己从未访问过受感染的子域，这也可能有效。在某些情况下，发送无效的Cookie也可能导致服务器出错。

如何保护自己和用户

Cookie安全的主要责任在于网站开发人员。现代的现成Web框架通常提供内置防御，但每个开发人员都应了解Cookie配置的具体情况以及粗心方法的