Cookie安全

Cookie安全

Cookie是一个神奇的机制，同域内浏览器中发出的任何一个请求都会带上Cookie，无论请求什么资源，请求时，Cookie出现在请求头的Cookie字段中。服务端响应头的Set-Cookie字段可以添加、修改和删除Cookie，大多数情况下，客户端通过JavaScript也可以添加、修改和删除Cookie。

由于这样的机制，Cookie经常被用来存储用户的会话信息，比如，用户登录认证后的Session，之后同域内发出的请求都会带上认证后的会话信息，非常方便。所以，攻击者就特别喜欢盗取Cookie，这相当于盗取了在目标网站上的用户权限。

Cookie的重要字段如下：

[name][value][domain][path][expires][httponly][secure]

其含义依次是：名称、值、所属域名、所属相对根路径、过期时间、是否有HttpOnly标志、是否有Secure标志。这些字段用好了，Cookie就是安全的，下面对关键的字段进行说明。

1．子域Cookie机制

这是domain字段的机制，设置Cookie时，如果不指定domain的值，默认就是本域。例如，a.foo.com域通过JavaScript来设置一个Cookie，语句如下：

document.cookie="test=1";

那么，domain值默认为a.foo.com。有趣的是，a.foo.com域设置Cookie时，可以指定domain为父级域，比如：

document.cookie="test=1;domain=foo.com";

此时，domain就变为foo.com，这样带来的好处就是可以在不同的子域共享Cookie，坏处也很明显，就是攻击者控制的其他子域也能读到这个Cookie。另外，这个机制不允许设置Cookie的domain为下一级子域或其他外域。

2．路径Cookie机制

这是path字段的机制，设置Cookie时，如果不指定path的值，默认就是目标页面的路径。例如，a.foo.com/admin/index.php页面通过JavaScript来设置一个Cookie，语句如下：

document.cookie="test=1";

path值就是/admin/。通过指定path字段，JavaScript有权限设置任意Cookie到任意路径下，但是只有目标路径下的页面JavaScript才能读取到该Cookie。那么有什么办法跨路径读取Cookie？比如，/evil/路径想读取/admin/路径的Cookie。很简单，通过跨iframe进行DOM操作即可，/evil/路径下页面的代码如下：

xc = function(src){

    var o = document.createElement("iframe"); // iframe进入同域的目标页面

    o.src = src;

    document.getElementsByTagName("body")[0].appendChild(o);

    o.onload = function(){ // iframe加载完成后

        d = o.contentDocument || o.contentWindow.document;
// 获取document对象

        alert(d.cookie); // 获取cookie

    };

}('');

所以，通过设置path不能防止重要的Cookie被盗取。

3．HttpOnly Cookie机制

顾名思义，HttpOnly是指仅在HTTP层面上传输的Cookie，当设置了HttpOnly标志后，客户端脚本就无法读写该Cookie，这样能有效地防御XSS攻击获取Cookie。以PHP setcookie为例，httponly.php文件代码如下：

setcookie("test", 1, time()+3600, "", "", 0); // 设置普通Cookie

setcookie("test_http", 1, time()+3600, "", "", 0, 1);
// 第7个参数（这里的最后一个）是HttpOnly标志，0为关闭，1为开启，默认为0

?>

请求这个文件后，设置了两个Cookie，如图2-2所示。

 

图2-2  设置的Cookie值

其中，test_http是HttpOnly Cookie。有什么办法能获取到HttpOnly Cookie？如果服务端响应的页面有Cookie调试信息，很可能就会导致HttpOnly Cookie的泄漏。比如，以下信息。

（1）PHP的phpinfo()信息，如图2-3所示。

 

图2-3  phpinfo()信息

（2）Django应用的调试信息，如图2-4所示。

 

图2-4  Django调试信息

（3）CVE-2012-0053关于Apache Http Server 400错误暴露HttpOnly Cookie，描述如下：

Apache HTTP Server 2.2.x多个版本没有严格限制HTTP请求头信息，HTTP请求头信息超过LimitRequestFieldSize长度时，服务器返回 400（Bad Request）错误，并在返回信息中将出错的请求头内容输出（包含请求头里的HttpOnly Cookie），攻击者可以利用这个缺陷获取HttpOnly Cookie。

可以通过技巧让Apache报400错误，例如，如下POC（Proof of Concept，为观点提供证据）：

 

apache 400 httponly cookie poc

请求这个POC时，发出的请求头信息如图2-5所示。

 

图2-5  POC发出的请求头信息

此时，httponly.php（其代码在前面已给出）会出现400错误，导致HttpOnly Cookie泄漏，如图2-6所示。

 

图2-6  Apache 400错误报出的HttpOnly Cookie

上面的几个例子中，服务端响应泄漏了HttpOnly Cookie应该算是一种漏洞，需谨慎对待，否则XSS会轻易获取到同域内的HttpOnly Cookie。

 

本文节选自《web前端黑客技术揭秘》

钟晨鸣，徐少培编著

电子工业出版社出版