最近在用thinkjs写自己的博客，发现自己老是掉进cookie的坑里，所以我会好好爱护这个小cookie的，没想到说的很有趣的。每个知识点都能钓到一条大鱼。想想我之前对待cookie，简直就是它认识我，我只能叫出他的名字。下面根据自己的理解，使用原生的koa2+mysql来简单演示一些cookie的处理方案。如果有什么不对的地方，希望大家友好指正。1.cookies介绍1.1项目中cookies的使用在实际应用场景中，使用cookies做的最多的事情之一就是维护身份认证的服务器状态。比如登录状态的判断1.2为什么需要cookies？敲黑板，HTTP是无状态协议，它不管理之前请求和响应的状态。即服务器每次收到请求，都不知道用户是谁，是否处于登录状态，所以服务器很迷茫。Cookie可以解决这个问题。如图所示，cookies的实现过程如下（盗图）：客户端向服务端发送HTTPResuest，服务端收到请求，并在其中添加set-cookie字段和对应的cookie值返回的HTTPResponse响应标头。response，解析出header中的set-cookie字段，并在下次向服务器发送请求时将cookie保存在本地，cookie会附加到HTTP请求的header字段Cookie中。服务端收到请求，通过判断cookie就知道除了发送请求外，客户端是谁。我是jser，通过原生的nodejs和浏览器调试工具，可以看到各个服务器和浏览器交互的细节。代码如下，欢迎交流和star：https://github.com/LaputaGit/...有兴趣的可以了解一下，运行代码。代码中有详细注释。2.那么问题来了，你的cookie安全吗？首先检查您的项目是否在以下情况下使用了cookies。可以用js操作客户端cookie吗？Cookie域（Domain）和路径（Path）设置如何制定策略？为什么要这样划分？在使用SSL的应用程序中，您的cookie可以在HTTP请求和HTTPS请求之间共享吗？这个暂且不提，介绍一下我个人对cookies安全性的理解。我认为cookies不是为了安全而制作的，所以没有必要为安全承担责任。许多人使用cookie进行登录验证，包括我自己。已经搞定了，而且很简单。..再说说cookie的安全性。说到“让cookies更安全”，我们大概会做以下工作。将httpOnly设置为true以确保客户端无法操作cookie。将安全设置为true。服务器通过各种方式对cookie进行加密后，生成token例如用户发起登录->服务器根据客户端的用户名、ip、expiration、useragent、saves等组合信息，加密生成具有可加密功能的token数据库中的令牌，并将令牌写入cookie。服务器端验证流程：client发送请求->server解析cookie中的token信息->解密token，验证client的username是否存在，如果存在->验证token与token是否相同在数据库中，如果相同->验证token的有效期到期，如果有效->验证ip是否变了，如果有效->验证useragent等...我们可以为cookie的加密添加许多选项。或者，有一些解决方案是在后端session中存储敏感信息，但是数据仍然存储在cookie中，通过http传输的问题就来了。不管是通过cookie对敏感信息进行加密，还是通过session将敏感信息包裹起来，这样就解决了问题是的Cookie是一个可以被篡改的问题！这是一个内部问题。不仅仅是浏览器可以发送HTTP请求。很多HTTP客户端软件，如postman、paw等，都可以发送任意的HTTP请求，设置任意的header字段。如果我们直接将Cookie字段设置为authed=true，然后发送HTTP请求，服务器岂不是被欺骗了？这种攻击非常容易，cookies是可以被篡改的！但是，这并不能保证数据的安全。基于HTTP的cookie传输是明文的，可以通过抓包获取数据，这是由传输层决定的。这是cookie不安全的决定因素。不管你的cookie是怎么加密的，一旦我劫持了你的cookie，我就会把cookie原封不动的发给服务器。退一步说，即使是加密的，有时候也可以通过一些手段破解，只要符合服务器cookie验证的规则，那么这个cookie就是“合法”的，自然就不安全了。待续。..相关代码示例稍后补充
