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

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

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

        查看某个网站颁发的Cookie很简单。在浏览器地址栏输入“javascript:alert (document. cookie)”就可以了（需要有网才能查看）。JavaScript脚本会弹出一个对话框显示本网站颁发的所有Cookie的内容，如下图所示。
🦴🗼🦞©🦌‏

        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的使用可能反而有弊无利。