读Cookie安全后的读后感
引用 “Cookie是一个神奇的机制，同域内浏览器中发出的任何一个请求都会带上Cookie，无论请求什么资源，请求时，Cookie出现在请求头的Cookie字段中。服务端响应头的Set-Cookie字段可以添加、修改和删除Cookie，大多数情况下，客户端通过JavaScript也可以添加、修改和删除Cookie。”
这句话基本上说了cookie是什么 和怎样进行操作就不重复了
现在越来越多的黑阔用xss进行盗取用户或者管理员的cookie 盗取目标网站的用户权限
Cookie的重要字段如下：
[name][value][domain][path][expires][httponly][secure]
其含义依次是：名称、值、所属域名、所属相对根路径、过期时间、是否有HttpOnly标志、是否有Secure标志。
有几个字段是有专门的机制的
一个一个来
0×01子域Cookie机制
设置Domain 的值 可以进行共享cookie (不填为默认 本域 不能为其他域名)
比如 你是www.fuck.com但你 domain = bingdao.com 那是行不通的
在查关于 子域cookie机制时
找到2个相关的博文
http://blog.csdn.net/civilman/article/details/5286426(跨子域的Cookie的清除问题 在同一个环境下的2个网站 1.fuck.com 和 2.fuck.com 共用同一组cookie 但导致不能登出的问题的解决方法)
http://hi.baidu.com/thinkinginlamp/item/b1273444b6631ff4dc0f6ce6（子域和根域下的同名Cookie） 在子域下请求时，浏览器会把子域和根域下的Cookie一起发送到服务器，那如果子域和根域下有一个同名Cookie，当我们在PHP里使 用$_COOKIE访问时，到底生效的是哪个呢？
我也有点感兴趣就同这个博文实验了下
我直接贴图和操作了
我是在本机操作的 于是就用switchhosts! 更改了下环境 设定了一个虚拟域名
设定虚拟域名 (因为毕竟是子域和根域下的Cookie的问题 IP不好实现)
编写设置Cookie的PHP脚本，先设置子域，再设置根域：
再编写浏览Cookie的脚本：
然后访问1.php 生成cookie 再访问2.php获取cookie
结果显示有效的是子域下的Cookie。
___________________________________________
在子域下请求时，浏览器会把子域和根域下的Cookie一起发送到服务器，那如果子域和根域下有一个同名Cookie，当我们在PHP里使 用$_COOKIE访问时，到底生效的是哪个呢？
大家再看下我们的问题 所以我们再将先后顺序换下
答案很明显了
第一次先设置子域，再设置根域：请求头Cookie的值是bar=www;bar=2b，结果有效的是bar=www
第二次先设置根域，再设置子域：请求头Cookie的值是bar=2b;bar=www，结果有效的是bar=2b
同名时是根据设置cookie的先后顺序来也就是哪个在前哪个生效，后面的会被忽略。
0×02路径Cookie机制
“path字段的机制 ，设置Cookie时，如果不指定path的值，默认就是目标页面的路径。”
看就看得懂.
0x03HttpOnly Cookie机制
“HttpOnly是指仅在HTTP层面上传输的Cookie，当设置了HttpOnly标志后，客户端脚本就无法读写该Cookie，这样能有效地防御XSS攻击获取Cookie。
<?php
setcookie(“test”, 1, time()+3600, “”, “”, 0); // 设置普通Cookie
setcookie(“test_http”, 1, time()+3600, “”, “”, 0, 1);
// 第7个参数（这里的最后一个）是HttpOnly标志，0为关闭，1为开启，默认为0
?>
”
但还是有突破的方法
(1)查看phpinfo.php
本地测试的
（2）Django应用的调试信息，没进行测试- -
（3）CVE-2012-0053关于Apache Http Server 400错误暴露HttpOnly Cookie 本地木有apache环境 没有测试…. 大家有兴趣自己测试吧..
0×04 Secure Cookie机制
指的是设置了Secure标志的Cookie仅在HTTPS层面上安全传输，如果请求是HTTP的，就不会带上这个Cookie，这样能降低重要的Cookie被中间人截获的风险。
Secure Cookie对于客户端脚本来说是可读写的。
本文出自 “Taro” 博客，转载请与作者联系！