当前位置:   article > 正文

AST 代码扫描实战:如何保障代码质量_ast扫描

ast扫描
 小试牛刀

解决金额变量的定位问题后,我们再来看看 “金额赋默认值” 的检测问题。

// 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: ‘…’, // … } // …}

如上所示,该代码应该是在开发初期 mock 了展示所需的数据,但是在后续迭代时又没有删除 mock 数据。一旦服务端下发的数据缺少 itemPrice 字段,所有的价格都将显示 99,这也是颗危险的定时炸弹。

Bad code 3:

const [price, setPrice] = useState(50);

如上所示,这个 hooks 的使用例子默认就会给 price 赋值 50,如果这是一个红包或券的面额,意味着用户可能就领到了这 50 元,从而也就造成了资损。

Bad code 4:

// price1为活动价,price2为原始价let discount = Math.ceil(100 * (price1 / 1) / (price2 / 1)) / 10;

先自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《Java开发全套学习资料》送给大家,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频

如果你觉得这些内容对你有帮助,可以扫码领取!

img

最后

经过日积月累, 以下是小编归纳整理的深入了解Java虚拟机文档,希望可以帮助大家过关斩将顺利通过面试。
由于整个文档比较全面,内容比较多,篇幅不允许,下面以截图方式展示 。







由于篇幅限制,文档的详解资料太全面,细节内容太多,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
0-1711201049567)]
[外链图片转存中…(img-VfJrVTS8-1711201049567)]
[外链图片转存中…(img-22EuJfp4-1711201049567)]
[外链图片转存中…(img-JFta9LuK-1711201049568)]
[外链图片转存中…(img-5oKR6aCP-1711201049568)]
[外链图片转存中…(img-ujOrlpAZ-1711201049568)]

由于篇幅限制,文档的详解资料太全面,细节内容太多,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
需要更多Java资料的小伙伴可以帮忙点赞+关注,点击传送门,即可免费领取!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/597709
推荐阅读
相关标签
  

闽ICP备14008679号