Cookie安全小结

Cookie机制:一般来说,同域内浏览器中发出的任何一个请求都会带上Cookie,无论请求什么资源,请求时,Cookie出现在请求头的Cookie字段中。服务端响应头的Set-Cookie字段可以添加、修改和删除Cookie,客户端通过javascript也可以添加、修改和删除Cookie。另外,Cookie是无法跨浏览器存在的。

利用Cookie机制,我们可以存储用户的会话信息,比如,用户登认证后的Session,之后同域内发出的请求都会带上认证后的会话信息,很方便。也因此,攻击者特别喜欢盗取Cookie,这相当于盗取了目标网站上的用户权限。

当然,有时对静态组件的Cookie读取是一种浪费,我们可以用另一个无Cookie的域名来存放这些静态组件。

Cookie的重要字段如下:

[name] [value] [domain] [path] [expries] [max-age] [httponly] [secure]

其含义依次为:名称、值、所属域名、所属相对根路径、过期时间、是否有HttpOnly标志、是否有Secure标志。

下面分别对domain、path 、httponly和secure字段进行说明:

1、子域Cookie机制

设置Cookie时,如果不指定domain的值,默认就是本域。

例如:a.foo.com域通过javascript设置一个Cookie,语句如下:

      document.cookie="test=1";

那么,domain值默认为a.foo.com。如果指定domain为父级域,比如:

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

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

2、路径Cookie机制

设置Cookie时,如果不指定path的值,默认就是目标页面的路径。

例如:a.foo.com/admin/index.php页面通过javascript来设置一个Cookie,语句如下:

      document.cookie="test=1";

那么,path值默认为/admin/。通过指定path字段,javascript可以设置任意Cookie到任意路径下,但是只有目标路径下的页面javascript才能读取到该Cookie。

但是,通过设置path不能防止重要的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
    };
}(‘http://a.foo.com/admin/index.php‘);

3、HttpOnly Cookie机制

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

<?php
setcookie("test",1,time()+3600,"","",0,0);    //设置普通cookie
setcookie("test_http",1,time()+3600,"","",0,1);//第7个参数(这里的最后一个)是HttpOnly标志,0为关闭,1为开启,默认为0
?>

请求这个文件后,设置了个两个Cookie,如下图所示:

其中,test_http是HttpOnly Cookie。如果服务端响应的页面有Cookie调试信息,很可能会导致HttpOnly Cookie的泄漏。比如以下信息。

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

大多数浏览器限制Cookies(每个域50个Cookie)最大约为4kB,我们设置为更大且为本地Cookie,让请求头长度超过Apache的LimitRequestFieldSize,从而引起400错误。这样受攻击者只能通过清除Cookie才能正常访问目标网站。

4、Secure Cookie机制

Secure Cookie机制指的是设置了Secure标志的Cookie仅在HTTPS层面上安全传输,如果请求是HTTP的就不会带上这个Cookie,这样能降低重要的Cookie被中间人截获的风险。

但是,Secure Cookie对于客户端脚本来说是可读写的,也就意味着,它能够被盗取和篡改。如下的javascript脚本代码可对已知的Secure Cookie进行篡改:

//path与domain必须一致,否则会被认为是不同的Cookie
document.cookie="test_secure=1;path=/;secure;"

本地Cookie与内存Cookie

如果没设置过期时间,就是内存Cookie,这样的Cookie会随着浏览器的关闭而从内存中消失;如果设置了过期时间是未来的某个时间点,那么就是本地Cookie,这样的Cookie就会以文本形式保存在操作系统本地,待过期时间到了才会消失。如:

document.cookie="test_expires=1;expires=Mon,01 Jan 2112 00:00:00 GMT";//GMT时间,2112年1月1日才会过期

采用本地Cookie可以让用户在未来某一段时间内都不需要进行登录操作,提升用户体验,但是,如果攻击者通过XSS得到这样的本地Cookie后,就能够在未来很长一段时间内,甚至永久控制着目标用户的账号权限。但这并不意味着内存Cookie更安全,因为攻击者可以给内存Cookie加一个过期时间,使其变为本地Cookie。

Cookie的P3P性质

HTTP响应头的P3P(Platform for Privacy Preferences Project)字段是W3C公布的一项隐私保护推荐标准。该字段用于标识是否允许目标网站的Cookie被另一个域通过加载目标网站而设置或发送,但仅IE执行了该策略。

比如,evil域通过script或iframe等方式加载foo域。加载的时候,浏览器是否会允许foo域设置自己的Cookie,或是否允许发送请求到foo域时,带上foo域已有的Cookie。

下面是关于P3P策略在设置与发送的两个场景,P3P策略在这两个场景下是有差异的:

1、设置Cookie

在IE下,默认是不允许第三方域设置Cookie(本地和内存)的,除非foo域在响应的时候带上P3P字段,如:

P3P:CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"

该字段的内容本身意义不大,不需要记(当然我们也没有时间去记这些没有特别意义的东西),只要知道这样设置后,被加载的目标域的Cookie就可以被正常设置了,设置后的Cookie在IE下会自动带上P3P属性(这个属性在Cookie中是看不到的),一次生效,即使之后没有P3P头,也有效。

2、发送Cookie

发送的Cookie如果是内存Cookie,刚无所谓是否有P3P属性,就可以正常发送;如果是本地Cookie,则这个本地Cookie必须拥有P3P属性,否则,即使目标域响应了P3P头也没用。

我们可以通过以下方法进行测试:

1)给host文件添加www.foo.com与www.evil.com域。

2)将如下代码保存为foo.php,并保证能通过www.foo.com/cookie/foo.php访问到。

<?php
//header(‘P3P:CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"‘);
setcookie("test0",‘local‘,time()+3600*3650);
setcookie("test_mem0",‘memory‘);
var_dump($_COOKIE);
?>

3)将如下代码保存为evil.php,并保证能通过www.evil.com/cookie/evil.php访问到。

<iframe src="http://www.foo.com/cookie/foo.php"></iframe>

4)IE浏览器访问www.evil.com/cookie/evil.php,由于没有响应P3P头,foo.php设置并未成功。

5)将foo.php的P3P响应功能的注释去掉,再访问www.evil.com/cookie/evil.php,可以发现本地Cookie(test0)与内存Cookie(test_mem0)都已设置成功。

6)修改foo.php里的Cookie名,比如,test0改为test1,test_mem0改为test_mem1等,注释P3P响应功能,然后直接访问www.foo.com/cookie/foo.php,这时会设置本地Cookie(test1)与内存Cookie(test_mem1),此时这两个Cookie都不带P3P属性。

7)再通过访问www.evil.com/cookie/evil.php,可以发现内存Cookie(test_mem1)正常发送,而本地Cookie(test1)没有发送。

8)继续修改foo.php里的Cookie名,test1改为test2,test_mem1改为test_mem2,去掉P3P响应功能的注释,然后直接访问www.foo.com/cookie/foo.php,此时本地Cookie(test2)与内存Cookie(test_mem2)都有了P3P属性。

9)这时访问www.evil.com/cookie/evil.php,可以发现test2与test_mem2都发送出去了。

时间: 2024-10-11 03:54:54

Cookie安全小结的相关文章

Cookie知识点小结

问题是什么?有哪些技术?如何解决? 1. Cookie 1)完成回话跟踪的一种机制:采用的是在客户端保存Http状态信息的方案 2)Cookie是在浏览器访问WEB服务器的某个资源时,由WEB服务器在HTTP响应消息头附带传送给浏览器的一个小文本文件. 3)一旦WEB浏览器保存了某个Cookie,那么它在以后每次访问该WEB服务器时,都会在HTTP请求头中将这个Cookie回传给WEB服务器. 4)底层实现原理:WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie

SqlMap post cookie注入小结

sqlmap SqlMap  POST注入 自动检测sqlmap -u “http://www.xxx.com/news?id=1″ –smart –level 3 –users 单个注入sqlmap -u “http://www.xxx.com/1.php” –data=”id=1″ 多个post值注入sqlmap -u “http://www.xxx.com/vuln.php” –data=”query=foobar;id=1″ –param-del=”;” -f –banner –dbs

JavaEE 要懂的小事:二、图解 Cookie(小甜饼)

Writer      :BYSocket(泥沙砖瓦浆木匠) 微         博:BYSocket 豆         瓣:BYSocket FaceBook:BYSocket Twitter    :BYSocket 上一篇 图解Http协议 ,这次继续Http家族中的Cookie.泥瓦匠最近看到博客园中一篇好文,如图: 这就是因为浏览器Cookie太大,导致请求时,请求头域过大造成发送失败.下面咱们就了解了解Cookie.按着以前的思路图文并茂哈,没图说个XX. 一.概述 首先从HTTP

SESSION和cookie的使用和区别

PHP中SESSION和cookie的使用和区别 cookie 是一种在远程浏览器端储存数据并以此来跟踪和识别用户的机制. PHP在http协议的头信息里发送cookie, 因此 setcookie() 函数必须在其它信息被输出到浏览器前调用,这和对 header() 函数的限制类似. 1.1 设置cookie: 可以用 setcookie() 或 setrawcookie() 函数来设置 cookie.也可以通过向客户端直接发送http头来设置. 1.1.1 使用setcookie()函数设置

Session与Cookie解析

Session和Cookie这两个对象也接触了比較长的时间了,今天就来总结一下. 首先,他们都是会话跟踪中经常使用的技术.Cookie在client记录信息来确定用户身份,Session在服务端记录信息来确定用户. 这篇文章将系统解说Cookie与Session的机制.使用场景和实例. Cookie机制: Cookie的产生:当两个用户都用訪问了同一个购物站点,訪问结束关闭浏览器后,假设用http协议传输Web数据,client和server的连接就关闭了,此时不能保存会话状态. 也就是说假设用

Java EE : 二、图解 Cookie(小甜饼)

目录 Java EE : 一.图解Http协议 Java EE : 二.图解 Cookie(小甜饼) Java EE : 三.图解Session(会话) 概述 一.概述 二.详细介绍Cookie 传输过程 三.谈Cookie的作用到XSS(跨站点脚本攻击) 四.总结 参考 一.概述 首先从HTTP说起,Cookie是Http协议中那部分呢? Cookie是什么? 自问自答:Cookie是请求头域和响应头域的字段.简单地说,就是伴随请求和响应的一组键值对的文本,小文本.所以称之为”Cookie“饼

servlet&amp;jsp入门.....韩顺平笔记

u 背景知识介绍 J2EE的13种技术 java->servlet->jsp [技术总是有一个演变过程] zip粘贴到word设置 u 回顾一下我们现有的技术 java 基础(面向对象,集合,界面,线程,文件,网络) jdbc (java 的数据库编程) oracle / mysql / sqlserver html css javascript (web  开发)  ->网页设计 xml serlvet+jsp ->java web开发[使用java技术做 web开发] u ja

Flask中session实现原理

前言 flask_session是flask框架实现session功能的一个插件,用来替代flask自带的session实现机制,flask默认的session信息保存在cookie中,不够安全和灵活. flask的session机制 session是用来干什么的呢?由于http协议是一个无状态的协议,也就是说同一个用户第一次请求和第二次请求是完全没有关系的,但是现在的网站基本上有登录使用的功能,这就要求必须实现有状态,而session机制实现的就是这个功能. 实现的原理: 用户第一次请求后,将

Cookie小结以及Cookie的小应用

Cookie小结以及Cookie的小应用 会话(Session)跟踪是Web程序中常用的技术,用来跟踪用户的整个会话.常用的会话跟踪技术是Cookie与Session.Cookie通过在客户端记录信息确定用户身份,Session通过在服务器端记录信息确定用户身份. 产生原因: 在程序中,会话跟踪是很重要的事情.WEB服务器端程序要能从大量的请求消息中区分出哪些请求消息属于同一个会话,即能识别出来自同一个浏览器的访问请求,这需要浏览器对其发出的每个请求消息都进行标识:属于同一个会话中的请求消息都附