基于工程实践的需求分析和概念原型
一、前言
本文是基于工程实践——基于模糊测试的智能合约安全漏洞检测项目,进行用例建模和业务领域建模,以及数据建模,最终形成概念原型。
参考资料:https://gitee.com/mengning997/se/blob/master/README.md#%E4%BB%A3%E7%A0%81%E4%B8%AD%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B
二、需求分析
智能合约是运行在区块链共识协议之上的程序代码,其能够使人们在最小化彼此之间信任的同时达成协定。如今,数百万的智能合约被部署在各种各样的去中心化应用中,然而存在于智能合约中的安全漏洞却对这些去中心化应用造成了巨大的威胁。
智能合约的运行依赖于底层的区块链平台以及其它协作合约,合约开发者没能完全理解这些合约之间以及合约与底层区块链平台之间隐含的关系;智能合约的编程语言与运行环境对于合约开发者来说都是全新的,且这些工具还不够成熟,合约开发者没能很好的处理这些工具自身的不足;区块链具有不可篡改的性质,智能合约在被部署至区块链平台之后难以更新。
本项目提出了ContractFuzzer工具,该工具是一个全新的针对于以太坊智能合约安全漏洞检测的模糊测试工具,其能够根据智能合约的ABI规范生成模糊测试输入,定义检测安全漏洞的测试预言,通过对以太坊虚拟机插桩记录智能合约的运行时状态,分析日志并报告安全漏洞。
三、用例建模
1.用例的核心概念中首先它是一个业务过程,经过逻辑整理抽象出来的一个业务过程,这是用例的实质。在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。
2.用例的基本要素:(1)一个用例应该由业务领域内的某个参与者所触发;(2)用例必须能为特定的参与者完成一个特定的业务任务;(3)一个用例必须终止于某个特定参与者,也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
3.用例建模的基本步骤:(1)从需求表述中找出用例,往往是动名词短语表示的抽象用例;(2)描述用例开始和结束的状态,用TUCBW和TUCEW表示的高层用例;(3)对用例按照子系统或不同的方面进行分类,描述用例与用例、用例与参与者之间的上下文关系,并画出用例图;(4)进一步逐一分析用例与参与者的详细交互过程,完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。 4.用例图如下:

四、业务领域建模
1.业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中,他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景,这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。 2.业务领域建模的基本步骤:(1)收集应用业务领域的信息。聚焦在功能需求层面,也考虑其他类型的需求和资料;(2)头脑风暴。列出重要的应用业务领域概念,给出这些概念的属性,以及这些概念之间的关系;(3)给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系;(4)将结果用 UML 类图画出来。 3.UML类图如下:
五、数据建模
User:
| 用户编号 | 用户名称 |
| id | name |
Contract:
| abi对象描述符 | 合约账户余额 |
| abi | balance |
ABI:
| 合约名称 | 合约方法签名 | 输入 | 输出 |
| name | methodSig | input | output |
六、概念原型
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。概念原型是一种虚拟的、理想化的软件产品形式。概念原型=用例+数据模型。概念原型的工作过程为:(1)分析测试智能合约的ABI接口以及字节码,提取ABI函数的每一个参数的数据类型以及ABI函数中所使用到的函数签名;(2)进行ABI签名分析,并根据各个智能合约所支持的函数签名将其进行索引;(3)生成与ABI规范相符的合法模糊测试输入以及越过有效边界的突变输入;(4)启动模糊测试,通过随机的函数调用,使用生成的输入调用相应的ABI接口;(5)分析模糊测试过程中生成的执行日志,检测安全漏洞。

浙公网安备 33010602011771号