来聊一聊Cookie(小甜饼)，及其涉及到的web安全吧

最近在用thinkjs写本身的博客，发现老是掉到cookie的坑，因而就好好八一八这个小甜饼，没想到竟然还说颇有意思的，每个知识点都能拉出一条大鱼，想一想本身以前对cookie，简直就是它认识我，我只能叫出他的名字。

我将基于我本身的理解，使用原生koa2 + mysql来简单演示一下一些cookie的处理方案，有什么出岔子的地方，但愿你们友好指正

一、cookie介绍

1.1 项目中cookie的使用场景

在实际的应用场景中，Cookie被用来作得最多的一件事是保持身份认证的服务端状态。好比登陆状态的判断

1.2 为何须要cookie呢？

敲黑板，HTTP是无状态协议，他不对以前发生过的请求和响应的状态进行管理。也就是每次服务器接收到请求后，并不知道请求到底用户是谁，
是不是登陆态，这样服务端就懵逼了。cookie能够解决这个问题。如图，cookie的实现过程以下(盗了个图)：

• 客户端向服务器发送HTTP Resuest
• 服务器接收到请求，在返回的HTTP Response响应头中加入set-cookie字段以及对应的cookie值
• 客户端接收到服务器的响应，解析出头部的set-cookie字段并将其中的cookie保存到本地
• 下次向服务器发送请求时， 会将cookie附加在HTTP请求的头字段Cookie中
• 服务器收到请求，判断cookie，便知道了发送请求的是客户端是谁了

我是一个jser，经过原生nodejs和浏览器调试工具看到每个服务器和浏览器交互的细节。代码以下，欢迎交流并star：

https://github.com/LaputaGit/...

有兴趣的能够了解一下，运行一下代码，代码里面有详细的注释。

二、那么问题来了，你的cookie安全吗

首先，检测你的项目使用cookie有没有如下状况

1. 能不能用js操做客户端cookie？
2. 对于Cookie的域（Domain）和路径（Path）设置是如何制定策略的？为什么这样划分？
3. 在有SSL的应用中，你的Cookie是否能够在HTTP请求和HTTPS请求中通用？这一条暂时放放不介绍

我我的对于cookie的安全是这么理解的，我以为cookie不是为安全而生的，因此不必承担安全的责任，不少人拿cookie来作登陆验证，包括我本身之前也这么搞过，并且搞得很简单。。。囧

来讲一下cookie的安全性话题吧，谈到"为了cookie更安全"，大概会作如下工做

• 设置httpOnly为true，来保证客户端没法操做cookie
• 设置secure为true
• cookie在服务器以各类方式加密后，生成token

好比，用户发起登陆 -> 服务器根据客户端的username, ip, expiration, useragent等组合信息，用可加密函数加密生成token，将此token保存到数据库，并将token写入cookie。

服务端验证流程: 客户端发来请求 -> 服务器解析出cookie中的token信息 -> 将token解密，验证客户端的username是否存在，若是存在 -> 验证token是否和数据库中的token相同，若是相同 -> 验证token的有效期expiration，若是有效 -> 验证ip是否变化，若是有效 -> 验证user agent等 …咱们能够把不少的选项加入到cookie的加密中。

或者，有一些方案是把敏感信息交有后端session来保存，可是数据仍然放在cookie中，经过http传输

问题来了，无论你是经过cookie加密，或者是经过session包装敏感信息，这解决的是Cookie是能够被篡改的问题！这是个内部问题，能够发送HTTP请求的不仅是浏览器，不少HTTP客户端软件，好比postman, paw等等，均可以发送任意的HTTP请求，能够设置任何头字段。 假如咱们直接设置Cookie字段为authed=true并发送该HTTP请求， 服务器岂不是被欺骗了？这种攻击很是容易，Cookie是能够被篡改的！

可是，这样是不能保证数据的安全性的，基于HTTP的cookie的传输是明文的，能够经过抓包获取数据，这个是传输层所决定的。这个才是cookie不安全的决定因素，无论你cookie如何加密，一旦我劫持到你的cookie，再把这个cookie原封不动地发送到服务器，退一步来讲，即便加密，有时也能够经过一些手段破解，只要符合服务器cookie验证的规则，那么这个cookie是"合法的"，天然就不安全了。

未完待续。。。后续会补上相关代码示例