目     录

摘要

关键词

一、 引言 

二、 COOKIE概述 

三、 COOKIE安全分析 

四、 COOKIE惯性思维 

五、 COOKIE防护 

六、 总结 

七、 参考文献： 15

摘要：Cookie是一小段文本信息，只能保存字符串，伴随着用户请求和页面在Web服务器和浏览器间传递，用来保持Web中的回话状态和缓存信息，记录用户的状态。Cookie的使用方便了人们的网上生活,但同时对用户的许多隐私信息构成了威胁。本文介绍了Cookie技术的相关概念、应用领域及基本特征,说明了Cookie的工作原理和Cookie结构;其次讲述了常见的Cookie技术的漏洞,最后介绍了针对Cookie技术的安全防护措。

关键词：Cookie，HTTP无状态，保持secure，httponly，跨站攻击

Cookie技术产生于HTTP协议在互联网的急速发展。由于因特网的发展，人们对于web服务的便利性和友好性有了更大的需求。在复杂的互联网交互活动中，希望服务器能够记录活动的状态，识别不同用户的活动记录。使得用户在本次访问服务器中，服务器能有上次用户访问时的种种记录和资源。

但是，HTTP协议是无状态的，即协议对于事物处理没有记忆能力。这种情况下，如果后续事物处理需要之前的信息，就必须要重传。举个例子，你再淘宝里面精挑细选了50件产品放在了购物车中，但是不小心关闭了淘宝界面。这时再登录时，我们肯定希望购物车中还是有这50件产品。

http协议是不能记住我们上次把50件产品加入购物车的。在客户端和服务器进行这种动态交互的web 应用的大量出现后，http的无状态特性就极大的阻碍了这些交互应用的发展。因此，在这种需求下就推出了各种能够保存web服务器状态的技术手段，两种用于保持HTTP连接状态的技术就应运产生了。一种是session技术，另一种就是cookie技术。

Cookie在英文中意为“小饼干，小甜品”，顾名思义就是形容cookie容量小，cookie是一小段文本文件，只含有字符。

Cookie就是服务器给用户颁布的一个状态值，并且保存在客户端或浏览器。只要在cookie的有效期内，用户再次访问该服务器时，浏览器会检查本地的cookies，并且会自动将cookie加在请求头部中一起发送给服务器，服务器通过识别该cookie来辨别用户身份，并且将用户在服务器中的资源提供给用户。

过度泛化的“隐私问 题”，正在影响互联网发展的大方向。 央视3·15晚会出人意料地没有谈食物、水和空气，而选择曝光公众缺乏意识的cookie问题，这一下子让还处在马斯洛需求层面较低层级的中国人民在对自身安全的追求上开始更加忧虑。Cookie 安全就不止为安全领域的人员所熟知，而成为一个热门的全民话题。

1. Cookie属性

1)Cookie名称，Cookie名称必须使用只能用在URL中的字符，一般用字母及数字，不能包含特殊字符，如有特殊字符想要转码。如js操作cookie的时候可以使用escape()对名称转码。

2)Cookie值，Cookie值同理Cookie的名称，可以进行转码和加密。

3)Expires，过期日期，一个GMT格式的时间，当过了这个日期之后，浏览器就会将这个Cookie删除掉，当不设置这个的时候，Cookie在浏览器关闭后消失。

4)Path，一个路径，在这个路径下面的页面才可以访问该Cookie，一般设为“/”，以表示同一个站点的所有页面都可以访问这个Cookie。

5）Domain，子域，指定在该子域下才可以访问Cookie，例如要让Cookie在a.test.com下可以访问，但在b.test.com下不能访问，则可将domain设置成a.test.com。

6)Secure，安全性，指定Cookie是否只能通过https协议访问，一般的Cookie使用HTTP协议既可访问，如果设置了Secure（没有值），则只有当使用https协议连接时cookie才可以被页面访问。

7)HttpOnly，如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息。

2. Cookie工作工程

具体工作过程描述如下：

1）We b 客户端通过浏览器向 We b 服务器发送连接请求， 通过 HTTP 报文请求行中的 URL 打开某一 Web页面。

2）We b 服务器接收到请求后，根据用户端提供的信息产生一个 Set-Cookies Head

3）将生成的Set-Cookies Header通过 Response Header存放在 HTTP 报文中回传给 Web 客户端，建立一次会话连接。

    4）We b 客户端收到 H T T P 应答报文后，如果要继续已建立的这次会话，则将 Cookies 的内容从 HTTP 报文中取出，形成一个 Cookies文本文件储存在客户端计算机的硬盘中或保存 在客户端计算机的内存中。

5）当 We b 客户端再次向 We b 服务器发送连接请求时， We b 浏览器首先根据要访问站点的 U R L 在本地计算机上寻找对应的 Cookies文本文件或在本地计算机的内存中寻找对应的 Cookies 内容。如果找到，则将此 Cookies 内容存放在 HTTP 请求报文中发给 Web 服务器。

6）Web 服务器接收到包含 Co okies 内容的 HT TP 请求后， 检索其 Cookies 中与用户有关的信息，并根据检索结果生成一个客户端所请求的页面应答传递给客户端 。

3. Cookie 特点

①　由服务器写入，保存在本地，传输于HTTP头部

②　Cookie由三元组【名字name，域名domain，路径path】确定，会出现重名，即cookie不唯一

③　Cookie 存在同源策略，仅以domain和path 作为同源限制，不区分端口和协议。Cookie 的同源策略类似于Web的同源策略(sop)，但比其安全性高。Web的同源策略以协议，端口，域名作为同源限制。Web 同源策略的目的是为了保护用户信息的安全，防止恶意的网站窃取数据。Cookie的同源策略目的也是为了安全性。

l Domain向上通配：一个页面可以为本域和任何父域设置cookie。

Eg:  服务器写入cookie时，当页面为 http://www.bank.com ，cookie为X时：

Ø Set-Cookie: user1=aaa; domain=.bank.com; path=/;      -------> domain不配陪  

Ø Set-Cookie: user2=bbb; domain=www.bank.com; path=/;  -------> domain匹配

Ø Set-Cookie: user3=ccc; domain=.www.bank.com; path=/;  ------->domian匹配

Ø Set-Cookie: user4=ddd; domain=other.bank.com；path=/; ------->domain不匹配

l Path向下通配：一个页面可以为本路径和任何子路径设置cookie。

Eg:  服务器写入cookie时，当页面为 http://www.bank.com ，path为/hello时：

Ø Set-Cookie: user1=aaa; domain=www.bank.com; path=/;         -------> path不配陪  

Ø Set-Cookie: user1=aaa; domain=www.bank.com; path=/hello;      -------> path配陪  

Ø Set-Cookie: user2=bbb; domain=www.bank.com; path=/hello/world; -------> path匹配

4. Cookie版本

主流有两个版本 ：

版本 0 : 由 Netscape 公司制定的，也被几乎所有的浏览器 支持。Java中为了保持兼容性 , 目前只支持到版本 0, Cookie的内容中不能空格，方括号，圆括号，等于号（=），逗号，双引号， 斜杠，问号，@ 符号，冒号，分号。

版本 1 : 根据 R F C 2109 文档制定的。放宽了很多限制。 版本 0 中所限制的字符都可以使用。但为了保持兼容性，程序 开发者都会尽量避免使用这些特殊字符。

1. Cookie 泄漏（欺骗）

    如下图，cookie在http协议中是明文传输的，并且直接附在http报文的前面，所以只要在网络中加个嗅探工具，获取http包，就可以分析并获得cookie的值。

    此时，当我们获取到别人的cookie的值，就产生了一种攻击漏洞，即cookie欺骗。我们将获取到的cookie值加在http请求前，服务器就会把我们当作是该cookie的用户，我们就成功的冒充了其他用户，可以使用其他用户在服务器的资源等。

既然明文cookie不安全，那么我们就使用加密传输cookie。这样即使数据包被截取，cookie也不会被泄漏。把http协议改成加密的https，如下图：

但是攻击者依旧可以通过社会工程学等等诱使用户主动访问在http协议下的服务器，从而获取明文cookie，因此加密后的cookie依旧不安全。如下图：用户先是通过HTTPS访问了bank.com服务器。而后，攻击者在网站weibo.com中插入js代码，该代码中img指向访问http下的non.bank.com服务器。攻击者通过社会工程学诱使用户去访问这条链接，当用户一点击该链接，就自动访问non.bank.com，让服务器给用户一个cookie。因为cookie同源策略中domain是向上匹配的。所以服务器会将该用户在bank.com的cookie 也分配给non.bank.com。这时就得到了bank.com给用户的cookie就被泄漏了。

在HTTPS也不安全的情况下，我们考虑cookie 自身属性。

Cookie 中有个属性secure，当该属性设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该cookie信息，所以不会被窃取到Cookie 的具体内容。就是只允许在加密的情况下将cookie加在数据包请求头部，防止cookie被带出来。

另一个是 HttpOnly属性，如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。

secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取cookie后进行攻击。

但是这两个属性并不能解决cookie在本机出现的信息泄漏的问题(FireFox的插件FireBug能直接看到cookie的相关信息)。

2. Cookie 注入\覆盖

Cookie 欺骗是攻击者登录的是受害者的身份。而Cookie 注入是认证为攻击者的攻击方式，受害者登录的是攻击者的身份。

Cookie注入简单来说就是利用Cookie而发起的注入攻击。从本质上来讲，Cookie注入与一般的注入（例如，传统的SQL注入）并无不同，两者都是针对数据库的注入，只是表现形式上略有不同。Cookie 注入就是将提交的参数以cookie的方式提交。而一般的注入是使用get和post方式提交。Get方式提交就是直接在网址之后加需注入的内容，而post 是经过表单提取的方式。Post和get不同就在于，get方式我们可以在ie地址栏看到我们提交的参数，而post 不能。

在 ASP 脚本中 Request 对象是用户与网站数据交互之中非常关键的点，Request 对象 获取客户端提交数据常用的 GET 和 POST 两种方式，同时可以不通过集合来获取数据，即直接用“request(“name”)”等。

相对post和get方式注入来说，cookie注入就要稍微繁琐，要进行cookie注入，我们首先就要修改cookie，这里就需要使用到Javascript语言。另外cookie注入的形成有两个必须条件： 条件1是程序对get和post方式提交的数据进行了过滤，但未对cookie方式提交的数据库进行过滤；条件2是在条件1的基础上还需要程序对提交数据获取方式是直接request("xxx")的方式，未指明使用request对象的具体方法进行获取。

    Cookie 注入 从技术手段来讲，比较有技术含量。如果只是简单的注入，例如，让受害者登录攻击者的邮箱，那么只要攻击者查看邮箱的信件就会发现异常，容易被发现。那么这种情况下，就需要进行精准的攻击。例如攻击”一个网页“中的一个组成界面，替换“一次http行为”中的某些阶段行为。精确攻击将在下文cookie惯性思维中细讲，这里不多做描述。精确攻击就很难被发现，极为隐蔽。

    如下图，用户先是用HTTPS的方式访问bank.com，而后，我们让用户使用HTTP的方式来访问non.bank.com，这时我们能得到一个cookie ，攻击者此时就可以将该明文cookie 替换成攻击者attack的cookie。在domain 向上匹配的同源策略下和cookie 优先级的情况下，访问non.bank.com时得到的cookie 会更优先，这时用户通过https访问bank.com时，就会使用attack优先级更高的cookie。

１.盲目认为cooke可信，没有做复杂验证

ｃｏｏｋｉｅ来自服务器还是第三方？我们通常认为cookie服务器颁发的，所以很可能认为cookie是安全的。但是cookie是从客户端向服务器提交的，所以严格来说，服务器接收到的cookie很可能是来自第三方的。攻击者窃取了他人的cookie然后提交给主机的。我们如果能够进行复杂的验证，例如过滤等，就会有效降低cookie的威胁。但是这个验证，本身存在一定的技术困难。

２.cookie 是唯一的？

事实是cookie不唯一，因此cookie会存在重名的情况。同名的cookie处理有歧义，因为RFC标准中对于cookie同名的处理就是不严格的，所以存在cookie同名上的安全隐患。

浏览器的cookiｅ优先级排序：

Ø ｐａｔｈ更长；

Ø ｐａｔｈ相同，更早创建（删除对方的cookie）

由于存在重名cookie的优先级，那么攻击者就可能利用cookie的同源策略来制造同名cookie，并且利用浏览器对于重名cookie的优先级的定义，从而使重名cookie中，攻击者所有的哪个cookie优先级更高。

３.一个“ＨＴＴＰ页面”？   NO!!!

我们经常认为一个网页界面是一个http页面，但其实，那是由很多个界面叠加组成的。这些不同的界面可能由于path 不同而拥有不同的cookie。此时，就可能形成了一种精准攻击，针对于某个界面进行cookie注入，而其他界面仍然是正常界面。那么这种情景下，用户是很难发现异常的。如下图：

４.一次“ＨＴＴＰ”操作“？　　　ＮＯ！！！

    如下图，举个例子，我们在网上进行支付行为，我们外表看来的一次支付行为可能分为很多个HTTP操作，其中的跳转可能就不止一个。而每个不同的跳转和页面都会有不同的cookie。因此，这也会造成精准攻击。攻击者用自己的cookie 替换掉中间两个跳转，攻击者就可以从受害者卡里划走一笔钱到自己的账户中。同样，这种精准攻击也是极其难发现的。因为可能上面的登录名还是受害者的，但是钱却不知不觉的转到攻击者账户区。

５.精确清理cookie？

实际上，我们并不经常清理cookie，或者说，cookie难以清理。由于cookie 的便利性和我们对于本地cookie的不熟悉性，我们并不能精准的清理cookie，这就会导致泄漏的cookie可能一支被利用，从而形成持久化攻击。

１.”重名检查“

但是这个有难度。因为cookie 时RFC定义的，而修改RFC中的cookie 标准是有困难的。

２.清理cookie

Cookie是由于便利性而存在的，那么总是在使用后清除cookie，其实就达不到cookie的便利作用了。

３.不在 Cookies 中存放敏感信息。

这是一个 理想化的思路，其实质就是抛弃 Cookies，但明显违背安全平台的设计思路，不能因为 Cookies 可能存在欺骗攻击而废止它的便利性。

４. 严格保护数据库不泄露。

保护数据库不泄露不仅仅是 Cookies 防御技术中需要注意的安全措施，也是其它安全措施中必须注意的重点。在数据库足够安全的情况下，即使产生cookie注入，cookie 注入的危害也会被极大的减小。这时从cookie 造成损失的后果上来减小cookie的危害。可以对数据库进行加密等等。

５. 严格堵住脚本系统中可能提交盗取 Cookies 的代码，把好验证关。

为了实现正常的用户交互功能，一般的脚 本系统都有发帖、留言、讨论、评论等功能，这些功能都允许用户提交或者上传一些自己的代码、程序，这样的代码有可能就是盗取 Cookies 的代码，因此，出于安全考虑，管理员要对这些代码进行严格审查，或者使用过滤插件、过滤软件过滤掉用户提交的一些非法信息来减小恶意代码的运行。

６. 使用 Session 和 Cookies 双重验证。

一般给予cookie 的系统会在cookie 中存储两个或多个变量，常见的是 username ( 用户名) 和 userlevel ( 用户等级) ，对于安全程序员来说， 既然cookie 是不安全的，而又必须把用户登录信息 存储下来以方便交互，就应该增加存储在 session。

cookie保存在客户端，容易被篡改，session保存在服务器端，用户难以修改，当用户与网站的交互结束时，Session 的生命周期随即结束，从这个层面上说，session类似一次一密，因此Session 的安全性比 Cookies 要高。所以两者结合适用，比较安全。

该方法技术实现为：在 cookie 中存储用户名和密码，当用户访问一个页面是先读取 session，如果有内容则以 session 为准，否则读取 cookie，按照 cookie 中提供的用户名和密码进行 “不透明”的登录一次，用以判断 cookie 中的内容是否合法，若合法再进而存入 session 中。

７.加防篡改验证码，加个登录随机验证码

在用户登录时，多增加一层验证，需要验证两个 cookie，一个验证的是用户名，一个验证的是随机数，而这个随机数是系统自动产生的，某时间段内相对为唯一的 “验证码”。

这种方法的技术实现方式为：修改用户登录页面代码，当用户名和密码通过系统正确验证之后，从数据库中取出对应这个用户名的 randnum，并写入 cookie，也就是说此时类似于产生了两个 cookie。

这样以来，就算是攻击者通过不法手段伪造了管理员的用户名，但这个随机产生的验证码就很难猜到了，而且这个随机数是不停变化的，就能在一定程度上增加了cookie攻击的难度。

８.运用HSTS平台，对于特定的域名强制进行HTTPS访问。

    Cookie 在web中是广泛使用的，它给我们的上网带来了极大的便利性，例如，当我们浏览过一次优酷，那么这条记录就会被保存在浏览器中。当然，有利也有弊，我们的上网安全也因之收到威胁。Cookie 可以也能被利用来进行XSS，CSRF等跨站攻击，它本身不是病毒也不是木马，对于主机本身不会产生威胁，但是容易被利用来进行攻击。对于cookie 安全，本文给出了一些安全分析，也给出了对应的防护策略。但我仍然认为，最佳的防御应该是优化网站本身，设置复杂而周全的规则策略使攻击者不能获取到有效信息，从而来堵住cookie漏洞，同时也经常给站点打补丁，进行分析。在大局势下，安全总是相对的，不安全却是绝对的。我们所能采取的措施就是 时刻保持警惕，不断了解最新的技术和安全报告， 一旦发现问题就迅速解决，尽可能地不给居心不良 者以可乘之机。

1.胡忠望，刘卫东 . Cookie 应用于个人信息安全研究 [J]. 计算机应用与软件，2007，（03）

2.李强，陈然等 . 基于主机特征的 Cookie 安全研究 [J]. 保密科学技术，2011，（04）

3.马亚娜，钱焕延，孙亚民 . Cookie 在 web 认证中的应用研究 ［ J］ . 小型微型计算机系统，2004，02: 207 －210.

4. 沈海波，洪帆. 基于 Cookie 的 Web 服务安全认证系统 ［J］ . 计算机工程与设计，2006，05: 762 －764 +881.

5.许治坤，王伟，郭添森. 网站渗透技术[M]. 北京 ：电子工业出版社， 2005.

6. 李馥娟 . 基于 Cookie 的 Web 应用分析及其安全研究 [J]. 网络安全 技术与应用，2009，（08）：63-67.