web safe csrf

在 web 应用上存在很多安全风险，如 csrf（XSRF），既伪造用户请求向网站发起恶意请求，是一种对网站的恶意利用。

通常防御方式都是服务器分发凭证，每次提交请求或者表单时带上凭证给服务器校验是否为恶意的请求

常用的防范方案

• 对于服务端渲染的表单页面可以把 token 渲染及隐藏在特定的地方，from 表单提交的时候把该 token 通过约定的参数带给后台
• 将 token 设置在 Cookie 中，在提交 post 请求的时候提交 Cookie，并通过 header 或者 body 带上 Cookie 中的 token，服务端进行对比校验
• 将 token 存在 custom header 上，服务端通过校验请求自定义头部字段值
• 在链接 url 上带上 token 参数

Example

基于 koa 框架采用服务端 setCookie 的方式来讲解

步骤

• 服务器接受到请求，通过响应页面时将 token 渲染到页面上的 form 隐藏域中<input type="hidden" name="_csrf" value="xxxx">
• 服务端将 token 设置 cookie 带回客户端response headers -> Set-Cookie: xxx
• 当用户发送 GET 或者 POST 请求时带上_csrf参数（对于 Form 表单直接提交即可，因为会自动把当前表单内所有的 input 提交给后台，包括_csrf）
• 后台在接受到请求后解析请求的 cookie 从 session 中 获取 secret 的值，然后和用户请求提交的 _csrf 做解析比较，如果相等表示请求是合法的

所需 middleware

koa-session

option

• key，cookie key，默认 koa:sess
• maxAge，存储时间，默认 1 小时
• overwrite，覆盖同名的 cookie，默认允许
• httpOnly，仅服务器可以访问 cookie，不予许客户端 js 访问，默认开启
• signed，安全性相关，koa 的 cookie 本身带了安全机制的签名app.keys 密钥，通过ctx.cookies.set('name', 'tobi', { signed: true })就可以设置，对于 cookie 默认开启签名
• rolling，强制在每个响应中设置会话标识符 cookie。 过期被重置为原始的 maxAge，重置到期倒计时。默认关闭。
• renew，会话即将过期时更新会话。默认关闭
• store，外部存储
• encode，自定义编码
• decode，自定义解码

koa-session 默认的 session 存储方式 cookie，同时也支持外部存储默认配置下，会使用 cookie 来存储 session 信息，也就是实现了一个”cookie session”。这种方式对服务端是比较轻松的，不需要额外记录任何 session 信息，但是也有不少限制，比如大小的限制以及安全性上的顾虑。用 cookie 保存时，实现上非常简单，就是对 session(包括过期时间)序列化后做一个简单的 base64 编码。其结果类似

koa:sess=eyJwYXNzcG9ydCI6eyJ1c2VyIjozMDM0MDg1MTQ4OTcwfSwiX2V4cGlyZSI6MTUxNzI3NDE0MTI5MiwiX21heEFnZSI6ODY0MDAwMDB9;

在实际项目中，会话相关信息往往需要再服务端持久化，因此一般都会使用外部存储来记录 session 信息。外部存储可以是任何的存储系统，可以是内存数据结构，也可以是本地的文件，也可以是远程的数据库。但是这不意味着我们不需要 cookie 了，由于 http 协议的无状态特性，我们依然需要通过 cookie 来获取 session 的标识(这里叫 externalKey )。koa-session 里的 external key 默认是一个时间戳加上一个随机串，因此 cookie 的内容类似

koa:sess=1517188075739-wnRru1LrIv0UFDODDKo8trbmFubnVmMU

koa-csrf

原理：

koa-csrf 会在 session 中保存一个secret字段，创建一个新的密钥。

1

ctx.session.secret = ** (Create a new secret key synchronously)

使用密钥生成 token，由于每次请求都是重新生成 salt，因此每次 token 都不一样

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# secret是上面生成的密钥
# salt是salt是随机生成的字符串，长度可自定
ctx.csrf = token = salt + '-' + hash(salt + '-' + secret)

# hash函数源码
function hash (str) {
  return crypto
    .createHash('sha1')
    .update(str, 'ascii')
    .digest('base64')
    .replace(PLUS_GLOBAL_REGEXP, '-')
    .replace(SLASH_GLOBAL_REGEXP, '_')
    .replace(EQUAL_GLOBAL_REGEXP, '')
}

验证的时候，只需要取出 token 头部的 salt，再从 session 中取出 secret,再生成 expected，与 token 对比

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 校验函数
function verify (secret, token) {
  if (!secret || typeof secret !== 'string') {
    return false
  }

  if (!token || typeof token !== 'string') {
    return false
  }

  var index = token.indexOf('-')

  if (index === -1) {
    return false
  }

  var salt = token.substr(0, index)
  var expected = this._tokenize(secret, salt) # _tokenize函数为生成token

  return compare(token, expected) # 判断是否一致
}

添加中间件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

...
# 添加session会发机制中间件
this.app.use(
  session(
    {
      key: config.cookie, // cookie key
      maxAge: 86400000, // 存储时间，默认1小时
      overwrite: true, // 覆盖同名的cookie
      httpOnly: true, // 仅服务器可以访问cookie，不予许客户端js访问
      signed: true, // 安全性，签名
      rolling: false,
      renew: false
    },
    this.app
  )
);
# 添加CSRF中间件
this.app.use(
  new CSRF({
    invalidSessionSecretMessage: 'Invalid session secret',
    invalidSessionSecretStatusCode: 403,
    invalidTokenMessage: 'Invalid CSRF token',
    invalidTokenStatusCode: 403,
    excludedMethods: ['GET', 'HEAD', 'OPTIONS'],
    disableQuery: false
  })
);
...

创建 ejs 模板，其中_csrf认证的字段

1
2
3
4
5
6

<form action="/csrf/register" method="POST">
  <input type="hidden" name="_csrf" value="<%= csrf %>" />
  <input type="email" name="email" placeholder="Email" />
  <input type="password" name="password" placeholder="Password" />
  <button type="submit">Register</button>
</form>

ctx.csrf带有生成的 token

1
2
3
4
5
6
7
8

async index(ctx: any) {
  if (ctx.method === 'GET') {
    await ctx.render('csrf', {
      title: 'web safe csrf',
      csrf: ctx.csrf
    });
  }
}

第一次访问的时候服务器会响应 setCookie，后面请求都会

提交时候把_csrf字段带给服务器校验

项目 demo 地址，yarn run csrf

相关链接

koa-session 基础知识（写的还是不错）
聊聊 CSRF（另一种实现方式）

json-web-token

json-web-token，简称jwt。是服务端开发的认证的一种方式，是一种基于JSON的、用于在网络上声明某种主张的令牌（token）。JWT通常由三部分组成: 头信息（header）, 消息体/载荷（payload）和签名（signature）。

header中的内容指定的是jwt的签名算法

1
2
3
4

{
  "typ": "JWT", // 类型
  "alg": "HS256" // 算法，默认HS256算法。
}

payload这一部分为实体的状态，每个claim包含传输的信息，以及用于服务验证的信息。即里面可以存我们想要自定义验证的信息（如我们可以用户的id等需要使用的数据），可以包含规范定义的claim的信息。

1
2
3
4
5
6
7

{
  "iss": "MRLYJ",
  "iat": 1416794645,
  "exp": 1448338978,
  "aud": "gopeak.cn",
  "sub": "jwt",
}

• iss: jwt的发行者（可选）
• sub: 主题（可选）
• aud: jwt的接收者（可选）
• jti: 令牌的唯一标识符（可选）
• exp: 过期时间，numericData类型，Unix时间戳（可选）
• iat: 签发时间，numericData类型，Unix时间戳（可选）
• nbf: 有效起始时间（当前时间在nbf里的时间之前，则Token不被接受），numericData类型，Unix时间戳（可选）

signature签名

生产token具体步骤

1
2
3
4
5
6
7
8
9
10
11

# 先加头部信息的JSON对象进行[base64编码]
header = encodeBase64(header)
# 再把载体信息的JSON对象进行[base64编码]
payload = encodeBase64(payload)
# 需要提供一个secret（密钥），进行签名操作
key = 'secretkey'
signature = HMAC-SHA256(key, encodeBase64(header) +
'.' + encodeBase64(payload))
# 最后生成的令牌
token = encodeBase64(header) + '.' +
encodeBase64(payload) + '.' + encodeBase64(signature)

jwt传输到服务端的方式相对传统方式比较灵活的，实际场景中，我们接受到服务端认证后返回的token，可以通过cookie或者http请求中自定义头部信息。在通常情况下，大部分会选择头部方法，由于cookie很容易受安全和跨域的影响。

头部规范

1

Authorization: Bearer eyJhbGci...

基于node服务端的实现

所需

• koa2 框架
• koa-jwt 基于koa框架的jwt中间件
• jsonwebtoken 用于生产token令牌和验证token有效性

koa-jwt

用来校验权限和解析token用的

jwt(obj1).unless(obj2)

• obj1
• secret，密钥
• passthrough
• key，附属在ctx.state上的属性，存放解析后的数据
• obj2
• path，数组类型，设置忽略校验的路径

jsonwebtoken

jsonwebtoken是基于node实现jwt功能的一个库

jwt.sign(payload, secretOrPrivateKey, [options, callback])

• payload: 载体，类型为object、buffer、string，对于使用exp字段时必须是object。
• secretOrPrivateKey: 密钥。类型可以查看官方github文档
• option
• algorithm (default: HS256)
• expiresIn: expressed in seconds or a string describing a time span zeit/ms. Eg: 60, “2 days”, “10h”, “7d”
• notBefore: expressed in seconds or a string describing a time span zeit/ms. Eg: 60, “2 days”, “10h”, “7d”
• audience
• issuer
• jwtid
• subject
• noTimestamp
• header
• keyid

其中expiresIn, notBefore, audience, subject, issuer这些属性也可以设置在payload(object), 在其分别对应的
exp,nbf,aud,sub,iss。

更多的api解释

开发

思路上实现验证的流程大体上几个步骤

• 在应用上配置koa-jwt中间件
• 当权限失效的时候，设置拦截的中间件
• 实现注册
• 实现登录

定义权限验证失败中间件

当请求经过koa-jwt校验时，如果没有token或者token已经失效了，该中间件会给出对应的状态码为401的错误信息，如果我们没自定义中间件来处理改错误时会直接返回给用户。

1
2
3
4
5
6
7
8
9
10

this.app.use((ctx, next) => {
  return next().catch((err) => {
    if (401 === err.status) {
      ctx.status = 401;
      ctx.body = 'Protected resource, use Authorization header to get access\n';
    } else {
      throw err;
    }
  });
});

koa-jwt

1
2
3
4
5
6

this.app.use(jwt({
    secret: config.secret,
  }).unless({
    path: ['/jwt/register', '/jwt/login']
  })
);

其中secret为密钥，不限字符串，文件也行。unless()用于设置那些路径不用经过校验，也就是public api（通常对于注册和登录接口是不需要校验权限的）。当校验成功时，koa-jwt会在请求的上下文，即ctx的state中添加user属性，该属性的值为解析后的数据，当然你也可以更换键名。

1
2

app.use(jwt({ secret: 'shared-secret', key: 'jwtdata' }));
# 可以通过ctx.state.jwtdata获取值

register
实现用户注册，将用户信息存入数据库。实际项目中需要加密，字段校验等措施。

login
实现用户登录，查询数据库是否该用户，然后将有关数据通过jsonwebtoken签名生产token并返回给客户端，客户端可以通过localstorage等方式将token存储在本地存储，在每次的 HTTP 请求中，都将 token 添加在 HTTP Header Authorazition: Bearer token 中。后端每次经过koa-jwt去验证该token的正确与否。只有token正确后才能访问到对应的资源。

1
2
3
4
5

jsonwebtoken.sign({
    data: user._id,
  }, secret, {
  expiresIn: 60 * 2, // 设置token有效期
})

secret为密钥，记住这里的secret必须要与中间件jwt()中的secret 一致。

users
实现获取用户信息，我们需要在头部自定义Authorization字段，就可以获取对应的资源。

1

Authorization: Bearer ...(token)

项目地址，运行npm run jwt

Debug

node的调试方式

打日志

通过使用console.log方法，此方式相当便捷，当相对于难点的bug还是比较无力。

node自带的debugger调试器

官方文档debugger

基于TCP的协议，通过commod界面可以对nodejs脚本进行调试

1
2
3
4

# 旧版的node
node debug **.js
# 最新的node
node inspector **.js

运行后终端出现commod界面

调试

• cont, c - 继续执行
• next, n - 下一步
• step, s - 跳进函数
• out, o - 跳出函数
• pause - 暂停运行代码（类似开发者工具中的暂停按钮

设置断点

• 可以通过文本打添加debugger
• setBreakpoint(), sb() - 在当前行设置断点
• setBreakpoint(line), sb(line) - 在指定行设置断点
• setBreakpoint(‘fn()’), sb(…) - 在函数体的第一条语句设置断点
• setBreakpoint(‘script.js’, 1), sb(…) - 在 script.js 的第 1 行设置断点
• clearBreakpoint(‘script.js’, 1), cb(…) - 清除 script.js 第 1 行的断点

执行

• run - 运行脚本（调试器开始时自动运行）
• restart - 重新启动脚本(每次设置完断点后可以运行此命令方便点)
• kill - 终止脚本

node inspect和node --inspect的区别？
node inspect启动是command界面操作debug方式，而node --inspect可以上 Chrome 的开发者工具附加到 Node.js 实例以用于调试和性能分析，这是由 V8 的检查器集成来的。

中规中矩，还是在编辑器上设置断点调试才是最方便的，不过多学中node debug方式有益无害。

node-inspector

这是社区提供的优秀的debugging工具。
Node Inspector 是 Node.js 应用程序的调试器接口，通过它可以使用 Blink（Chrome 浏览器内核）开发工具来进行 debugging。

1
2
3
4

# 安装
npm install -g node-inspector
# 启动
node-debug **.js

node-debug 命令将在默认浏览器中加载 Node Inspector。

node inspector仅使用于chrome和opera，若是其它浏览器需要在打开inspect页面

node自带新的方式

官方文档command inspect参数选项

V8检查器集成允许Chrome DevTools和IDE等工具调试和配置Node.js实例。 这些工具通过tcp端口附加到Node.js实例，并使用Chrome Debugging Protocol调试协议进行通信。

可以是用此方式代替node-inspector工具的使用。

1

node --inspect **.js

与--inspect-brk对比
--inspect-brk会在应用代码的第一行断开，方便从头开始调试

要求：

• Node.js 6.3+
• Chrome 55+
• Enable a new way of Node.js debugging in Chrome
• 在chrome输入chrome://flags/#enable-devtools-experiments
• 开启Developer Tools experiments
• 重启Chrome
• 打开Chrome的DevTools->Setting->Experiments 选项（在重启之后它开始可见）
• 按6次’SHIFT’以显示隐藏的实验功能
• 选中 “Node debugging”
• 打开/关闭 DevTools

最新版的chrome已经没有Node debugging，默认启动

use

运行node --inspect **.js
终端输出

打开chrome，输入chrome://inspect/，如下选择你对应的inspect

调试

IDE

使用IDE工具上自带的debug功能进行调试。

推荐使用vscode

也可以使用其它的编辑器webstorm等进行debug。