Babel 不但完成了 AST 的解析工作,而且由于其编译 js 代码的使命,它还提供了一套完善的 visitor 插件机制用于扩展,而种种的这些都为我们的代码扫描工作创造了完美的条件。
const parser = require(‘@babel/parser’);const traverse = require(‘@babel/traverse’).default;// 编写自定义规则插件const visitor = {};// 源代码const code = var str = "hello world";
;// code -> astconst ast = parser.parse(code);// 用自定义规则遍历ast(即代码扫描)traverse(ast, visitor);
如上所示,利用 Babel 提供的能力来做代码扫描就是如此简单,唯一要做的就是结合我们自定义的资损/舆情规则来编写 Babel 开放的 visitor 插件。(有关"如何自定义 Babel 插件"可以查看这份Babel插件手册,该文档介绍了如何编写一个 Babel 自定义插件,也是后文的基础 )
解决问题
在简单介绍完 AST 后,让我们回归到本文的核心问题:面对以下这些可能发生资损故障的场景,什么"千奇百怪"的代码都可能出现,我们该如何做检测呢?
-
前端金额赋默认值
-
前端金额计算错误
-
前端写死固定金额/积分
-
…
▐ 寻找"金额"
根据上文的描述,我们知道 “金额” 在前端就是一个高危分子,有关它的操作都容易造成资损。
一方面,这是因为 js 的数字"精度"问题(老生常谈的 “0.1 + 0.2 = 0.300000004” 问题);另一方面,金额计算本就应该放在服务端更安全。
因此,为了避免潜在的风险,所有的金额计算操作都应该由服务端计算后下发给前端,而前端只做展示作用。这也正是代码扫描的关键一步,我们需要检测代码中是否含有金额的计算操作。
为了找出代码中的金额计算,首先要做的就是识别代码中的 “金额变量”。对于这个问题,我们可以使用简单粗暴却又行之有效的方法:正则匹配。由于大家的金额变量名取得都比较有规律(就比如 xxxPrice,PS:可继续扩展),我们可以用一个简单的正则进行匹配:
const WHITE_LIST = [‘price’]; // TODO: 可扩展const PRICE_REG = new RegExp(WHITE_LIST.map(s => s + ‘$’).join(‘|’), ‘i’);
根据 Babel 解析得到的 AST,由于变量名均是 Identifier 类型的节点,所以我们可以用一个简单的规则来匹配所有的金额变量:
const isPrice = str => PRICE_REG.test(str);const visitor = { Identifier(path) { const {id} = path.node; if(isPrice(id.name)) { // 金额变量 匹配成功! } }};
▐ 小试牛刀
解决金额变量的定位问题后,我们再来看看 “金额赋默认值” 的检测问题。
// case 1: 直接赋默认值const price = 10;// case 2: ES6解构语法赋默认值const {price = 10} = data;// case 3: "||"运算符赋默认值const price = data.price || 10;// …
如上所示,虽然金额赋默认值有多种写法,但是当它们被解析成 AST 后,我们却可以将其逐一击破。说到这,就不得不再次祭出 astexplorer 神器将上述代码分析一波。
case 1: 直接赋默认值
根据上面的 code vs AST 关系图可以看到,我们只要找到 VariableDeclarator 节点,且同时满足 id 是金额变量,init 是大于 0 的数值节点这两个条件即可。代码如下:
const t = require(‘@babel/types’);const visitor = { VariableDeclarator(path) { const {id, init} = path.node; if( t.isIdentifer(id) && isPrice(id.name) && t.isNumericLiteral(init) && init.value > 0 ) { // 直接赋默认值 匹配成功! } }};
case 2: ES6解构语法赋默认值
经过对上一个 case 的解析,我们其实已经初步掌握了如何用 AST 做代码扫描的要领,再来看 ES6解构语法赋默认值 的检测。观察上面的关系图,我们可以得出结论:找到 AssignmentPattern 节点,且同时满足 left 是金额变量,right 是大于 0 的数值节点这两个条件。代码如下:
const t = require(‘@babel/types’);const visitor = { AssignmentPattern(path) { const {left, right} = path.node; if ( t.isIdentifer(left) && isPrice(left.name) && t.isNumericLiteral(right) && right.value > 0 ) { // ES6解构语法赋默认值 匹配成功! } }};
case 3: "||"运算符赋默认值
经过上面的两个例子说明,想必 "||"运算符赋默认值 的检测已经不在话下。不过这里需要特别注意一点:在实际的代码中,= 右侧的赋值表达式可能并不像例子中给的 “data.price || 10” 这般简单,而是可能夹杂着一定的逻辑运算。对于这类情况,我们需要改变策略:遍历右侧的赋值表达式中是否包含 “|| 正数” 的模式。
const t = require(‘@babel/types’);const visitor = { VariableDeclarator(path) { const {id, init} = path.node; if(t.isIdentifer(id) && isPrice(id.name)) { path.traverse({ LogicalExpression(subPath) { const {operator, right} = subPath.node; if( operator === ‘||’ && t.isNumericLiteral(right) && right.value > 0 ) { // "||"运算符赋默认值 匹配成功! } } }); } }};
▐ 变量追踪
根据上文的介绍,其实一些基础规则的代码扫描已经可以实现,然而现实中提交的代码往往会比上面给出的例子复杂得多。就拿金额计算来说,我们可以用下面的 visitor 来匹配任何有关金额的四则运算:
const t = require(‘@babel/types’);const Helper = { isPriceCalc(priceNode, numNode, operator) { return ( t.isisIdentifier(priceNode) && isPrice(priceNode.name) && (t.isNumericLiteral(numNode) || t.isIdentifier(numNode)) && [‘+’, ‘-’, ‘*’, ‘/’].indexOf(operator) > -1 ); }};const checkPriceCalcVisitor = { BinaryExpression(path) { const {left, right, operator} = path.node; if( Helper.isPriceCalc(left, right, operator) || Helper.isPriceCalc(right, left, operator) ) { // 金额计算 匹配成功! } }}
然而,上面的规则却只能检测对金额变量的直接运算,一旦碰上函数调用就无效了。比如以下代码:
const fen2yuan = (num) => { return num / 100;};const ret = fen2yuan(data.price);
这是一个再简单不过的分转元金额单位换算函数,由于形参不具备金额变量名的特征,先前的规则将无法成功检测。为了解决 “变量追踪” 这个问题,我们还需引入 Babel 中的 Scope 能力。根据 官方文档 介绍,一个 scope 可以被表示成:
// 一个scope{ path: path, block: path.node, parentBlock: path.parent, parent: parentScope, bindings: […]}// 其中的一个binding{ identifier: node, scope: scope, path: path, kind: ‘var’, referenced: true, references: 3, referencePaths: [path, path, path], constant: false, constantViolations: [path]}
有了上面这些信息,我们就可以查找任何一个变量的声明以及任何一个绑定的所有引用。什么意思呢?
前文提到的变量追踪问题在于:原本是金额变量名的实参在函数调用时,形参可能变成了和金额无关的变量名。但是现在,我们可以借助 scope 顺藤摸瓜,先找到该函数的声明,然后根据参数的位置信息重新建立实参和形参之间的关系,最后再用 binding 检测函数体内是否含有对形参的四则运算。
const t = require(‘@babel/types’);const Helper = { // … findScope(path, matchFunc) { let scope = path.scope; while(scope && !matchFunc(scope)) { scope = scope.parent; } return scope; }};const checkPriceCalcVisitor = { // … CallExpression(path) { const {arguments, callee: {name}} = path.node; // 匹配金额变量作为实参的函数调用 const priceIdx = arguments.findIndex(arg => isPrice(arg)); if(priceIdx === -1) return; // 寻找该函数的声明节点 const foundFunc = Helper.findScope(path, scope => { const binding = scope.bindings[name]; return binding && t.isFunctionDeclaration(binding.path.node); }); if(!foundFunc) return; // 匹配实参和形参之间的位置关系 const funcPath = foundFunc.bindings[name].path; const {params} = funcPath.node; const param = params[priceIdx]; if(!t.isIdentifier(param)) return; // 检测函数内是否有对形参的引用 const renamedParam = param.name; const {referencePaths: refPaths = []} = funcPath.scope.bindings[renamedParam] || {}; if(refPaths.length === 0) return; // 检测形参的引用部分是否涉及金额计算 for(const refPath of refPaths) { // TODO: checkPriceCalcVisitor支持指定变量名的检测 refPath.getStatementParent().traverse(checkPriceCalcVisitor); } }}
如上所示,借助 scope 和 binding 的能力,我们就基本解决了 “变量追踪” 问题。
检测效果
经过前文对基本原理介绍后,我们再来看下实际的检测效果。从代码扫描上线之后到本次 618 活动目前为止,我们对一批前端代码仓库进行了扫描,共有 1/7 的仓库都命中了规则。下面挑了几个例子来感受下藏在代码中的"毒药"~
Bad code 1:
let { // … rPrice = 1} = res.data || {};
如上所示,当服务端返回的数据异常时,一旦 res.data 为空,那么 rPrice 就会获得默认值 1。经过代码分析后发现 rPrice 代表的就是红包面额,因此理论上就可能会造成资损。
Bad code 2:
class CardItem extends Component { static defaultProps = { itemPrice: ‘99’, itemName: ‘…’, itemPic: ‘…’, // … } // …}
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
![img](https://i-blog.csdnimg.cn/blog_migrate/d907d88c7273ac8488be6542325adfeb.jpeg)
总结
虽然面试套路众多,但对于技术面试来说,主要还是考察一个人的技术能力和沟通能力。不同类型的面试官根据自身的理解问的问题也不尽相同,没有规律可循。
上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料
有些面试官喜欢问自己擅长的问题,比如在实际编程中遇到的或者他自己一直在琢磨的这方面的问题,还有些面试官,尤其是大厂的比如 BAT 的面试官喜欢问面试者认为自己擅长的,然后通过提问的方式深挖细节,刨根到底。
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》,点击传送门即可获取!
转存中…(img-fQDgXOrB-1711961111585)]
上面提到的关于这些JAVA基础、三大框架、项目经验、并发编程、JVM及调优、网络、设计模式、spring+mybatis源码解读、Mysql调优、分布式监控、消息队列、分布式存储等等面试题笔记及资料
有些面试官喜欢问自己擅长的问题,比如在实际编程中遇到的或者他自己一直在琢磨的这方面的问题,还有些面试官,尤其是大厂的比如 BAT 的面试官喜欢问面试者认为自己擅长的,然后通过提问的方式深挖细节,刨根到底。
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》,点击传送门即可获取!