HTTP首部二-HTTP(六)

为Cookie服务的首部字段

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

Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;

当服务器准备开始管理客户端的状态时,会事先告知各种信息。
下面表格列举了Set-Cookie的字段值。
HTTP首部二-HTTP(六)_第2张图片

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属性的方法如下所示。

Set-Cookie: name=value; secure

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

HttpOnly属性

Cookie的HttpOnly属性是Cookie的扩展功能,它使JavaScript脚本无法获得Cookie。其主要目的为防止跨站脚本攻击(Cross-Site-Scripting,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

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)匹配时许可。(比如,当指定http://hackr.jp/sample.html页面为SAMEORIGN时,那么hackr.jp上所有页面的frame都被允许可加载该页面,而example.com等其他域名的页面就不行了)。
    现在主流的浏览器都已经支持该首部字段。
    能在所有的Web服务器端预先设定好X-Frame-Options字段值是最理想的状态。
    对apache2.conf的配置实例
<IfModule mod_headers.c>
  Header append X-FRAME-OPTIONS "SAMEORIGIN"
IfModule>

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请求首部,其中DNT是Do 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的设定,需按以下操作步骤进行。
步骤1:创建P3P隐私。
步骤2:创建P3P隐私对照文件后,保存命名在/w3c/p3p.xml。
步骤3:从P3P隐私中新建Compact policies(压缩策略)后,输出到HTTP响应中。

协议中对X- 前缀的废除
在HTTP等多种协议中,通过给非标准参数加上前缀X-,来区别于标准参数,并使那些非标准的参数作为扩展变成可能。但是这种简单粗暴的做法有百害而无一益,因此在"RFC 6648 - Deprecating the “X-” Prefix and Similar Constructs in Application Protocols"中提议停止该做法。
然而,对已经在使用的X-前缀来说,不应该要求其变更。

参考

图解HTTP六:HTTP 首部
【图解HTTP读书笔记】第六章:HTTP首部

你可能感兴趣的