引用 “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对于客户端脚本来说是可读写的。