COOKIE安全与防御
目 录程序员
摘要web
关键词数据库
1、 引言 浏览器
2、 COOKIE概述 缓存
4、 COOKIE惯性思惟 服务器
5、 COOKIE防御 cookie
6、 总结 网络
7、 参考文献： 15session
摘要：Cookie是一小段文本信息，只能保存字符串，伴随着用户请求和页面在Web服务器和浏览器间传递，用来保持Web中的回话状态和缓存信息，记录用户的状态。Cookie的使用方便了人们的网上生活,但同时对用户的许多隐私信息构成了威胁。本文介绍了Cookie技术的相关概念、应用领域及基本特征,说明了Cookie的工做原理和Cookie结构;其次讲述了常见的Cookie技术的漏洞,最后介绍了针对Cookie技术的安全防御措。
关键词：Cookie，HTTP无状态，保持secure，httponly，跨站攻击
1、引言
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 安全就不止为安全领域的人员所熟知，而成为一个热门的全民话题。
2、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 中所限制的字符均可以使用。但为了保持兼容性，程序 开发者都会尽可能避免使用这些特殊字符。
3、COOKIE安全分析
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。
4、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可能一支被利用，从而造成持久化攻击。
5、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访问。
6、总结
Cookie 在web中是普遍使用的，它给咱们的上网带来了极大的便利性，例如，当咱们浏览过一次优酷，那么这条记录就会被保存在浏览器中。固然，有利也有弊，咱们的上网安全也因之收到威胁。Cookie 能够也能被利用来进行XSS，CSRF等跨站攻击，它自己不是病毒也不是木马，对于主机自己不会产生威胁，可是容易被利用来进行攻击。对于cookie 安全，本文给出了一些安全分析，也给出了对应的防御策略。但我仍然认为，最佳的防护应该是优化网站自己，设置复杂而周全的规则策略使攻击者不能获取到有效信息，从而来堵住cookie漏洞，同时也常常给站点打补丁，进行分析。在大局势下，安全老是相对的，不安全倒是绝对的。咱们所能采起的措施就是 时刻保持警戒，不断了解最新的技术和安全报告， 一旦发现问题就迅速解决，尽量地不给居心不良 者以可乘之机。
7、参考文献：
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.