廉价的自尊、粗劣的傲气,无论哪个后生小辈都很重视这些东西。 收藏本站
登陆 / 注册 搜索

阅读:1.1万   回复: 2

WEB安全第五课 HTTP协议 之六 Cookie语义

[复制链接]
小执念 古黑浩劫论坛大牛 2016-5-29 20:03 |显示全部楼层

可遇不可求的事:故乡的云,上古的玉,随手的诗,十九岁的你。

管理员
        HTTP Cookie不属于RFC2616的内容,但它们是Web最重要的协议扩展之一。Cookie机制的使用过程首先是由服务器端返回一个Set-Cookie响应头,把一组组短小而不透明的“名称=值”格式的数据保存到浏览器端,在客户端再次提交请求时,会把之前保存下来的Cookie参数再返回给服务器端,服务器就可以重新再取回这些信息了。

        Cookie是到目前为止,保持会话和用户授权请求的最常用方式,它是Web环境里4种正统的全局授权认证方式(Ambient authoritye)@之一(另外几种内置的授权方式包括:HTTP验证授权、IP检查和客户端证书)。

        查看某个网站颁发的Cookie很简单。在浏览器地址栏输入“javascript:alert (document. cookie)”就可以了(需要有网才能查看)。JavaScript脚本会弹出一个对话框显示本网站颁发的所有Cookie的内容,如下图所示。🧑‍🎤‏👒🖌😷👏

WEB安全第五课 HTTP协议 之六 Cookie语义 QQ截图20160529195424.png

        Cookie机制最开始是1994年由Lou Montulli在Netscape浏览器里实现的,他简要地在一份4页纸的草案里描述了这一机制。而在过去17年里,竟然就一直没有一份恰当描述这套机制的标准文档。在1997年,RFC2109尝试着勾画了当时的Cookie现状,但又显得有点含糊不清,它还提议了若干彻底的修改,但这些提议又和现在用的任意一款浏览器的实际表现都不符。

        而另一项野心勃勃的尝试——Cookie2,出现在RFC2965里,但10年过去了,实际上还没有任何一款浏览器支持它,这种情况现在看来也不会有啥变化。一份对Cookie进行了较为准确描述的规范性文档就是RFC6265,在本书原版付印之前刚刚完成,终于一扫这场关于Cookie规范的迷雾。👩‍🩰🪗🤖💅
        
        由于长期以来缺乏真正的标准,所以对Cookie的各种具体实现也非常有意思,有时候甚至彼此不兼容。根本上来说,一个新的Cookie是通过Set-Cookie响应头进行设置,后面跟着一串“名字=域值”格式的数据对,和若干以分号分开的可选参数,这些参数用于定义Cookie的范围和生命周期,关于这些参数的解释如下:
        
        Expires 设定Cookie过期的时间,格式与Date或Expires响应头里的相类似。如果Cookie产生时没有设定过期时间,这意味着Cookie将在浏览器的整个会话期间内都有效(尤其是如果便携式计算机上有“挂起”功能时,Cookie的存活可能会持续数周之久)。定义了过期时间的Cookie被存放在硬盘上,所以在不同的会话之间仍然能保持,除非用户的隐私设置里明确地禁止了这种用法。
        
👌🗺🥑🔞🦄‏        Max-age 这是另一种RFC建议的过期时间设定,但由于IE浏览器不支持这种用法,所以实际上不会碰到。
        
        Domain 如果希望Cookie的有效范围,超出当前返回Set-Cookie响应头的那个主机头名范围,则需要设置该参数。关于Cookie有效范围的精确规则运用以及相关的安全问题,我们将在第9章里再详加讨论。
        
        注意:与RFC2109里的规定不同,其实不能用这个参数来设定Cookie只在某个主机名范围内有效。例如,如果设置了domain=example.com,其实也会匹配到www.example.com的二级域名范围。只有完全不设置Domain项,才是使得Cookie只在当前主机名范围内有效的唯一方法,但即使这样,在IE浏览器里也仍然会有一些出人意料的问题。

👎⛄🥚🅰🐠‌

        
        Path 允许Cookie在特定的请求路径内有效。但这并不是一个可靠的安全机制,原因会在后面的帖子解释,但因为它的简便易用可以考虑釆纳这种设置,它可以避免完全同名的Cookie在应用的不同部分产生冲突。
        
        Secure属性 禁止以非加密传输方式来使用Cookie。
        🧓‏👗🧬🥱👃
        HttpOnly属性 禁止通过JavaScript的document.cookieAPI方式来读取Cookie。该可选项原本是微软的一个扩展,但现在所有的主流浏览器都支持这一特性。
        
        如果当前访问的域名在浏览器的Cookie池中有对应的Cookie数据,浏览器就会把所有适用于这个域名的Cookie,按照“名称=值”的数据对格式,中间用分号分隔拼接在一起,无需再带其他的元数据,组合成一行请求头返回给服务器端。如果在特定的请求里,需要发送给服务器的Cookie太多了,已经超出服务器允许的头域长度限制,那该次请求可能会失败;除了手工清除Cookie池里的内容,也别无其他办法。
        
        让人觉得有意思的是,对服务器来说并没有什么显式的方法来删除不需要的Cookie。然而,由于每个Cookie都是独一无二地通过“名称-域名-路径”(name-domain-path)这三个基本要素确定的(Secure和Httponly属性会被忽略),所以可以用这个方法来覆盖特定范围内一个老的Cookie值。更进一步来说,如果新Cookie设置的到期时间(Expires)比当前实际时间要早,那这个Cookie就会被剔除掉,这倒是一种有效但有点绕的删除Cookie数据的办法。👦‎👠🦯😔🤛
        
        尽管RFC2109规定要接受由逗号分隔的设置在同一个Set-Cookie响应头里的多个Cookie,但这种做法非常危险,所有的浏览器都不再支持这种方式了。Firefox允许通过document.cookieJavaScriptAPI—次性地设置多个Cookie,但是这种方法很绕,需要用换行来做分隔符。没有一个浏览器接受以逗号作为Cookie的分隔符,而在服务器端接受这种格式的Cookie也是不安全的。
        
        另一个与规范有重大差异的地方是,在HTTP规范里,Cookie的值应该使用Quoted-string的格式,但实际上只有Firefox和Opera才接受这种格式。因此完全依赖于Quoted-String的处理,以及在攻击者控制的Cookie里允许出现单个的引号,都是很不安全的做法。
        👴‍👑🧯🤡🖐
        当然Cookie本身就不是特别可靠。所以有些客户端程序可以强制使用较为保守的用户配置策略,限定每个域名所允许的Cookie数量和大小,这样甚至可以限制Cookie的生命周期,但这类隐私保护措施都是被误导的结果。因为有别的方式能同样可靠地追踪用户的操作,比如上一章节里提到的ETag/If-None-Match,所以限制Cookie的使用可能反而有弊无利。

WEB安全第五课第七节:HTTP协议 之七 HTTP认证

上一篇
下一篇
帖子热度 1.1万 ℃

初晓微芒 「出类拔萃」 2018-5-3 08:24 |显示全部楼层

这个用户很懒,还没有填写自我介绍呢~

前排支持下了哦~
耀眼的阳光 「出类拔萃」 2018-5-7 09:32 |显示全部楼层

这个用户很懒,还没有填写自我介绍呢~

very good!
您需要登录后才可以回帖 登录 | 免费注册  

本版积分规则

快速回复 返回列表