cookie 那些事儿

最新推荐文章于 2024-08-04 17:21:38 发布

转载最新推荐文章于 2024-08-04 17:21:38 发布 · 419 阅读

文章标签：

#cookie 跨域

javascript 专栏收录该内容

1 篇文章

订阅专栏

转自http://yslion.com/?p=37

关于跨域：

cookie是用来在某一个域下使用的，比如在.baidu.com这个域下种一个cookie，那么.google.com这个域就不能使用它；这是浏览器出于对用户隐私保护的考虑。要实现跨域的一个思路就是：客户端浏览器对某些html标签(比如script、iframe)的src没有进行跨域限制，用它们以GET方式夹带本域种的cookie值动态请求外域的程序，这个外域的程序来种植该域的值为GET参数传过去的cookie，从而达到互通的目的。例如：
最近上线的家天下单点登录首页里有一个员工论坛的链接，而员工论坛部署在.soufun.com域名下。为了实现在家天下单点登录首页可以直接进入员工论坛。我们的做法是：在家天下单点首页加载完后，利用js在页面动态添加一个script标签，向搜房的单点的接口发请求，验证通过后设置.soufun.com域的cookie。就有了.soufun.com域下的cookie，论坛就可以直接进入了。

这样的做法就是所谓的“jsonp”，用iframe也可以实现同样的效果。但是iframe存在很多浏览器兼容问题，个人认为还是用jsonp更省事。

经过实际使用发现Firefox、chrome等不用P3P也可以跨域，但是IE必须用加P3P的头信息才可以跨域。看来IE对跨域的限制更为严格！所以要想实现完全跨域，还是加上下面这句头信息比较好:)
header(‘P3P: CP=”CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA div COM NAV OTC NOI DSP COR”‘);

最近在做一个流量统计的东西的时候，偶然发现IE在对iframe里面的页面写Cookie的时候有一些安全限制，导致读取Cookie不成功，找了好长时间的解决办法，重要找到如下的办法：

1.页面里的COOKIE不能是浏览器进程的COOKIE(包括验证票和不设置超时时间的COOKIE),否则跨域会取不到.这点做跨域COOKIE的人比较少提到.不过实际上留意下几家大学做的方案,有细微的提到他们的验证模块里的COOKIE是有设置超时时间的.

2.当利用IFRAME时,记得要在相应的动态页的页头添加一下P3P的信息,否则IE会自觉的把IFRAME框里的COOKIE给阻止掉,产生问题.本身不保存自然就取不到了.这个其实是FRAMESET和COOKIE的问题,用FRAME或者IFRAME都会遇到.

3.测试时输出TRACE,会减少很多测试的工作量.

只需要设置 P3P HTTP Header，在隐含 iframe 里面跨域设置 cookie 就可以成功。他们所用的内容是：

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

ASP直接在头部加了头部申明，测试有效。
<%Response.AddHeader “P3P”, “CP=CAO PSA OUR”%>

php的话，应该是如下写法：
header(‘P3P: CP=CAO PSA OUR’);

ASP.NET的话
通过在代码上加Response.AddHeader(“P3P”, “CP=CAO PSA OUR”)或者在Window服务中将ASP.NET State Service 启动。

JSP:
response.setHeader(“P3P”,”CP=CAO PSA OUR”)

关于XSS

xss 通过 document.cookie 取得用户cookie 干坏事，权宜之计可这么做：

如何保障我们的敏感Cookie安全呢？通过上面的分析，一般的Cookie都是从 document对象中获得的，我们只要让敏感Cookies浏览器document中不可见就行了。很幸运，现在浏览器在设置Cookie的时候一般都接受一个叫做HttpOnly的参数，跟domain等其他参数一样，一旦这个HttpOnly被设置，你在浏览器的document对象中就看不到 Cookie了，而浏览器在浏览的时候不受任何影响，因为Cookie会被放在浏览器头中发送出去（包括ajax的时候），应用程序也一般不会在js里操作这些敏感Cookie的，对于一些敏感的Cookie我们采用HttpOnly，对于一些需要在应用程序中用js操作的cookie我们就不予设置，这样就保障了Cookie信息的安全也保证了应用。关于HttpOnly说明可以参照 http://msdn2.microsoft.com/en- us/library/ms533046.aspx。
给浏览器设置Cookie的头如下：
Set-Cookie: <name>=<value>[; <name>=<value>]
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure][; HttpOnly]
以php为例，在php 5.2版本时就已经在Setcookie函数加入了对HttpOnly的支持，譬如
<?php
setcookie(”abc”, ”test”, NULL, NULL, NULL, NULL, TRUE);
?>
就可以设置abc这个cookie，将其设置为HttpOnly，document将不可见这个Cookie。因为setcookie函数本质就是个 header，所以一样可以使用header来设置HttpOnly。然后再使用document.cookie就可以看到已经取不到这个Cookie 了。我们用这种方法来保护利例如Sessionid，如一些用于认证的auth-cookie，就不用担心身份被人获得了，这对于一些后台程序和 webmail提升安全性的意义是重大的。再次使用上面的攻击手法时可以看到，已经不能获取被我们设置为HttpOnly的敏感Cookie了。
但是，也可以看到HttpOnly并不是万能的，首先它并不能解决xss的问题，仍然不能抵制一些有耐心的黑客的攻击，也不能防止入侵者做ajax提交，甚至一些基于xss的proxy也出现了，但是已经可以提高攻击的门槛了，起码xss攻击不是每个脚本小子都能完成的了，而且其他的那些攻击手法因为一些环境和技术的限制，并不像Cookie窃取这种手法一样通用。
HttpOnly也是可能利用一些漏洞或者配置Bypass 的，关键问题是只要能取到浏览器发送的Cookie头就可以了。譬如以前出现的Http Trace攻击就可以将你的Header里的Cookie回显出来，利用ajax或者flash就可以完成这种攻击，这种手法也已经在ajax和flash中获得修补。另外一个关于配置或者应用程序上可能Bypass 的显著例子就是phpinfo，大家知道phpinfo会将浏览器发送的http头回显出来，其中就包括我们保护的auth信息，而这个页面经常存在在各种站点上，只要用ajax取phpinfo页面，取出header头对应的部分就可以获得Cookie了。一些应用程序的不完善也可能导致header头的泄露，这种攻击方式对于basic验证保护的页面一样可以攻击。
HttpOnly在IE 6以上，Firefox较新版本都得到了比较好的支持，并且在如Hotmail等应用程序里都有广泛的使用，并且已经是取得了比较好的安全效果。