【前端安全】从需求分析开始，详解前端加密与验签实践
最近在复盘项目的时候，想到了之前做的关于前端加密与验签的需求，感觉这块很少有文章介绍，所以我就把这块内容做一下整理，希望可以帮助到后面有这一块需求的朋友。
后文你会看到：
- 需求分析与技术选型
- RSA 加密实践
- RSA + SHA256 验签实践
- 项目实践中的存在的坑点
- 如何处理依赖包体积过大问题
首先我们先从需求开始☟
为什么要引入加密与验签？
这个要从两件事情说起
- 公司委托第三方安全检测扫描发现账号登录部分存在安全漏洞，也就是密码安全问题；
- 我们发现项目的下单接口经常被某平台恶意刷单；
于是就有了我们的需求：
- 账号登录需要对密码做加密处理；
- 下单接口要避免被恶意刷单影响；
需求分析与技术选型
需求1：
这里的要求很明确，需要对登录密码做加密处理，所以接下来我们就要找一种合适的加密方案。这里我们没有过多纠结，直接选择目前比较常用且相对安全的RSA 非对称加密。
需求2：
在分析需求之前，我们首先要看一下恶意刷单是怎么做的。
当对方了解了我们下单接口所需的参数，以及基本的后端校验规则后，其就可以直接跳过前端校验，对参数稍作改动，通过程序频繁调用下单接口。
要阻止这个行为，我们要做下面两点：
第一点 接口节流处理，这个是后端处理的，这里不做介绍；
第二点 下单接口验签，这个需要前端生成签名和后端进行验签比对，具体的前后端验签比对的；
接下来的问题就是要再选择一种适合做验签的技术方案，目前处理验签的方案有很多，常见的例如MD5 、SHA1 、SHA256等。选择哪一种，我们必须要结合到具体的使用场景去分析。
首先，我需要处理的这个项目项目是服务 3000 多家景区的 Saas 平台，下单接口的并发量比较大，所以在并发性能上有所要求（这里的并发的压力是在后端）。其次，这个需求的根本是为了避免被刷单，所以安全性也是重要的衡量标准。
接下来，后端同事根据约定的签名规则使用 MD5、SHA1、SHA-256 签名，在相同次数下生成签名的耗时数据对比表如下：
| # | 100次（毫秒） | 10000次（毫秒） | 1000000次（毫秒） |
|---|---|---|---|
| MD5 | 161 | 9018 | 883387 |
| SHA1 | 166 | 8980 | 886486 |
| SHA256 | 2121 | 10590 | 931271 |
通过上面的数据对比表我们可以看出：在执行字数比较少的时候，MD5 与SHA1 执行效率明显更优，但是在执行次数到达10000次以上之后，三者执行的总时间差距并没有拉大。最后通过安全性和服务器承受能力两个维度考量 ，最终确定使用 SHA256 来生成签名。虽然它相对会比较损耗性能，但是目前的后端服务器是完全可以承受的，另外它也可以带来更好的安全性。
这里，我们就确定好了具体的技术方案，接下来进入具体加密与验签实践
RSA 加密实践
简介
1977年，三位数学家 Rivest、Shamir 和 Adleman 设计了一种算法，可以实现非对称加密。这种算法用他们三个人的名字命名，叫做RSA算法。从那时直到现在，RSA算法一直是最广为使用的"非对称加密算法"。毫不夸张地说，只要有计算机网络的地方，就有RSA算法。
更多 RSA 算法原理，可以打开下方传送门：
[RSA算法原理（一）]：http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.html
[RSA算法原理（二）]：http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html
工作流程
为了方便大家理解，我先画一个 RSA 加密的工作流程图。
具体步骤：
- step1：用户输入信息，前端使用公钥进行加密
- step2：通过 http 请求将密文发送到后端
- step3：后端使用私钥将密文进行解密
这里大家应该注意到了两个关键词：
公钥——可以公开的秘钥，一般为前端使用，对文本加密使用
私钥——不可公开的秘钥，一般留给后端解密使用，对已加密文本进行解密
补充：其实也可以通过私钥加密，公钥解密，只要保持一部分私有就可以
辅助工具
- 工具1：RSA 公私钥生成网站：http://www.bejson.com/enc/rsa/
我们看看生成好的样子
// 公钥
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA5iTKIXHGuDNG9x
......
3QIDAQAB
-----END PUBLIC KEY-----
// 私钥
-----BEGIN PRIVATE KEY-----
MIIEuwIBADANBgkqhkiG9w0BAQEFAASCBKUwggShAgEAAoIBAQDmJMohcc
......
8jKcsEAozBoeXJiSx0+D
-----END PRIVATE KEY-----
这里已经加好了公私钥的注释，这个我们需要保留，后面再开发中会使用到。
- 工具2：RSA 加密与解密校验网站：点击这里
加密测试：选择 RSA公钥加密 >> 输入公钥 >> 输入待加密内容 >> 加密结果
图中我们输入了hello world加密得到：
cTX3VGKEjxGYl0d35JfENIPgtB3amNEWbjjlMw8vMcIUCzM6gHvZwbTjkHvuKDKJGQf0Upcb1zRVsDwWYb8MBYlOia72pme29M6UuRyt4FYy0mL8GTLNJUMcGP+lI9jb2tQ7NmToufV2RI9c666P6B+xx5bT4vHEgI+hs4xKny8=
解密测试：选择 RSA私钥解密 >> 输入私钥 >> 输入待解密内容 >> 原文本
解密之后，我们重新见到了原文：hello world ✌
代码中的实现
这里我们需要借助 JSEncrypt 来完成前端的 RSA 加密工作
- 安装依赖
npm install jsencrypt --save
- 创建我们的类方法
// 新建文件 /common/myEncrypt.js
import { JSEncrypt } from 'jsencrypt';
class myEncrypt {
constructor() {
// 这里不要去掉注释
this.pubsKey = `
-----BEGIN PUBLIC KEY-----
SIb3DQEBAQUAA4GNADCBiQKBgQDI5kmdW9rmxQlTraZ6Wx+C7kYR......省略
-----END PUBLIC KEY-----
`;
}
/**
* RSAj加密
* @param {String} text 需要加密的文本
* @returns {String} 加密后的文本
*/
setRSA(text) {
// 新建JSEncrypt对象
const encryptor = new JSEncrypt();
// 设置公钥
encryptor.setPublicKey(this.pubsKey);
// 加密数据
const resultText = encryptor.encrypt(text);
// 转码,避免特殊符号在传输过程中丢失
return encodeURIComponent(resultText);
}
}
export default new myEncrypt();
- 加密处理
// 引入该方法
import encrypt from '@/common/myEncrypt';
// 对用户密码进行加密
const password = '996ICU';
const rsaPass = encrypt.setRSA(password);
注意：在微信小程序中无法使用 window 对象，直接引用依赖处理会报错，这里需要对 jsencrypt 进行兼容性改造，代码量很大，这里就不贴了。兼容方案看这里☞在小程序使用jsEncrypt.js
SHA256 生成签名
简介
SHA-2，名称来自于安全散列算法2（英语：Secure Hash Algorithm 2）的缩写，一种密码散列函数算法标准，由美国国家安全局研发，由美国国家标准与技术研究院（NIST）在2001年发布。属于SHA算法之一，是SHA-1的后继者。其下又可再分为六个不同的算法标准，包括了：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。
更多 SHA256 算法原理看这里☞一文读懂SHA256算法原理及其实现
工作流程
话不多说，直接上图
具体步骤：
- step1：用户提交订单，前端生成签名
- step2：后端在网关层，依据双方约定规则生成签名，进行比对
- step3：比对通过进行正常下单流程
这里重点讲一下，前端部分生成签名的规则
- 将接口参数转换为字符串 A；
- 生成随机字符串作为盐值 S；
- 首先对接口参数字符串进行处理生成签名，再将盐值与之前生成的签名合并，继续使用 SHA256 算法，生成新签名，公式为
sha256(sha256(A)+S)； - 使用 RSA 对盐值进行加密；
- 将加密后的盐值与生成的验签传给后端，方便进行校验；
代码中的实现
这里我推荐使用 hash.js 中的 sha256 模块来生成验签，为什么选择它，后面会进行介绍。
- 安装依赖
// SHA256 生成验签
npm install hash.js --save
- 生成签名
// common/myEncrypt.js
// myEncrypt 类中
/**
* 生成验签
* @param {Object} params 请求参数
* @param {Boolean} isJson 是否为json类型请求
*/
setSign(params, isJson) {
// 随机字符串，这里省略生成规则
const salt = ..sfoshx2434..;
// 对接口参数进行处理,这里可以自己根据与后端预定的规则处理一下
const paramsStr = dataToString(params, isJson);
const sign = this.signData(paramsStr, salt);
const sk = this.setRSA(salt);
return {
sk,
sign,
};
}
/**
* 按照约定规则生成验签
* @param {String} data 需要加密的数据
* @param {String} salt 盐值
*/
signData(data, salt) {
const once = sha256().update(data).digest('hex');
const seconed = sha256().update(once + salt).digest('hex');
return seconed;
}
- 接口中使用
import myEncrypt from '@/common/myEncrypt';
// 验签加密处理 params 为接口参数 jsonFlag 为参数类型
const {sk, sign} = myEncrypt.setSign(params, jsonFlag);
踩坑盘点
- RSA 加密后的密文需要使用 encodeURIComponent 转码后传给后端，因为密文中会存在 + 号之类的特殊符号，在接口传输过程中容易丢失；
- RSA 加密所使用的依赖 jsencrypt 因为包含 window 对象，我们在小程序中使用，需要进行兼容性处理；
- 刚开始选择提供 SHA256 算法的依赖包是最常用的 crypto-js，后面在小程序上使用的时候，包体积直接爆掉，crypto-js 的体积为 434KB，而现在我们用的 hash.js 的体积只有 41.7KB，其实中间我还尝试过使用通过 js-sha256 来生成验签，虽然体积也比较小，但是经常会出现验签后后端无法匹配上的问题，所以只能弃用。
后记
其实前端加密或者做接口验签都不会是绝对的安全，加密可以破解，签名可以模仿，做这些工作只不过是给那些想搞事情的人，制造点困难。最后希望这篇文章可以帮助到大家，谢谢❤
