第七章 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 字段

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

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

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

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

    Set-Cokkie: name=VALUE; secure

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

  • HttpOnly 属性 CookieHttpOnly 属性是 Cookie 的扩展功能,它使 JavaScript 脚本无法获得 Cookie 。其主要目的为防止跨站脚本攻击(Cross-sitescripting,XSS)对 Cookie 的信息窃取。 发送指定 HttpOnly 属性的 Cookie 的方法如下所示。

    Set-Cookie: name=value; HttpOnly

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

Cookie: status=enable

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

第二节 其他首部字段

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

  • X-Frame-Options

  • X-XSS-Protection

  • DNT

  • P3P

第一小节 X-Frame-Options 字段

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 字段

X-XSS-Protection: 1

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

  • 0:将 XSS 过滤设置成无效状态

  • 1:将 XSS 过滤设置成有效状态

第三小节 DNT 字段

DNT: 1

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

  • 0:同意被追踪

  • 1:拒绝被追踪

    由于首部字段 DNT 的功能具备有效性,所以 web 服务器需要对 DNT 做出对应的支持。

第四小节 P3P字段

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

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

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

  • 步骤一:创建 P3P 隐私

  • 步骤二:创建 P3P 隐私对照文件后,保存命名在 /w3c/p3p.xml

  • 步骤三:从 P3P 隐私中新建 Compact policies 后,输出到 HTTP 响应中

关于 P3P 的详细规范请查看下面链接。 https://www.w3.org/TR/P3P/

作者:肖鹏-SpiritLing 时间:2019-01-30