Cookie安全性分析

浅谈cookie安全性

 

摘要

HTTP State Management Mechanism（HTTP状态管理机制）一文中，定义了HTTP Cookie和Set-Cookie头字段。HTTP服务器利用这种头字段，在HTTP用户代理（浏览器）中存储当前状态，使得在大多数无状态的HTTP协议下，服务器可以维持一个有状态的回话。虽然，在安全性和隐私性上，cookie有许多历史性的不合理处，但是cookie和Set-Cookie头字段仍广泛用在网络中。

本文将结合具体案例“qqun_sql_step”讨论cookie在连续会话中的应用，同时，将从私密性和安全性两方面来讨论Cookie的安全特性。分析第三方Cookies，生存周期，明文存储，客户端存储带来的安全问题，着重讨论了几种常见的利用cookie的攻击方式，并在最后对cookie可能存在的每个安全漏洞提出几条建议与注意事项，以降低安全风险。

 

• 什么是cookie

HTTP State Management Mechanism（HTTP状态管理机制）中定义了HTTP Cookie和Set-Cookie头字段。利用Set-Cookie头字段，HTTP服务器可以向用户代理传输名值对（name/value pair）和关联的元数据（称为cookie）。当用户代理向服务器发送接下来的请求时，用户代理根据元素数据和其他信息来决定是否在Cookie头中返回名值对。一个回话建立过程如图1所示：

图 1 cookie的使用

尽管在表面上很简单，cookie有许多复杂特点。例如，服务器在每个cookie发送至用户代理时，会为其指定范围。这个范围包括，用户代理应当返回cookie的最长时间，用户代理应当返回cookie的服务器，以及cookie实用的URI设计。

基于历史性的原因，cookie包含许多安全和隐私上的不合理处。例如，服务器默认一个提交的cookie是“安全”连接的，但是，在活跃的网络攻击者出现时，并没有安全属性来提供完整性保障。同样的，尽管浏览器通常使用的同源策略（same-origin policy）隔离了不同端口的检索内容，cookie对于其提交主机来说，是在所有端口上共享的。

 

• cookie在有状态会话中的应用

Cookie通常存储在客户端，针对一个服务器的cookie文件中可能包含的信息有会话标识符（session-id），域，路径，安全属性（true/false）等。

分析QQ群检索项目，两个服务器端脚本如图2，3所示：

图 2-将用户待查询QQ号加入队列

cookie如果为空，则将其内容设置为两个随机数，以此作为会话标识符。对于两个拼接的随机数，有效地避免了重复以及攻击者遍历所有取值地攻击方式，可以保证cookie的唯一性。但是cookie的明文传输特性，该脚本没有对其有任何加密处理，攻击者通过监听即可获取当前cookie值。

图 3-将查询结果返回用户

系统设置每半小时返回一次查询结果，在此期间，如果用户关闭浏览器，且恰好用户设置了立即清除本地cookies文件，那么该用户将丢失回话信息，无法得到查询结果。

对此较好的解决方式是加入用户登录系统，以用户身份信息标识每一次查询，Cookie作为登录过程中的信息传输方式。

而Cookie本身存在许多隐私性和安全性问题，我们将在后面详细讨论。

 

• cookie隐私性考虑

Cookie通常被用来让服务器追踪用户状态。比如，许多“网页分析”公司利用cookie来识别一个用户是否返回了一个网页地址，或是否浏览了另一个网站。尽管cookie不是唯一可以被用来在HTTP请求中追踪用户的机制，但是，cookie在用户代理会话中的连续性和能在不同主机间共享的特性，让它很容易实现追踪。

3.1 第三方cookie

尤其令人担忧的是“第三方”cookie。在客户端递交一个HTML文件时，经常会向其他服务器（比如广告网络）请求资源。第三方服务可以利用cookie追踪用户，尽管用户从来没有直接访问过这个服务器。比如，如果一个用户访问了一个网页，其中有的内容来自一个第三方，随后，用户访问了另外一个网站，该网站中有来自同一个第三方的内容。这种情况下，第三方可以在这两个网站之间追踪用户。第三方cookies如图4所示：

图 4-第三方cookies

有的用户限制了第三方cookie的行为。比如，在响应第三方请求时，有的用户拒绝发送cookie头，有的用户拒绝处理Set-Cookie头。客户端在它们的cookie策略中差异很大。我们允许用户代理广泛尝试第三方策略，以平衡用户需要的隐私性和兼容性。但在HTTP State Management Mechanism文中，并没有提出支持任何一个特定的第三方cookie策略。

如果服务器尝试在限制范围内追踪用户，第三方cookie阻塞策略在实现其私密性上经常是无效的。特别是，两个合作的服务器可以通过在动态URL中注入认证信息，在不使用用任何cookie的情况下，实现追踪用户。

3.2用户控制

客户端应该提供用户管理存在cookie内存中cookie的机制。比如，客户端可以让用户在一个特定的时间段内，能够删除所有接受的cookies，或者与特定域名有关的cookies。在此基础上，许多客户端包括用户接口元素允许用户检查存储在cookie内存中的cookies。

客户端应该提供用户能够让cookie失效的机制。当cookies失效时，用户代理禁止在对外发出的HTTP请求中包含cookie头，紧张对接收的Set-Cookie头进行处理。

有的客户端为用户提供防止回话中连续存储cookies的机制。当这样配置时，用户代理必须将所有接受到cookies的连续标志（persistent-flag）视为false。一些流行的客户端通过“无痕浏览”模式来展示这个功能。

有的客户端为用户提供允许个人编辑cookie存储的功能。在许多常用的情景中，这些功能控件会产生大量的提示。然而，一些对隐私性担忧的用户发现这些控件很有用。

例如，在Chrome浏览器中，提供了如下可供用户操作的Cookies管理选项：

图 5-Chrome中的Cookies管理

3.3失效日期

尽管服务器可以为远距离的cookie设置失效日期，大多数用户代理并没有保存cookies几十年。服务器应当基于cookie的目的，为cookie选择合理的截止日期，以此来保障用户隐私性，而不是选择毫无必要的如此长的生命周期。比如，一个典型的认证回话，设置两周后失效才是合理的。

 

• cookie安全性考虑

4.1综述

cookies有许多安全陷阱。HTTP Statement Management Mechanism主要讨论了几个突出的问题。

特别的，cookies鼓励开发者依赖环境权限来进行授权，这经常成为被攻击的漏洞，比如CSRF（cross-site request forgery跨站点请求伪造）。并且，开发者经常会在将会话标识符存在cookies中时，创造会话固定漏洞（session fixation vulnerabilities）。

HTTPs中用到的传输层加密，不足以防止网络攻击者获得或替换一个受害者的cookies，因为cookie协议本身就有各种漏洞。并且，默认情况下，即使与HTTPs一同使用时，cookies不提供网络攻击下的机密性和完整性保护。

4.2环境权限

因为一些用户代理允许远程方从用户代理发出HTTP请求（比如，通过HTTP重定向或HTML形式），这使得那些利用cookies来为用户授权的服务器会产生安全漏洞。当发送这些请求时，用户代理甚至可以在远程方根本不知道cookies内容的情况下获得cookies，这很可能让远程方在安全性不严密的服务上行使权限。

虽然这些安全顾虑有过很多说法（如：跨站点请求伪造，混淆代理confused deputy）这些问题都来源于将cookie作为一种环境权限。cookies鼓励服务器操作者将指定（URLs形式）与授权认证（cookies形式）区分。因此，用户代理为攻击者指定的资源提供权限，可能造成服务器或它的用户执行攻击者指定的操作，就好像这些操作是由用户授权了的一样。

服务器开发者可能会希望通过将URL视为能够来考虑指定和授权混乱的问题，而不是使用cookies来授权。如果将秘密信息存储在URLs中，而不是cookies中，这要求远程端自身提供机密性，。尽管这个方法不是万能的，但审慎地应用这些规则可以实现更加健壮的安全性。

4.3明文

除非在安全信道中传输（如：TLS），Cookie和Set-Cookie头中的信息是以明文形式传输的。

1. 所有在这些头中传输的敏感信息都暴露在窃听者面前。
2. 恶意中间人可以在信息向任意方向传输时更改Set-Cookie头，这将导致不可预测的结果。
3. 恶意用户可以在传输前更改Cookie头，这将导致不可预测的结果。

    服务器应该在传递cookies至客户端时（尽管在加密通道内发送）对其内容加密和签名。然而，对cookies加密和签名并不能够防止攻击者将cookie从一个用户代理移植到另外一个或者在后面的某个时间重放。

    为了对每一个cookie的内容进行加密和签名，对安全性有更高要求的服务器应当只在加密信道中使用Cookie和Set-Cookie头。当在加密信道中使用Cookie和Set-Cookie头时，服务器应当为每一个cookie设置安全属性，否则，安全信道提供的保护很大程度上是无意义的。

打开Chrome浏览器中任意一个cookie文件，其内容如图所示：

图 6-cookie内容

可见google浏览器对其内容进行了加密，从这份cookie文件可用得到该cookie的相关属性设置。

举例来说，考虑一个在cookie中存储了会话标识符，并且通常通过HTTPs访问的网页邮箱服务器。如果服务器没有在其cookies中设置安全属性，一个活跃的网络攻击者可以拦截窃听任何从客户端发出的HTTP请求，并且通过HTTP将该请求重定向到网页邮箱服务器。尽管服务器没有监听HTTP连接，用户端将仍会在请求中包含cookies。活跃的网络攻击者会拦截这些cookies并在服务器上重放，从中获取用户邮箱。相反，如果服务器在这些cookie中设置了安全属性，用户代理将不会在其明文请求中包含cookie。该攻击过程如下图所示：

图 7-对没有安全保护的Cookie的攻击

4.4会话标识符

服务器大多存储一个nonce（或会话标识符）在cookie中，而不是直接的会话信息。当服务器接收了一个带有nonce的HTTP请求时，cookie中的nonce作为钥匙，服务器可以以此来查看状态信息。

如果攻击者的到了cookie的内容，会话标识符的使用可以限制攻击者造成的危害，因为nonce只有在和服务器交互中才有用（与无标识符cookies内容不同，无标识符cookies的内容本身很敏感）。进一步说， nonce信号量的使用防止了攻击者将两次服务器的交互连接起来，否则，这会导致一些不可预测的行为。

使用会话标识符不是没有风险。比如，服务器应该注意“会话固定（session fixation）”漏洞。会话固定攻击分三步进行。第一，攻击者从自己的用户代理移植一个会话标识符到受害者客户端；第二，受害者使用该会话标识符与服务器交互，这可能将会话标识符嵌入到用户的证书或机密信息中；第三，攻击者使用该会话标识符直接与服务器交互，这可能获得用户权限或者机密信息。

4.4脆弱的机密性

cookie不提供端口隔离。如果运行在某个端口上的服务，其cookie是可信任的，那么在运行在其他端口的相同服务的cookie也是可信任的。如果cookie对某个端口的服务是可写的，那么对其他端口相同服务也是可写的。基于这个原因，服务器不应当在同一主机不同端口上运行互相不信任的服务，在cookie中存储安全敏感信息。

cookie不提供协议（scheme）隔离。虽然在最常用的http和https协议中，一个指定主机的cookies也可能对其他协议可用，如：ftp和gopher。尽管这种协议隔离的缺乏在允许存取cookie的非HTTP API中最明显，但它确实存在于处理cookie本身的需求中。

cookie通常不提供路径隔离。尽管网络层协议不向另一个路径发送存储的cookie，用户代理会通过非HTTP API暴露cookie，如，HTML的document. cookie API。因为这其中有的用户代理（如，网页浏览器）没有对来自不同路径的资源进行隔离，从一个路径检索的资源可能会能够访问另一个路径存储的cookies。

4.5脆弱的完整性

cookies不为同胞域（sibling domains）及其子域提供完整性保证。比如，考虑foo.example.com和bar.example.com。这是《HTTP Statement Management Mechanism》举的一个例子。

 foo.example.com服务器设置了一个有域名属性的cookie（可能覆盖了一个已经存在的由bar.example.com设置的”example.com” cookie），并且用户代理会在对bar.example.com的HTTP请求中包含该cookie。最坏的情况，bar.example.com无法将其与自身设置的cookie区分。foo.example.com服务器可能会利用此功能对bar发动攻击。如图8所示：

 

图 8-同胞域内攻击

服务器可以通过对其cookies内容的加密和签名部分缓减这个攻击。然而，使用密码学并不能完全解决这个问题，因为从用户会话中真实的example.com服务，攻击者可以拦截来自其中的cookie，这将带来不可预测的结果。

最后，攻击者能够通过存储大量的cookie，来强制用户代理删除cookies。一旦用户代理达到了其存储限制，它将会删除一些cookies，这样就破坏了服务器的正常服务。

4.6对DNS的依赖性

cookie的安全性依赖于域名系统（Domain Name System）。如果DNS部分或完全损害，cookie协议可能无法提供应用要求的安全特性。

 

• 总结

Cookie的使用使得用户与服务器可以进行连续有状态的会话，但Cookie的众多安全漏洞让攻击者有可乘之机，尽管人们在不断完善加强Cookie的安全机制，增加许多约束与属性，仍然无法保证Cookie在身份认证，访问控制，数据机密性，完整性上的绝对安全。

在某种意义上来说，Cookie本身的存在就破坏了用户信息的隐私性，它被用来追踪用户的当前状态。对于第三方Cookie，它能够实现在不同站点之间追踪用户的状态，为此，浏览器提供了一些策略，如，让用户能够禁止第三方Cookie，但这并不能完全阻止服务器对用户的追踪。只要两个合作服务器在URL中包含状态等信息，不需要Cookies也能实现追踪。

对于用户的隐私性，有的用户代理提供用户对本地Cookies文件的操作权限，服务器合理设置Cookies有效时限，这些都是提高Cookie在安全性上的措施。

对于用Cookies来进行用户授权而存在的安全漏洞，典型攻击有跨站点请求伪造。开发者应采用加密的URLs来判断用户身份。

对于Cookies的明文传输特性，服务器需要对其加密和签名，同时在加密信道中传输。这还不够，服务器还要为其设置安全属性，这样客户端才不会在明文请求中包含cookie。

对于Cookies中的会话标识符，在一定程度上抵抗了攻击者的窃听与攻击。但它同样存在“会话固定”漏洞，攻击者通过监听窃取用户当前的会话标识符可以实现会话劫持。

Cookies的数据机密性，完整性十分脆弱，这是因为它不提供端口，协议，路径上的隔离，也不提供同胞域及其子域的完整性保障。即使是相互不信任的服务，在同一个主机中的不同端口，协议，路径之间都是信息共享。Cookie注入是常见的攻击手段，破坏数据完整性。

并且，Cookies脆弱的安全性依赖于DNS的安全性，若系统遭到DNS域名攻击，Cookies的安全性就免谈了。

 

MEMO

    针对上述分析的cookie安全性问题，为提高用户和服务器的信息安全，这里提出几条相关的建议和注意事项。

对于服务器开发者：

1. 根据交互所需的传输范围，设置适当的Cookie有效时间
2. 对cookie加密以及数字签名，并在安全信道中传输
3. 用URL参数代替cookie中可能包含的敏感信息
4. 不要在cookie中设置中文
5. 合理设置Cookies中的安全属性
6. 服务器不应该在同一个主机上同时运行相互不信任的服务

对于普通用户：

1. 设置浏览器禁止第三方cookie
2. 定期清除本地存储的cookie
3. 不使用“自动登录”，因为自动登陆即使将用户名和密码保存在cookie中存在本地，即使加密了，很容易被盗取

 

 

 

注：文中一，三，四部分参考自《HTTP Statement Management Mechanism》