第七章 为 Cookie 服务和其他首部字段

作者：肖鹏-SpiritLing 时间：2019-01-30包含 为 Cookie 服务的首部字段和其他首部字段

第一节 为 Cookie 服务的首部字段

管理服务器与客户端之间状态的 Cookie ，虽然没有被编入标准化 HTTP/1.1 的 RFC2616 中，但在 Web 网站方面得到广泛的应用。Cookie 的工作机制是用户识别及状态管理。web 网站为了管理用户的状态会通过 web 游览器，把一些数据临时写入用户的计算机内。接着当用户访问该 web 网站时，可通过通信方式取回之前存放的 Cookie 。调用 Cookie 时，由于可校验 Cookie 的有效期，以及发送方的域、路径、协议等信息，所以正规发布的 Cookie 内的数据不会因来自其他 web 站点和攻击者的攻击而泄露。在目前使用最广泛的 Cookie 标准却不是 RFC 中定义的任何一个。而是在网景公司指定的标准上进行扩展后的产物。下面是与 Cookie 有关的首部字段

首部字段名 说明 首部类型
Set-Cookie 开始状态管理所使用的 Cookie 信息 响应首部字段
Cookie 服务器接收到的 Cookie 信息 请求首部字段

第一小节 Set-Cookie 字段

  1. Set-Cookie: status-enable; expires=Tue, 05 Jul 2018 02:01:22 GMT; path=/; domain=.example.com;

复制

当服务器准备开始管理客户端的状态时，会事先告知各种信息。下面表格列举了 Set-Cookie 的字段值。

属性 说明
NAME=VALUE 赋予 Cookie 的名称和其值（必须项）
expires=DATE Cookie 的有效期（若不明确指定则默认为游览器关闭前为止）
path=PATH 将服务器上的文件目录作为 Cookie 的适用对象（若不指定则默认文档所在的文件目录）
domain=域名 作为 Cookie 适用对象的域名（若不指定则默认为创建 Cookie 的服务器域名）
Secure 仅在 HTTPS 安全通信时才会发送 Cookie
HttpOnly 加以限制，使 Cookie 不能被 JavaScript 脚本访问

  • expires 属性Cookie 的 expires 属性指定游览器可发送 Cookie 的有效期。当省略 expires 属性时，其有效期仅限于维持游览器会话（Session）时间段内。这通常限于游览器应用程序被关闭之前。另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显示删除 Cookie 的方法。但可以通过覆盖已过期的 Cookie ，实现对客户端 Cookie 的实质性删除操作。

  • path 属性Cookie 的 path 属性可用于限制指定 Cookie 的发送范围的文件目录。不过另有办法避开这项限制，看来对其作为安全机制的效果不能报有期待。

  • domain 属性通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。比如，当指定 example.com 后，除 example.com 以外，www.example.com 或 www2.example.com 等都可以发送 Cookie 。因此，除了针对具体指定的多个域发送 Cookie 之外，不指定 domain 属性显得更安全。

  • secure 属性Cookie 的 secure 属性用于限制 web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie 。发送 Cookie 时，指定 secure 属性的方法如下所示。

  1. Set-Cokkie: name=VALUE; secure

复制

以上例子仅当在 https://www……..（HTTPS）安全连接的情况下才会进行 Cookie 的回收，也就是说，即使域名相同，http://www……（HTTP）也不会发生 Cookie 的回收行为。当省略 secure 属性时，不论 HTTP 还是 HTTPS ，都会对 Cookie 进行回收。

  • HttpOnly 属性Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie 。其主要目的为防止跨站脚本攻击（Cross-sitescripting，XSS）对 Cookie 的信息窃取。发送指定 HttpOnly 属性的 Cookie 的方法如下所示。
  1. Set-Cookie: name=value; HttpOnly

复制

通过上述设置，通常从 web 页面内还可以对 Cookie 进行读取操作。但使用 JavaScript 的 document.cookie 就无法读取附加 HttpOnly 属性后的 Cookie 的内容了。因此，也就无法在 XSS 中利用 JavaScript 劫持 Cookie 了。虽然是独立的扩展功能，但 Internet Explorer 6 SP1 以上版本等当下的主流游览器都已经支持该扩展了。另外顺带一提，该扩展并非是为了防止 XSS 而开发的。

第二小节 Cookie 字段

  1. Cookie: status=enable

复制

首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支持时，就会在请求中包含从服务器接受到的 Cookie 。接受到多个 Cookie 时，同样可以以多个 Cookie 形式发送。

第二节 其他首部字段

HTTP 首部字段是可以自行扩展的。所以在 Web 服务器和游览器的应用上，会出现各种非标准的首部字段。下面是一些比较常用的首部字段/

  • X-Frame-Options
  • X-XSS-Protection
  • DNT
  • P3P

第一小节 X-Frame-Options 字段

  1. X-Frame-Options: DENY

复制

首部字段 X-Frame-Options 属于 HTTP 响应首部，用于控制网站内容在其他 web 网站的 Frame 标签内显示问题。其主要目的是为了防止点击劫持（clickjacking）攻击。首部字段 X-Frame-Options 有以下两个可指定的字段值。

  • DENY拒绝
  • SAMEORIGIN仅同源域名下的页面（Top-level-browsing-context）匹配时许可。
    支持该首部字段的游览器有：Internet Explorer 8、Firefox 3.6.9+、Chrome 4.1.249.1042+、Safari 4+ 和 Opera 10.50+ 等。现在主流的游览器都已经支持。能在所有的 web 服务端预先设定好 X-Frame-Options 字段值是最理想的状态。当然版本不支持的以及其不放心时可以参考这篇文章

第二小节 X-XSS-Protection 字段

  1. X-XSS-Protection: 1

复制

首部字段 X-XSS-Protection 属于 HTTP 响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制游览器 XSS 防护机制的开关。首部字段 X-XSS-Protection 可指定的字段值如下：

  • 0：将 XSS 过滤设置成无效状态
  • 1：将 XSS 过滤设置成有效状态

第三小节 DNT 字段

  1. DNT: 1

复制

首部字段 DNT 属于HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝个人信息被手机，是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值如下。

  • 0：同意被追踪
  • 1：拒绝被追踪由于首部字段 DNT 的功能具备有效性，所以 web 服务器需要对 DNT 做出对应的支持。

第四小节 P3P字段

  1. P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND UNI COM NAV INT"

复制

首部字段 P3P 属于HTTP响应首部，通过利用P3P ( The Platformfor Privacy Preferences,在线隐私偏好平台)技术，可以让Web网站上的个人隐私变成种仅供程序可理解的形式， 以达到保护用户隐私的目的。

要进行 P3P的设定，需按以下步骤进行。

  • 步骤一：创建 P3P 隐私
  • 步骤二：创建 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml
  • 步骤三：从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应中
    关于 P3P 的详细规范请查看下面链接。https://www.w3.org/TR/P3P/
作者：肖鹏-SpiritLing 时间：2019-01-30

原文: http://http.kancloud.spiritling.cn/935040