您的位置 首页 php

细说web开发里的cookie

做IT经常会有这种感觉,当初信誓旦旦的观点瞬间崩塌。前两天跟一个同事说到跨域的问题,继而谈到cookie,脑子马上出现了好多问号,于是翻阅资料才有了更深入的理解。

cookie的存储位置

当年初识web开发,就知道cookie存在客户端,session存在服务端。那么cookie到底存在客户端的哪里,是硬盘里,内存里,浏览器里,document里,还是哪里?

首先思考一个问题,就是前面说的跨域问题。所谓跨域就是A站的页面不能随便请求B站的资源。这里其实有一个细节,请求都是客户端向服务端请求,严格来说跨域是响应到客户端的A站不能请求B站的服务端,而响应到客户端的B站就可以。这就奇怪了既然网页响应到客户端(即浏览器)便与服务端断开了连接,相互之间并没有瓜葛,怎么还能分得清A和B呢,难道html里偷偷藏了cookie在里面。这样才好解释每个请求里携带不同站点的cookie。事实上当然不是这样,html里除了我们自己写的那些标签再没有别的了。通过谷歌或火狐浏览器的设置里都能找到对应的存储cookie的位置,实际上cookie都是存在硬盘里的,安安静静的一个加密的文本文件。每次请求或者响应,浏览器都在根据站点与这个文本发生交互。所以,请暂时忘掉cookie藏在html里的想法。

71ede48c717d4b3e86fbb8f51208b4bd

cookie的调用

于是又回到了起初的那个问题,浏览器在请求时是怎么携带上对应的cookie呢?在深入思考前,咱们先做一个简单的模型。每个浏览器上渲染的页面都有地址吧,也就是url。比如说请求‘火狐的cookie存在哪’这样一个地址,响应的html会被浏览器解析渲染出来,它的html内容与url自然是一一对应的,同样的,属于它的cookie内容也会被打上url的标识,就像xml解析一样。这样便好理解了,页面请求时,浏览器会根据它的url从cookie文件里查找对应的cookie内容一并放在headers(不同于html里的head标签)里发送给服务端。

前面说的是比较简单的模型,cookie与url一一对应。实际上,cookie与url的对应关系要复杂一些,这要涉及到cookie的两个属性,暂且卖个关子,下面的cookie属性再细说。

cookie的属性

通常咱们使用cookie的属性,有name、value、maxAge/expires,这三个分别表示cookie内容的名称,值还有过期时间,不常用的属性也有三个,secure、comment、version分别表示安全传输协议、说明、规范版本。下面咱们要说到的是另两个不太常用但是却很重要的属性,即domain和path。

c7c6c9b5b87d43fbb469371525232b43

domain和path分别代表了cookie键值所属的站点和位置。举例来说,全村人把所有家伙什拿出放在一堆儿。而件家伙什都有各自的所属,有的呢只能被张三家使用,有的呢只要姓李就能使用,有的呢只能给王五的媳妇用。下面咱们就拿实例来说了,拿前面提到的url来说,打开谷歌浏览器访问,并打开开发工具里的application下的cookie查看。

2e43edad0b7845af86accd83c76289f9

如上图,红标1的domain是www.baidu.com,那么这条cookie就会被www.baidu.com下的页面调起使用;红标2的domain是*.baidu.com,那么这条cookie就会被www.baidu.com、live.baidu.com等.baidu.com结尾的页面调起使用。再拓展一下,如果domain是*.www.baidu.com,那么a.www.baidu.com当然也能调用,单点登录就是这么实现的。

domain搞明白了再说path,通常这个属性值都设为“/”也就是根目录,表示这个cookie能被对应domain下所有页面调用,但是如果设置二级目录,比如“/api”,那么必须是这个domain下的api目录才能使用。打个比方,一个庭院,如果院子里放着一个篮球,厨房里放着一个炒锅,卧室放着一个枕头。只要你进入这个庭院就能得到篮球,但是要得到炒锅就要进入厨房,要得到枕头就必须进入卧室。还有,如果你进入卧室,你不仅能拿到枕头,大院里的篮球也能拿到。依此类推,如果厨房的米柜里放着大米,要得到大米不仅要进入厨房还要打开米柜。总而言之,页面能取得当前目录及父级,父级的父级。。直到根目录的cookie.

说完了这些参数,cookie的调用就好理解了,也许每个浏览器有自己的寻址逻辑,但是大致思路是一致的。当向服务端请求时,浏览器会根据当前页面的url在cookie文件进行查找,首先根据domain查找,然后再根据path逐层查找,然后把所有合格的cookie带上传送给服务端。

cookie的设置

cookie存储在客户端,正常情况下cookie内容是由服务端控制的。这样才能实现登录或者其他业务。这就要谈到一个问题,服务端是怎么控制客户端的cookie的。

其实很简单,浏览器向服务端请求时,服务端会在响应的header头里携带set-cookie指令告诉浏览器,设置cookie的所有属性。并不是每次请求浏览器都会对cookie文件修改,只有收到这种set-cookie指令时才会修改。比如我已经登录了百度贴吧,会写入*.ba

idu.com一些键值记录登录状态,再访问百度地图时就不会再有记录登录信息的set-cookie了。

5742a4da62834ca381d89e4577f222af

前面说的是正常情况,当然就会有其他情况。比如js里执行个脚本document.cookie = “username=Darren;path=/;[domain=.csdn.net](#34;,可以轻意的修改cookie,或者在浏览器的开发工具里直接修改,还有很多的第三方插件都很容易做到。这样说来,cookie信不过。但是也没有更信得过的好办法了。说直白点,cookie是你存放物品的回执单,一旦被别人拿到就能把你的物品取走。甚至cookie比回执单更不安全,因为它可以复制,无限复制。咱们能做的还是自己小心。

cookie的祸端

许多人利用cookie作恶,最典型的是csrf攻击。就好像盗取了你的微信号然后给你家人打电话要钱。具体怎么实现呢,我举两个例子。

某个博客网站,删除文章只需要调用一个地址,abc.blog.com/articl/delete/234。正常情况下,服务端要验证是否是本人删除。非登录状态或者非本人文章是验证不通过的。但是,有这样一种场景。你在登录博客之后,浏览其它网站时,别人把这个链接藏在某个按钮或图片里,一旦你打开这个链接,浏览器首先会根据网址找到你存在电脑上的cookie信息发送给服务端,服务端会认为是本人所为,自然而然执行删除。

当然了,删除和修改的请求一般不会用get方法。那么我们再把黑客强大一些,即使是post请求,黑客用ajax模拟出了删除脚本,然后以评论或者其它方法写进了网站数据。当其它用户登录并打开了这个页面,就会启动删除脚本,同样会带上用户的cookie发送到服务端,服务端也同样会认为是本人所为,执行操作。

当然,网站能被植入脚本,网站开发要背锅。

cookie的拓展

seesion

既然cookie在客户端被随便修改,那么session在服务端是不是更安全一些呢。我先说结果,就安全而言两者是一模一样的。因为session内容虽然存在服务器上,但是也是通过一个name=PHPSESSID的cookie来连接的。只要别人拿了这个cookie,你用seesion在服务器上存了多少信息,也能给你挖出来。session是不能脱离cookie存在的。

token

token是前后分离后,用来跟服务端交互的手段,用来标识用户。曾经我以为token放在请求body里的参数,很容易被窃取,非常不安全。现在想想好天真,不管用cookie还是token都是秃子头上的虱子——明摆着。

好了,今天就说到这了。web开发经过几代大牛的耕耘才发展到现在,实属不易。但是仍然还有很多的路要走。

文章来源:智云一二三科技

文章标题:细说web开发里的cookie

文章地址:https://www.zhihuclub.com/33683.shtml

关于作者: 智云科技

热门文章

网站地图