深入剖析Express cookie-parser中间件实现示例

文章导读

cookie-parser 是Express的中间件,用来实现cookie的解析,是官方脚手架内置的中间件之一。

它的使用非常简单,但在使用过程中偶尔也会遇到问题。一般都是因为对 Express + cookie-parser 的签名、验证机制不了解导致的。

本文深入讲解 Express + cookie-parser 的签名和验证的实现机制,以及cookie签名是如何增强网站的安全性的。

文本同步收录于GitHub主题系列 《Nodejs学习笔记》

入门例子:cookie设置与解析

先从最简单的例子来看下 cookie-parser 的使用,这里采用默认配置。

  1. cookie设置:使用 Express 的内置方法 res.cookie() 。
  2. cookie解析:使用 cookie-parser 中间件。
var express = require('express');
var cookieParser = require('cookie-parser');
var app = express();
app.use(cookieParser());
app.use(function (req, res, next) {
 console.log(req.cookies.nick); // 第二次访问,输出chyingp
 next();
});

app.use(function (req, res, next) {
 res.cookie('nick', 'chyingp');
 res.end('ok');
});
app.listen(3000);

在当前场景下, cookie-parser 中间件大致实现如下:

app.use(function (req, res, next) {
 req.cookies = cookie.parse(req.headers.cookie);
 next();
});

进阶例子:cookie签名与解析

出于安全的考虑,我们通常需要对cookie进行签名。

例子改写如下,有几个注意点:

  1. cookieParser 初始化时,传入 secret 作为签名的秘钥。
  2. 设置cookie时,将 signed 设置为 true ,表示对即将设置的cookie进行签名。
  3. 获取cookie时,可以通过 req.cookies ,也可以通过 req.signedCookies 获取。
var express = require('express');
var cookieParser = require('cookie-parser');
var app = express();
// 初始化中间件,传入的第一个参数为singed secret
app.use(cookieParser('secret'));
app.use(function (req, res, next) {
 console.log(req.cookies.nick); // chyingp
 console.log(req.signedCookies.nick); // chyingp
 next();
});
app.use(function (req, res, next) {
 // 传入第三个参数 {signed: true},表示要对cookie进行摘要计算
 res.cookie('nick', 'chyingp', {signed: true});
 res.end('ok');
});
app.listen(3000);

签名前的cookie值为 chyingp ,签名后的cookie值为 s%3Achyingp.uVofnk6k%2B9mHQpdPlQeOfjM8B5oa6mppny9d%2BmG9rD0 ,decode后为 s:chyingp.uVofnk6k+9mHQpdPlQeOfjM8B5oa6mppny9d+mG9rD0

下面就来分析下,cookie的签名、解析是如何实现的。

cookie签名、验证实现剖析

Express完成cookie值的签名, cookie-parser 实现签名cookie的解析。两者共用同一个秘钥。

cookie签名

Express对cookie的设置(包括签名),都是通过 res.cookie() 这个方法实现的。

精简后的代码如下:

res.cookie = function (name, value, options) {
 var secret = this.req.secret;
 var signed = opts.signed;
 // 如果 options.signed 为true,则对cookie进行签名
 if (signed) {
  val = 's:' + sign(val, secret);
 }
 this.append('Set-Cookie', cookie.serialize(name, String(val), opts));
 return this;
};

sign 为签名函数。伪代码如下,其实就是把cookie的原始值,跟hmac后的值拼接起来。

敲黑板划重点:签名后的cookie值,包含了原始值。

function sign (val, secret) {
 return val + '.' + hmac(val, secret);
}

这里的 secret 哪来的呢?是 cookie-parser 初始化的时候传入的。如下伪代码所示:

var cookieParser = function (secret) {
 return function (req, res, next) {
  req.secret = secret;
  // ...
  next();
 };
};
app.use(cookieParser('secret'));

签名cookie解析

知道了cookie签名的机制后,如何"解析"签名cookie就很清楚了。这个阶段,中间件主要做了两件事:

  1. 将签名cookie对应的原始值提取出来
  2. 验证签名cookie是否合法

实现代码如下:

// str:签名后的cookie,比如 "s:chyingp.uVofnk6k+9mHQpdPlQeOfjM8B5oa6mppny9d+mG9rD0"
// secret:秘钥,比如 "secret"
function signedCookie(str, secret) {

 // 检查是否 s: 开头,确保只对签过名的cookie进行解析
 if (str.substr(0, 2) !== 's:') {
  return str;
 }

 // 校验签名的值是否合法,如合法,返回true,否则,返回false
 var val = unsign(str.slice(2), secret);

 if (val !== false) {
  return val;
 }

 return false;
}

判断、提取cookie原始值比较简单。只是是 unsign 方法名比较有迷惑性。

一般只会对签名进行合法校验,并没有所谓的反签名。

unsign 方法的代码如下:

  1. 首先,从传入的cookie值中,分别提取出原始值A1、签名值B1。
  2. 其次,用同样的秘钥对A1进行签名,得到A2。
  3. 最后,根据A2、B1是否相等,判断签名是否合法。

exports.unsign = function(val, secret){

 var str = val.slice(0, val.lastIndexOf('.'))
  , mac = exports.sign(str, secret);

 return sha1(mac) == sha1(val) ? str : false;
};

cookie签名的作用

主要是出于安全考虑, 防止cookie被篡改 ,增强安全性。

举个小例子来看下cookie签名是如何实现防篡改的。

基于前面的例子展开。假设网站通过 nick 这个cookie来区分当前登录的用户是谁。在前面例子中,登录用户的cookie中,nick对应的值如下:(decode后的)

s:chyingp.uVofnk6k+9mHQpdPlQeOfjM8B5oa6mppny9d+mG9rD0

此时,有人试图修改这个cookie值,来达到伪造身份的目的。比如修改成 xiaoming :

s:xiaoming.uVofnk6k+9mHQpdPlQeOfjM8B5oa6mppny9d+mG9rD0

当网站收到请求,对签名cookie进行解析,发现签名验证不通过。由此可判断,cookie是伪造的。

hmac("xiaoming", "secret") !== "uVofnk6k+9mHQpdPlQeOfjM8B5oa6mppny9d+mG9rD0"

签名就一定能够确保安全吗

当然不是。

上个小节的例子,仅通过 nick 这个cookie的值来判断登录的是哪个用户,这是一个非常糟糕的设计。虽然在秘钥未知的情况下,很难伪造签名cookie。但用户名相同的情况下,签名也是相同的。这种情况下,其实是很容易伪造的。

另外,开源组件的算法是公开的,因此秘钥的安全性就成了关键,要确保秘钥不泄露。

还有很多,这里不展开。

小结

本文主要对 Express + cookie-parser 的签名和解析机制进行相对深入的介绍。

不少类似的总结文章中,把cookie的签名说成了加密,这是一个常见的错误,读者朋友需要注意一下。

签名部分的介绍,稍微涉及一些简单的安全知识,对这块不熟悉的同学可以留言交流。为讲解方便,部分段落、用词可能不够严谨。如有错漏,敬请指出。

相关链接

https://github.com/expressjs/cookie-parser

https://github.com/chyingp/nodejs-learning-guide

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

您可能感兴趣的文章:

  • express的中间件cookieParser详解
(0)

相关推荐

  • express的中间件cookieParser详解

    cookieParser中间件用于获取web浏览器发送的cookie中的内容.在使用了cookieParser中间件后, 代表客户端请求的htto.IncomingMessage对象就具有了一个cookies属性,该属性之为一个对象的数组, 其中存放了所有web浏览器发送的cookie,每一个cookie为cookies属性值数组中的一个对象. index.html代码: 复制代码 代码如下: <!DOCTYPE html>  <html>  <head lang="

  • 深入剖析Express cookie-parser中间件实现示例

    文章导读 cookie-parser 是Express的中间件,用来实现cookie的解析,是官方脚手架内置的中间件之一. 它的使用非常简单,但在使用过程中偶尔也会遇到问题.一般都是因为对 Express + cookie-parser 的签名.验证机制不了解导致的. 本文深入讲解 Express + cookie-parser 的签名和验证的实现机制,以及cookie签名是如何增强网站的安全性的. 文本同步收录于GitHub主题系列 <Nodejs学习笔记> 入门例子:cookie设置与解析

  • express异步函数异常捕获示例详解

    在express中时使用 Async/await 编写异步代码时,每个 async 函数都要包裹在try/catch中,代码量多了看着冗余不优雅,express又不像koa的异步机制可以订阅全局的error事件,为了解决这个问题,需要写个捕获异步函数异常的中间件. uncaughtException 开始能想到的肯定是try/catch了,但是也想过能否使用nodejs提供的uncaughtException事件,在全局捕获异常,例如下面的代码: process.on("uncaughtExce

  • ASP.NET Core 使用Cookie验证身份的示例代码

    ASP.NET Core 1.x提供了通过Cookie 中间件将用户主体序列化为一个加密的Cookie,然后在后续请求中验证Cookie并重新创建主体,并将其分配给HttpContext.User属性.如果您要提供自己的登录界面和用户数据库,可以使用作为独立功能的Cookie中间件. ASP.NET Core 2.x的一个主要变化是不再存在Cookie中间件.取而代之的是在Startup.cs文件中的Configure方法中的调用UseAuthentication方法会添加设置HttpConte

  • 快速了解Python开发中的cookie及简单代码示例

    cookie :是用户保存在用户浏览器端的一对键值对,是为了解决http的无状态连接.服务端是可以把 cookie写到用户浏览器上,用户每次发请求会携带cookie. 存放位置: 每次发请求cookie是放在请求头里面的. 应用场景: ·登陆用户和密码的记住密码 ·显示每页显示的数据,以后都是按照设定的数目显示 ·投票机制 案例用户登录 创建用户登录的url url(r'^login/', views.login), 创建登录页面 代码为: <!DOCTYPE html> <html l

  • express中static中间件的具体使用方法

    如果想要在输入url后直接访问服务端的静态文件,比如css.js.文件等,就需要知道这些静态文件的定位,在express框架中express.static中间件函数可以帮助我们实现. Staic是express内置中间件函数,服务于静态文件,基于静态服务.Staic函数封装在serve-static模块当中,serve-static模块抛出的serveStatic就是static方法. 上面注释说明了方法的作用,大概是说该中间件函数为给定根目录的文件提供服务,要服务的文件将通过将req.url与

  • PHP Pipeline 实现中间件的示例代码

    Pipeline 设计模式 水管太长,只要有一处破了,就会漏水了,而且不利于复杂环境弯曲转折使用.所以我们都会把水管分成很短的一节一节管道,然后最大化的让管道大小作用不同,因地制宜,组装在一起,满足各种各样的不同需求. 由此得出 Pipeline 的设计模式,就是将复杂冗长的流程 (processes) 截成各个小流程,小任务.每个最小量化的任务就可以复用,通过组装不同的小任务,构成复杂多样的流程 (processes). 最后将「输入」引入管道,根据每个小任务对输入进行操作 (加工.过滤),最

  • node.js+express留言板功能实现示例

    目录 留言板 所需类库 开源项目 项目结构 留言板 基于nodejs+express+art-template的留言板功能.包含列表界面.添加界面和发送留言功能. 所需类库 直接copy以下package.json 然后直接 npm install 或者yarn install 即可. package.json所需内容如下. { "name": "nodejs_message_board", "version": "2021.09&qu

  • golang Gin上传文件返回前端及中间件实现示例

    目录 上传文件 文件返回给前端 中间件 中间件调用两种方式 单个中间件 多个中间件 上传文件 package main import ( "fmt" "github.com/gin-gonic/gin" ) func main() { router := gin.Default() // 给表单限制上传大小 (默认 32 MiB) // router.MaxMultipartMemory = 8 << 20 // 8 MiB router.POST(&q

  • express结合nodejs开启服务示例模版

    目录 express服务端 express客户端 express模版 express服务端 //用node开启服务 const express = require('express') const app = express() //const sum = require("./sum") # 方法单独封装成文件 var bodyParser = require("body-parser") app.use(bodyParser()) //执行的方法 functio

  • node.js express和koa中间件机制和错误处理机制

    目录 一.前言 二.中间件问题解析 三.错误逻辑捕获 3.1 express的错误捕获逻辑 3.2 同步逻辑错误获取的底层逻辑 3.3 异步逻辑错误获取的底层逻辑 3.4 koa的错误获取逻辑 一.前言 大家可能都知道koa是express核心原班人马写的,那么他们为什么要在express后再造一个koa的轮子呢? 今天就给大家带来一些分析.希望能够起到一个抛砖引玉的作用. 其实,这个题目也可以这么问, express有什么缺点? koa解决了一些express的什么问题? 这也在一些面试题中会

随机推荐