Cookie 究竟指的是什么？

Cookie，有时会使用其复数形式

Cookies

。它属于“小型文本文件”这一类型，是某些网站为了辨别用户身份、进行 Session 跟踪，而储存在用户本地终端上的数据（通常会经过加密处理），是由用户客户端计算机暂时或者永久保存的信息。

简介

Cookie 并非其原本“甜饼”的意思，而是保存在客户机中的一个简单文本文件。此文件与特定的 Web 文档相关联，保存着该客户机访问这个 Web 文档时的相关信息。当客户机再次访问该 Web 文档时，这些信息可供文档使用。鉴于“Cookie”能够保存在客户机上这一神奇特性，它能够帮助我们实现记录用户个人信息的功能，并且无需使用复杂的 CGI 等程序。

举例来讲，一个 Web 站点可能会为每一位访问者生成一个独一无二的 ID，然后以 Cookie 文件的形式保存在每个用户的机器里。倘若使用浏览器访问 Web，就能看到所有存于硬盘上的 Cookie。在这个文件夹中，每一个文件都是由“名/值”对组成的文本文件，另外还有一个文件保存着所有对应的 Web 站点的信息。这里的每个 Cookie 文件都是一个简单且普通的文本文件。通过文件名，就能知晓是哪个 Web 站点在机器上放置了 Cookie（当然，站点信息在文件中也有保存）。

组成

Cookie 是一段不超过 4KB 的小型文本数据，由一个名称（Name）、一个值（Value）以及其他几个用于控制 Cookie 有效期、安全性、使用范围的可选属性共同构成。其中：

(1)Name/Value：用于设置 Cookie 的名称以及相对应的值，对于认证 Cookie 来说，Value 值涵盖了 Web 服务器所提供的访问令牌。

(2)Expires 属性：用于设定 Cookie 的生存期。Cookie 存在两种存储类型：会话性和持久性。当 Expires 属性缺失时，为会话性 Cookie，仅保存在客户端内存中，并在用户关闭浏览器时失效；持久性 Cookie 会保存在用户的硬盘中，直至生存期结束或者用户直接在网页中点击“注销”等按钮结束会话时才会失效。

(3)Path 属性：明确了 Web 站点上能够访问该 Cookie 的目录。

(4)Domain 属性：指定了能够访问该 Cookie 的 Web 站点或域。Cookie 机制并未严格遵循同源策略，允许子域设置或获取父域的 Cookie。当需要实现单点登录方案时，Cookie 的上述特性极为有用，然而也增大了 Cookie 遭受攻击的风险，比如攻击者能够借此发起会话定置攻击。所以，浏览器禁止在 Domain 属性中设置.org、.com 等通用顶级域名以及在国家及地区顶级域下注册的二级域名，以缩小攻击的范围。

(5)Secure 属性：指明是否运用 HTTPS 安全协议发送 Cookie。使用 HTTPS 安全协议，能够保障 Cookie 在浏览器和 Web 服务器间的传输过程中不被窃取和篡改。该方法也可用于 Web 站点的身份鉴别，即在 HTTPS 的连接建立阶段，浏览器会检查 Web 网站的 SSL 证书的有效性。但是出于兼容性的原因（比如有些网站使用自签署的证书），在检测到 SSL 证书无效时，浏览器不会立刻终止用户的连接请求，而是显示安全风险信息，用户仍能够选择继续访问该站点。由于许多用户缺乏安全意识，因而仍可能连接到 Pharming 攻击所伪造的网站。

(6)HTTPOnly 属性：用于防止客户端脚本通过 document.cookie 属性访问 Cookie，有助于保护 Cookie 不被跨站脚本攻击窃取或篡改。不过，HTTPOnly 的应用存在一定局限性，一些浏览器能够阻止客户端脚本对 Cookie 的读操作，但允许写操作；此外，大多数浏览器仍允许通过 XMLHTTP 对象读取 HTTP 响应中的 Set-Cookie 头。

安全威胁

Cookie 捕获/重放

攻击者能够通过木马等恶意程序，或者运用跨站脚本攻击等手段窃取存放在用户硬盘或内存中的 Cookie。借助网络攻击手段，包括在不安全的局域网中被动监听网络通信；通过攻击网络用户的路由器，或者搭建恶意的无线路由器等方式，控制路由基础设施，将网络流量重定向至攻击者控制的主机；发动 DNSPharming（域欺骗）攻击，通过 DNS 缓存中毒、DNS 应答欺骗、或者修改用户端的本地域名解析文件等方法攻击 DNS 系统，导致用户对合法网站的访问请求被重定向到恶意网站等等，同样有可能窃取 Cookie。对于捕获到的认证 Cookie，攻击者往往会猜测其中的访问令牌，试图获取会话 ID、用户名与口令、用户角色、时间戳等敏感信息；或者直接重放该 Cookie，假冒受害者的身份发起攻击。

恶意 Cookies

Cookies 属于文本文件，通常认为其不会构成安全威胁。然而，如果在 Cookies 中通过特殊标记语言引入可执行代码，就很可能给用户带来严重的安全隐患。HTML 为区分普通文本和标记语言，使用符号“<>”来指示 HTML 代码。这些 HTML 代码要么定义 Web 网页的格式，要么引入 Web 浏览器可执行的代码段。Web 服务器能够利用 Cookies 信息创建动态网页。倘若 Cookies 包含可执行的恶意代码段，那么在显示合成有该 Cookies 的网页时，就会自动执行这段恶意代码。当然，恶意代码能否真正造成危害，还取决于 Web 站点的安全配置策略。

会话定置

会话定置（Session Fixation）攻击指的是，攻击者向受害者主机注入自己控制的认证 Cookie 等信息，使得受害者以攻击者的身份登录网站，进而窃取受害者的会话信息。注入 Cookie 的方法包括：使用跨站脚本或木马等恶意程序；或者伪造与合法网站同域的站点，并利用各种手段欺骗用户访问该仿冒网站，从而通过 HTTP 响应中的 Set-Cookie 头将攻击者拥有的该域 Cookie 发送给用户等。

CSRF 攻击

跨站请求伪造（Cross-Site Request Forgery，简称 CSRF）是指，攻击者可能利用网页中的恶意代码迫使受害者浏览器向被攻击的 Web 站点发送伪造的请求，篡夺受害者的认证 Cookie 等身份信息，从而假冒受害者对目标站点执行指定的操作。Firefox、Opera 等浏览器采用单进程机制，多个窗口或标签使用同一个进程，共享 Cookie 等会话数据。IE 则混合使用单进程与多进程模式，一个窗口中的多个标签，以及使用“CTRL+N”或单击网页中的链接打开的新窗口使用同一进程，共享会话数据；只有直接运行 IE 可执行程序打开窗口时，才会创建新的进程。Chrome 虽然运用多进程机制，然而经测试发现，其不同的窗口或标签之间仍会共享会话数据，除非使用隐身访问方式。因此，用户同时打开多个浏览器窗口或标签访问互联网资源时，就为 CSRF 攻击篡夺用户的会话 Cookie 创造了条件。另外，如果一个 Web 站点提供持久化 Cookie，则 CSRF 攻击将更直接、更轻易。

安全防护

Web 服务器端防护

通过 Cookie 在客户端与服务器端进行交互，最终实现对用户身份的认证，Cookie 成为了用户整个身份的替代，其安全性决定了整个系统的安全性，Cookie 的安全性问题主要包含以下几个方面：（1）Cookie 被用户非法篡改，比如篡改其中的 expire 项，能够将 Cookie 的有效期延长；篡改 path 项可使用户能够访问服务器上未被授权的内容；或者修改 domain 项，使用户能够访问未被授权的服务器从而获取合法用户的信息等；（2）被非法用户非法截获，然后在有效期内重放，则非法用户将享有合法用户的合法权益，可能会损害网站方的利益；（3）若 Cookie 被服务器加密，而非法用户通过强力攻击或其他手段获取了相应的加密密钥，则非法用户能够伪造任何合法 Cookie，从而能够访问合法用户的所有个性化信息，甚至是账户信息等。

面对诸如此类的攻击手段，有必要从服务器端对 Cookie 进行安全设计，保护措施主要有：（1）添加 MAC 以进行完整性校验；（2）防止非法用户非法截获后的重放，可以让用户对相关信息进行数字签名，加强有效性验证；（3）对 Cookie 本身进行随机密钥加密，保障 Cookie 本身的信息安全。

客户端浏览器防护

客户端浏览器为保障本地的 Cookie 安全，对不同访问网站的统一 Cookie 进行加密，在相应的系统目录下，只能看到一个与 Cookie 相关的加密文件，而且其中的 Cookie 文件，已被浏览器加密，用户不可见，在用户访问特定站点时，可由浏览器对 cookies 文件进行调用并解密，将特定站点的 Cookie 发送到指定的站点服务器中，实现对用户的 Cookie 的认证。

主机的安全防护

在原有的服务器端以及客户端对 Cookie 的安全性控制基础上，鉴于不同的客户端浏览器对站点的 Cookie 控制相互独立，可以采取在客户端浏览器对产生的 Cookie 文件进行基于主机特征的安全性认证，即在浏览器产生 Cookie 加密文件时，在 Cookie 文件中添加一段主机的特征，生成一个双层加密的新 Cookie 文件；在调用 Cookie 的时候，通过对 Cookie 文件进行主机特征的匹配，选择对内层的文件进行解密调用。

然后，对嵌套了主机序列号的内层密文进行二次加密；内层加密确保对源 Cookie 内容的加密，保证 Cookie 信息不可见，外层加密保障对主机特征的保护，以避免主机特征被替换，通过对 Cookie 加入主机特征，以及两次对 Cookie 加密，能够在原有的防护机制下，为 Cookie 提供更为安全的保护。

认证机制

在 Web 认证中，由于 HTTP 协议本身存在局限性，必须采用其他技术将相关认证标记以某种方式持续传送，以免客户从一个页面跳转到另一个页面时重新输入认证信息[5]。基于 Cookie 的认证过程，主要由以下三个阶段构成：

（1）发布 Cookie。当用户试图访问某 Web 站点中需要认证的资源时，Web 服务器会检查用户是否提供了认证 Cookie，如果没有，则将用户重定向到登录页面。在用户成功登录后，Web 服务器会生成认证 Cookie，并通过 HTTP 响应中的 Set-Cookie 头发送给客户端，用于对用户随后的请求进行检查和验证，接着将用户重定向到初始请求的资源。

（2）检索 Cookie。在用户随后的访问请求中，客户端浏览器检索 Path 和 Domain 等属性与用户请求资源相匹配的 Cookie，并将找到的 Cookie 通过 HTTP 请求中的 Cookie 头提交给 Web 服务器。

（3）验证 CookieWeb 服务器提取客户端浏览器递交的 Cookie，验证其中的访问令牌。若合法，则将访问请求的资源发送给客户端浏览器；反之则拒绝用户的访问请求。Cookie 认证技术简化了用户访问 Web 网站资源的流程，即用户只需在初次登录网站时输入身份信息进行认证，随后便能够访问被授权的所有站点资源，不再需要重复手工提交身份信息[5]。

实例

因为 Cookies 是我们浏览的网站传输到用户计算机硬盘中的文本文件或内存中的数据，所以它在硬盘中存放的位置与所使用的操作系统和浏览器紧密相关。在 Windows 9X 系统的计算机中，Cookies 文件的存放位置是 C:\Windows\Cookies，在 Windows NT/2000/XP 的计算机中，Cookies 文件的存放位置是 C:\Documentsand Settings\用户名\Cookies。硬盘中的 Cookies 文件能够被 Web 浏览器读取，它的命令格式为：用户名@网站地址[数字].txt。需要注意的是：硬盘中的 Cookies 属于文本文件，并非程序。

设置

能够在 IE 的“工具/Internet 选项”的“常规”选项卡中，选择“设置/查看文件”，查看所有保存到电脑里的 Cookies。这些文件通常是以 user@domain 格式命名的，user 是本地用户名，domain 是所访问的网站的域名。如果使用 NetsCape 浏览器，则存放在“C:\PROGRAMFILES\NETSCAPE\USERS\”里面，与 IE 不同的是，NETSCAPE 是使用一个 Cookie 文件记录所有网站的 Cookies。可以对 Cookie 进行适当设置：打开“工具/Internet 选项”中的“隐私”选项卡（注意该设置仅在 IE6.0 中存在，其他版本 IE 可以单击“工具/Internet 选项”|“安全”标签中的“自定义级别”按钮，进行简单调整），调整 Cookie 的安全级别。通常情况下，可以调整到“中高”或者“高”的位置。多数的论坛站点需要使用 Cookie 信息，如果从来不去这些地方，可以将安全级调到“阻止所有 Cookies”；如果只是为了禁止个别网站的 Cookie，可以单击“编辑”按钮，将要屏蔽的网站添加到列表中。在“高级”按钮选项中，可以对第一方 Cookie 和第三方的 Cookie 进行设置，第一方 Cookie 是正在浏览的网站的 Cookie，第三方 Cookie 是非正在浏览的网站发送的 Cookie ，通常要对第三方 Cookie 选择“拒绝”。如果需要保存 Cookie，可以使用 IE 的“导入导出”功能，打开“文件/导入导出”，按照提示进行操作即可。

写入与读取

Cookies 集合隶属于 Response 对象及 Request 对象的数据集合，使用时需要在前面加上 Response 或 Request。用于给客户机发送 Cookies 的语法通常为：

1

<%Response.cookies(“Cookies 名称”)=数据%>

当为不存在的 Cookies 集合进行设置时，就会在客户机创建，如果该 Cookies 已存在，则会被替代。由于 Cookies 是作为 HTTP 传输的头信息的一部分发送给客户机的，所以向客户机发送 Cookies 的代码通常放在发送给浏览器的 HTML 文件的标记之前。如果用户要读取 Cookies，则必须使用 Request 对象的 Cookies 集合，其使用方法是：

1

<%efg=request.cookies(“abc”) (将 cookies 对象 abc 的值赋给 efg)%>

需要注意的是，只有在服务器未向浏览器下载任何数据前，浏览器才能与 Server 进行 Cookies 集合的数据交换，一旦浏览器开始接收 Server 所下载的数据，Cookies 的数据交换就会停止，为了避免错误，要在程序开头加上 response.Buffer=True