针对目标应用进行漏洞检测的方法和装置

技术领域

本说明书一个或多个实施例涉及基于区块链的去中心化应用，尤其涉及对这样的去中心化应用进行漏洞检测的方法和装置。

背景技术

区块链和智能合约吸引了大量工业界和学术界的关注。许多流行的应用程序已在区块链上利用智能合约进行运行，形成去中心化的应用。在这些应用中，一些应用可以支持用户基于通证(token)进行资源的转移、交换。然而，随着这些应用的发展，其安全性也受到挑战。攻击者有可能利用智能合约的程序缺陷，或者应用的功能bug，发起攻击，不合理地从中提取本不属于他的大量资源，从而影响应用的安全性和稳定性。

希望能有改进的方案，可以更好地对这类应用进行漏洞检测。

发明内容

本说明书一个或多个实施例描述了一种针对去中心化的应用进行漏洞检测的方法和装置，能够有效检测这类应用中的通证泄露漏洞，提升应用的安全性和稳定性。

根据第一方面，提供了一种针对目标应用进行漏洞检测的方法，所述目标应用是基于区块链的去中心化应用，且支持基于若干种类型的通证进行资源交换和转移；所述方法包括：

记录所述目标应用执行过程中涉及智能合约的交易执行轨迹，形成调用树，所述调用树包含交易节点和事件节点；交易节点之间的有向边表示父交易引发子交易；交易节点与事件节点之间的有向边表示，通过该交易发出该事件；

基于所述调用树，提取通证转移事件并挖掘各个交易涉及的角色，从而确定出发生在用户和所述目标应用之间的目标转移动作，各目标转移动作形成通证流；其中所述角色包括代表用户的用户角色和代表目标应用的应用角色；

将针对各个类型通证的所述通证流进行合并，基于合并通证流确定累积转入量和累积转出量，根据该累积转入量和累积转出量，确定是否存在通证泄露漏洞。

根据一种实施方式，所述交易执行轨迹的记录，通过修改区块链节点中部署的用于执行智能合约的虚拟机实现。

进一步的，虚拟机的修改可以包括以下中的至少一项：

在用于执行外部交易的函数中插入记录代码，以记录外部交易；

在产生内部交易的目标函数的调用处理程序中插入记录代码，以记录内部交易；

在虚拟机的Log操作中插入记录代码，以记录事件。

根据一种实施方式，基于所述调用树，提取通证转移事件并挖掘各个交易涉及的角色，从而确定出发生在用户和所述目标应用之间的目标转移动作，具体包括：

从所述调用树中提取目标子树，遍历所述目标子树，确定出与通证转移事件对应的动作作为备选转移动作；其中，所述目标子树的根节点是调用代理合约的交易节点；所述代理合约是所述目标应用中用户可直接调用的外部合约；

将预设角色沿所述调用树传递，从而确定所述调用树中涉及的各个地址的角色；

基于所述各个地址的角色，从备选转移动作中确定出用户与目标应用之间的目标转移动作。

在一个进一步的实施例中，若干种类型的通证包括第一类通证，所述第一类通证具有第一通证标准；在此情况下，遍历所述目标子树，确定出与通证转移事件对应的动作作为备选转移动作，包括：利用所述第一通证标准，从所述目标子树中识别与第一类通证转移相关的第一事件，将所述第一事件对应的事件节点替换为通证转移节点，将该节点对应的动作归入备选转移动作。

在一个实施例中，所述若干种类型的通证包括第二类通证，所述第二类通证是可以直接通过外部交易在用户之间转移的通证；在此情况下，遍历所述目标子树，确定出与通证转移事件对应的动作作为备选转移动作，包括：从所述目标子树的第一交易中检索得到通证转移信息，在第一交易对应的交易节点中插入通证转移节点，将该节点对应的动作归入备选通证转移动作。

根据一个实施例，前述将预设角色沿所述调用树传递，从而确定所述调用树中涉及的各个地址的角色，具体包括：将外部交易的发起者设置为用户角色，将代理合约设置为应用角色，按照预定方式沿所述调用树进行角色传递，所述角色传递包括，对于内部交易，如果被调用者没有被标记角色，则将调用者的角色赋予被调用者。

在一个具体例子中，所述目标转移动作记录为数据元组，所述数据元组包括，触发该动作的交易所在的区块高度，该交易在区块中的位置，转移的通证数量，转移通证的种类，动作类型；所述动作类型选自存入动作或支取动作。

根据一种实施方式，上述方法还包括：利用预设类型通证的信息和所述各个交易涉及的角色，挖掘用户之间的预设关系；相应的，确定累积转入量和累积转出量，包括：合并单个用户的通证流，得到该用户的合并通证流；在合并通证流的单个操作处，搜索与该用户存在所述预设关系的相关用户，将其归为一组，计算该组中所有用户的累积存入量和累积支取量。

进一步的，在一个实施例中，所述预设类型通证用于记录用户的质押份额，且在用户执行存入/支取操作时，所述目标应用铸造/销毁该预设类型通证；所述挖掘用户之间的预设关系，包括以下的一项或多项：

响应于第一用户调用代理合约，将所述预设类型通证转移到目标应用，而所述预设类型通证被铸造给第二用户，记录所述第一用户和第二用户具有所述预设关系；

响应于第三用户将所述预设类型通证转移给第四用户，记录所述第三用户和第四用户具有所述预设关系。

根据一个实施例，若干种类型的通证为多种类型的通证；将针对各个类型通证的所述通证流进行合并，包括：基于预先构建的换算表，将各个类型通证均换算为预设的统一价值单位，基于该统一价值单位将不同通证的通证流合并为单个流。

在一个实施例中，根据该累积转入量和累积转出量，确定是否存在通证泄露漏洞，包括：在各个动作处，基于执行该动作之前的累积转出量与累积转入量的比值，计算该动作对应的实际返还率；从多个用户的多个动作所对应的实际返还率中，确定小于预设阈值T的多个返还率，计算该多个返还率的平均值和标准差，根据该平均值和标准差确定标准返还率；将实际返还率大于所述标准返还率的动作，确定为导致通证泄露的异常动作。

根据第二方面，提供了一种针对目标应用进行漏洞检测的装置，所述目标应用是基于区块链的去中心化应用，且支持基于若干种类型的通证进行资源交换和转移；所述装置包括：

记录单元，配置为记录所述目标应用执行过程中涉及智能合约的交易执行轨迹，形成调用树，所述调用树包含交易节点和事件节点；交易节点之间的有向边表示父交易引发子交易；交易节点与事件节点之间的有向边表示，通过该交易发出该事件；

提取单元，配置为基于所述调用树，提取通证转移事件并挖掘各个交易涉及的角色，从而确定出发生在用户和所述目标应用之间的目标转移动作，各目标转移动作形成通证流；其中所述角色包括代表用户的用户角色和代表目标应用的应用角色；

检测单元，配置为将针对各个类型通证的所述通证流进行合并，基于合并通证流确定累积转入量和累积转出量，根据该累积转入量和累积转出量，确定是否存在通证泄露漏洞。

根据第三方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面所述的方法。

根据第四方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面的方法。

在本说明书的实施例中，漏洞检测方案由三个阶段组成，其从DeApp所基于的区块链获取交易数据，并输出通证泄露漏洞和相应的攻击者。第一阶段通过重放这些交易，来记录DeApp的执行轨迹。第二阶段，提取通证转移事件，并挖掘相关地址的角色(用户或应用)以及用户之间的关系，生成用户的通证流。第三阶段，合并通证流并执行异常检测，以揭示通证泄漏漏洞和相应的攻击者。通过以上方式，可以高效而准确地检测出目标应用中的通证泄露漏洞。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是区块链架构示意图；

图2示出针对DeApp的攻击交易中的通证转移示意图；

图3示出LP通证的转移函数的代码；

图4示出根据一个实施例的漏洞检测方案的框架示意图；

图5示出根据一个实施例的应用漏洞检测的方法流程图；

图6示出调用树的示意图；

图7示出在一个示例中目标应用的多种存入模式；

图8示出基于调用树确定通证流的流程；

图9示出根据一个实施例的检测装置的结构示意图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

去中心化的应用基于区块链架构而提出。如图1所示，是区块链架构示意图。在图1所示的区块链架构图中，区块链中包括多个节点，例如节点1、节点2～节点6。节点之间的连线示意性的表示Peer to Peer点对点连接。这些节点上可存储全量的账本，即存储全部区块和全部账户的状态。其中，区块链中的每个节点可通过执行相同的交易而产生区块链中的相同的状态，区块链中的每个节点可存储相同的状态数据库，又称为世界状态。

区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段(From)、接收字段(To)和数据字段(Data)。其中，在交易为转账交易的情况中，From字段表示发起该交易(即发起对另一个账户的转账任务)的账户地址，To字段表示接收该交易(即接收转账)的账户地址，Data字段中包括转账金额。在交易调用区块链中的智能合约的情况中，From字段表示发起该交易的账户地址，To字段表示交易所调用的合约的账户地址，Data字段中包括调用合约中的函数名、及对该函数的传入参数等数据，以用于在交易执行时从区块链中获取该函数的代码并执行该函数的代码。

区块链中可提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约，是发起一笔指向智能合约地址的交易，使得区块链中每个节点分布式地运行智能合约代码。需要说明的是，除了可以由用户创建智能合约，也可以在创世块中由系统设置智能合约。这类合约一般称为创世合约。一般的，创世合约中可以设置一些区块链的数据结构、参数、属性和方法。此外，具有系统管理员权限的账户可以创建系统级的合约，或者修改系统级的合约(简称为系统合约)。其中，所述系统合约可用于在区块链中增加不同业务的数据的数据结构。

在部署合约的场景中，例如，Bob将一个包含创建智能合约信息(即部署合约)的交易发送到如图1所示的区块链中，该交易的data字段包括待创建的合约的代码(如字节码或者机器码)，交易的to字段为空，以表示该交易用于部署合约。节点间通过共识机制达成一致后，确定合约的合约地址“0x6f8ae93…”，各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户，分配与该合约账户对应的状态存储，并将合约代码保存在该合约的状态存储中，从而合约创建成功。

在调用合约的场景中，例如，Bob将一个用于调用智能合约的交易发送到如图1所示的区块链中，该交易的from字段是交易发起方(即Bob)的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后，区块链中的各个节点可分别执行该交易，从而分别执行该合约，基于该合约的执行更新状态数据库。为了获得相同的世界状态，在区块链的各个节点中部署相同的虚拟机，例如EVM(Ethereum Virtual Machine)，来执行所部署的智能合约。

由上可见，在区块链中，用户和智能合约，都以地址进行标识。用户的地址和合约的地址在形式上没有区别。表示用户的账户地址称为外部账户。

由于智能合约本质上是可编写可部署、用来实现一定逻辑的程序代码，基于区块链构建的去中心化应用DeApp可以利用智能合约实现其功能。一般地，DeApp运行中所涉及的交易可划分为两种：外部交易和内部交易。外部交易是由外部账户(用户)发起的交易，而内部交易是由智能合约发起的交易。外部交易可以引发(derive)或触发以树状结构依赖的多层内部交易。相应的，DeApp所涉及的智能合约可划分为代理(Proxy)合约和内部合约。代理合约是面向用户、可以由用户通过外部交易直接调用的合约。在代理合约被调用后，在其执行过程中，可以触发调用内部合约(或称为后台合约)。此外，在智能合约执行中，可以触发预定的事件，来记录特定的行为。

去中心化应用DeApp可以利用智能合约提供越来越丰富的功能。许多DeApp中提供多种通证(token)，支持用户利用各种通证进行资源的交换、转移。资源具体可以是实体资源(资金，票卷)，虚拟资源或网络资源(流量，网盘空间等)，用户权益(例如，会员期限)等各种形式。通证可以认为是资源的标识，用于指示对应资源的数量或份额。在一些DeApp中，提供多种不同类型的通证。不同种类的通证可以指示同一类型的资源，也可以标识不同类型的资源。通常情况下，不同种类的通证可以以一定“汇率”，互相转换。

由于DeApp功能的复杂性，一些应用存在通证泄露漏洞。这样的漏洞是指，不受信任的用户能够执行通证泄露行为，该行为从DeApp中异常地支取/获取超过合理数量(例如远超过存入的份额)或合理比例(例如远超过正常收益比例)的资源。

通证泄露漏洞涉及多方面的特征。

图2示出针对DeApp的攻击交易中的通证转移示意图。图中，黑色节点表示攻击者及其恶意合约的地址。灰色节点表示DeApp程序的内部合约。空心节点表示攻击者和DeApp应用程序以外的地址。不同深浅的边表示使用不同种类的通证进行通证转移。从图中可以看出，交易中的转移路径和流向很复杂，只有部分路径与DeAPP应用和用户相关。

如前所述，一些DeApp应用支持多种不同类型的通证的存入、支取和交换，如图2中不同深浅的边所示。例如，某种DeApp应用可能允许用户通过通证交换功能存入通证A，提取通证B。此外，还有一些DeApp应用允许用户在应用中以通证形式存入资源并获得收益，因此用户提取的资源份额比最初存入的多是正常的。这些复杂性都为通证泄露检测带来了挑战。

为检测通证泄露漏洞，往往需要分析造成泄露的根因。然而，由于DeApp应用基于复杂的智能合约提供各种业务，造成通证泄露的根源也很复杂。一些漏洞是由常见的智能合约本身的程序弱点引起的，如整数溢出和可重入性。

除了智能合约的弱点之外，一些通证泄漏漏洞的根本原因是功能错误。例如，一个DeApp使用LP通证表示用户的质押份额。当用户存入某种资源时，DeApp铸造或产生LP通证；当用户提取资源时，DeApp销毁LP通证。LP通证可以进行转移。图3示出LP通证的转移函数的代码。如图所示，错误实现的转移函数(第2行)会导致通证泄漏漏洞。假设变量_from(第3行)等于变量_to(第4行)的情况。在这种情况下，由于余额[_from](第19行)将被余额[_to](第23行)覆盖，余额[_to]最终将更新为余额[_to]加_value(第23行)，而用户的余额却没有减少。为此，攻击者可以利用此漏洞，首先质押资源获得X份LP通证，然后将X份LP通证转移到自己身上，如此，攻击者可以持有2X份LP通证，并使用2X份LP通证从DeApp应用中提取两倍的初始资源量。

此外，其他的多种功能错误也导致了通证泄漏。例如，当用户存入资源时，DeApp应用可能不会检查通证是否已成功转移，或者应用可能无法验证存入通证的地址是否正确。总体来说，导致通证泄漏的各种问题(包括智能合约弱点和功能错误)对保护DeApp应用免受攻击构成了重大挑战。

尽管现有的检测工具在检测智能合约弱点方面表现出了较优的性能，但功能错误是通证泄漏漏洞的更常见原因。而随着DeApp功能更多更复杂，这些功能错误很难系统地解决，使得现有工具检测通证泄漏漏洞的能力有限。

有鉴于此，在本说明书的实施例中，提出一种新的漏洞检测方案。图4示出根据一个实施例的漏洞检测方案的框架示意图。如图4所示，该检测方案由三个阶段组成，从DeApp所基于的区块链获取交易数据，并输出通证泄露漏洞和相应的攻击者。第一阶段通过重放(replay)这些交易，来记录DeApp的执行轨迹。第二阶段，提取通证转移事件，并挖掘相关地址的角色(用户或应用)以及用户之间的关系，生成用户的通证流(flow)。第三阶段，合并通证流并执行异常检测，以揭示通证泄漏漏洞和相应的攻击者。

下面详细描述以上检测过程。

图5示出根据一个实施例的应用漏洞检测的方法流程图。可以理解，该方法针对基于区块链的去中心化应用，即DeApp，且该应用支持基于若干种类型的通证进行资源交换和转移。后续为了描述的方便，将作为分析目标的这类应用，简称为目标应用。图5的流程可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行，该执行主体可以体现为区块链系统中的节点，或者，也可以位于区块链之外，但具有从区块链节点获取相关数据的能力。

如图5所示，根据该方法流程，首先在步骤S51，记录目标应用执行过程中涉及智能合约的交易执行轨迹，基于所述轨迹形成调用树。

具体的，这里的轨迹(trace)主要是指，目标应用运行过程中，涉及智能合约的交易执行日志。具体来说，发送到智能合约的外部交易(该交易的To字段指向智能合约的地址)可能会引发多个内部交易来调用其他智能合约。基于这些交易的执行关系，可以将上述轨迹排布整理为调用流向树(Call Flow Tree)CFT，或称为调用树，如图6中(1)部分所示。

从图中所示，调用树CFT中有两种类型的节点，即交易节点和事件节点。交易节点包括外部交易(例如0)和内部交易(例如1)，其中两个交易节点之间的有向边表示父交易引发了作为子交易的内部交易。每个交易节点包括交易的调用方(calller)和被调用方(callee)的地址，以及交易所携带的数据，这些数据可以包括，调用的函数和参数，交易的值、调用类型(即call、CALLCODE、DELEGATECALL、STATICALL和CREATE)。每个事件节点包含，发起方的地址和事件数据。交易节点和事件节点之间的有向边指示事件在交易中发出。调用树CFT可以作为后续通证转移提取和其他深入分析的基础。

上述执行轨迹的记录，可以通过修改节点中部署的用于执行智能合约的虚拟机(例如EVM)实现。具体的，为了提取外部交易的执行日志，可以在用于执行外部交易的函数(在某具体区块链系统中，该函数为ApplyMessage())中插入记录代码。为了记录内部交易的执行，可以在函数call、CALLCODE、DELEGATECALL、STATICALL和CREATE的调用处理程序(handler)中插入记录代码，因为内部交易只能通过上述函数产生。通过上述记录代码，可以记录交易的执行，及其引发关系。

为了记录事件，可以在EVM的Log操作中插入记录代码。此外，在一个实施例中，可以维护一个调用栈，来标识触发事件的对应交易。具体来说，当一个调用处理程序(callhandler)被触发时，将相应的交易推送到调用栈上。当该处理程序返回时，弹出调用堆栈的顶部交易。如此，可以通过检查调用栈的栈顶，来了解一个事件属于哪个交易。

通过以上方式，记录交易的执行轨迹，形成调用树CFT。

接着，在步骤52，基于上述调用树，提取通证转移事件并挖掘各个交易涉及的角色，从而确定出发生在用户和目标应用之间的目标转移动作。

需要理解的是，为了检测出通证泄露，重点关注的是用户与目标应用之间的通证转移行为。然而，如前所述，目标应用通常由多个智能合约组成，支持各种业务，因此应用中的通证传输路径变得非常复杂(例如图2所示)，这使得提取用户和应用之间的通证传输具有挑战性。

为了便于理解，本文中，用户在目标应用中转移通证的行为被称为存入动作，而目标应用将通证转移给用户的情况被定义为支取动作。例如，通证交换可能包含存入动作和支取动作。

为了提取存入动作和支取动作，需要准确找到用户和目标应用之间的通证转移，并识别出用户确切转移的通证。然而，目标应用中存在多种存入和支取的操作方式，这给动作的提取带来了困难。

图7示出在一个示例中目标应用的多种存入模式。图7示例的目标应用至少提供三种存入模式。图7中的(1)部分是最直接的存入动作，其中用户A直接调用代理合约(proxycontract)，并将通证转移到该代理合约。在这种情况下，可以轻松找到确切的通证转移。然而，有时用户和目标应用之间的通证转移很复杂。对于图7中的存入模式(2)，用户A调用代理合约，而通证从用户A转移到vault合约，该合约是负责处理目标应用资源分配的内部合约。在这种情况下，需要区分出该内部合约与目标应用中其他相关合约，以进行后续的动作提取。对于图7中的存入模式(3)，用户A调用代理合约，而通证从用户B转移到该代理合约。该功能类似于支付应用中的代扣代付。在这种情况下，调用方-用户A和存入者(用户B)是分开的，这意味着，用户A和用户B之间存在特定关系，用户A可以基于属于用户B的存入资源从目标应用中提取通证或资源。因此，需要在提取存入(支取)动作时识别用户并发现其关系，以便进行更准确的分析。

除了用户和目标应用之间的通证转移外，用户之间或目标应用内还有其他通证转移，这也会干扰漏洞检测。

考虑到上述的各种复杂性，在步骤52中，对调用树进行分析，首先提取通证转移事件，然后挖掘各个交易涉及的角色，由此确定出角色关系信息，从而获取发生在用户和目标应用之间的目标通证转移，构成通证流。

图8示出基于调用树确定通证流的流程，即步骤52的子步骤。

如图8所示，首先在步骤S521，从上述调用树中提取通证转移事件，获得备选转移动作。

为了提取与上述目标转移动作相关的通证转移信息，可以从完整的调用树中，排除不相关的子树，保留相关的目标子树，目标子树的根节点是调用目标应用的代理合约的交易(外部交易)。然后可以通过遍历目标子树，确定备选转移动作。

具体的，首先识别出与目标通证转移相关的目标子树。为了避免干扰并提高提取效率，在一个实施例中，仅保留调用目标应用的代理合约的子树，修剪掉不相关的子树。如图6中(2)部分所示，假定交易2是调用代理合约的外部交易，那么可以修剪掉不相关的子树1和3，保留相关的目标子树2。图示中，目标子树保留了初始的根节点0，以与原图对齐，显示清楚。此外，需要说明的是，尽管在图中仅示出了一个目标子树，但是实际上，在整个调用树CFT中可能有多个相关的目标子树，这些目标子树都将保留下来，用于后续分析。

在修剪掉不相关的子树后，可以在保留的目标子树中提取出通证转移事件，据此得到备选转移动作。这里，需要根据目标应用所提供的通证的类型，该通证满足的标准/规范，或具有的特点，来确定出备选转移动作。

举例而言，在一个例子中，目标应用提供I型通证和II型通证。对于I型通证转移，可以使用I型通证标准来识别与I型通证转移相关的所有事件，并将这些事件节点替换为通证转移节点，该通证转移节点可以记录通证转移的细节(例如，“地址A将数量为X的Y通证转移至地址B”)。假定II型通证是可以直接通过外部交易在用户之间转移的通证。对于II型通证转移，可以从目标子树的交易中检索得到通证转移信息，并在相应的交易节点中插入一个新的通证转移节点。接下来，将通证转移节点提升为调用代理合约的交易节点的子节点。例如，在图6的(3)部分中，分别将涉及I型通证转移的事件节点7和8替换为通证转移节点7和8(图中以黑色圆圈示出)，并将它们提升为交易节点2的子节点。此外，还插入一个涉及II型通证转移的节点9。这些通证转移节点对应的通证转移动作，都作为备选转移动作。

在步骤S522，进行角色挖掘，即确定前述调用树中涉及的各个地址的角色。角色包括，表示用户的用户角色，和代表目标应用的应用角色。

根据一种实施方式，通过解析调用树中的调用流，启发式进行角色挖掘。具体来说，将外部交易的发起者设置为用户角色，将代理合约设置为应用角色。当内部交易被触发时，如果被调用者(callee)没有被标记任何角色，则将调用者(caller)的角色赋予被调用者，即，被调用者被标记为与调用者相同的角色。例如，最初，交易0的调用者是用户角色，交易2调用了代理合约，因此交易2的被调用者是应用角色。通过角色传递，交易0、1和3的被调用者被赋予用户角色，交易5和6的被调用者被赋予应用角色。

此外，还可以执行进一步分析，以微调和完善地址的角色。具体的，如果某个地址的通证转移在历史交易中与许多地址相关，我们将该地址视为应用角色。如果一个用户角色通过一个交易调用代理合约，可以解析该交易data字段的相关参数，如果其中地址类型的参数中的具体地址add没有被标记角色，则将该地址add标记为用户角色。如此，可以获得CFT中各个地址的角色，作为后续分析的基础。

需要说明的是，需要将可信地址(例如，代理合约的创建者)排除在用户组之外，以避免来自特权地址的干扰。具体来说，可以将代理合约的创建者设置为可信地址。当可信地址调用代理合约时，将交易中的地址类型参数视为可信地址，而非用户角色。

接着，在步骤S523，利用预设类型通证的信息和上述角色信息挖掘用户关系。

如前所述，一些DeApp应用允许用户根据其他用户存入的通证提取资源。该步骤针对这种应用设计，是可选步骤。

具体的，在某些DeApp中，提供III型通证，用于记录用户的质押份额。在用户进行存入操作时，应用铸造或生成该III型通证；在用户执行支取操作时，应用销毁这些通证。在一些具体的应用中，III型通证具体称为LP通证。LP通证的产生/销毁可以表示为从/向特定地址(具体例如，0x0地址)进行通证转移。如图6的(4)部分所示，假定通证转移事件7涉及LP通证，可以将通证转移节点7转换为LM节点，以表示LP通证的铸造。然而，LP通证的使用带来了新的检测障碍，因为用户可以将质押的份额转让给他人。例如，根据图7的模式(3)，用户B向目标应用存入资源，使得为用户A铸造了LP通证，然后，用户A可以通过销毁LP通证来提取资源。在这种情况下，如果没有关于用户A和用户B之间关系的信息，则有可能会错误地将通证泄露归因于用户A。此外，一些DeApp应用通过维护世界状态存储来实现这一功能，从而使检测分析更加复杂。

为此，在一个实施例中，利用LP通证的信息和用户角色信息来建立用户之间的关系，以便进行更精确的检测。基于LP通证，可以使用与存入(支取)动作相关的子树中LP通证的铸造来确定用户之间的关系。例如，如果用户A调用代理合约，将通证转移到目标应用，同时LP通证被铸造给用户B，那么可以在用户A和用户B之间建立关系并将其记录。此外，由于LP通证可以在用户之间转移，可以收集LP通证的转移来建立用户之间的关系。例如，如果用户A将LP通证转移给用户B，可以记录用户A和用户B之间的关系。此外，基于挖掘的用户角色，可以记录代理合约的调用方和向目标应用转移通证(或从中接收通证)的用户之间的关系。例如，在图7的模式(3)中，可以记录调用方(用户A)和用户B之间的关系。

在一个例子中，挖掘出的用户关系可以如下表示：

rel＝{(userA,userB,blocki,txj)

这表示，用户A通过区块blocki中的交易txj与userB建立了预设关系。

进一步的，在步骤S524，基于前述各个地址的角色，从备选转移动作中确定出用户与目标应用之间的目标转移动作。

具体的，在确定调用树中各个地址的角色基础上，可以准确确定出发生在用户和目标应用之间的目标转移动作，并据此生成通证流，例如图6(4)中的通证转移节点8即对应于目标转移动作，用以构成通证流。可以理解，相关的目标子树中可能存在多个目标通证转移。对于每次具体的目标通证转移，可以生成一个元组，来表示通证发送者的(存入或支取)动作，该元组可以表示为：

action＝(block,tx,amount,token,type)(1)

其中block是触发该用户动作的交易所在的区块高度，tx是该交易在区块中的位置，amount是通证数量，token是转移通证的种类，type是动作类型(存入或支取)。一系列的上述动作action，可以构成通证流。

将各个动作action按照用户进行分组，可以得到各个用户分别对应的通证流。

回到图5。在通过步骤S52获取到以上信息的基础上，可以执行漏洞检测步骤S53，其中，将针对各个类型通证的通证流进行合并，基于合并通证流确定累积转入量和累积转出量，根据该累积转入量和累积转出量，确定是否存在通证泄露漏洞。

需要理解，一些DeApp应用支持多种通证，这有可能会干扰回报率的计算。例如，用户可以存入通证A，但支取通证B，使得通证的数量本身不能直接比对。因此，在本实施例中，将不同类型的通证流合并，以计算正确的返还率。

然而，有些区块链系统和DeApp中，多种类型的通证价值差异很大，并且其标识的资源量会随着时间的推移而变化。为此，在一个实施例中，提出一种方式来统一通证的价值。具体的，可以定义或使用一种特殊的统一价值单位，例如WETH，来计算通证的价值。为此，预先根据一些标准，构建WETH与其他通证之间的换算表，又可称为“汇率表”。基于汇率表，可以利用WETH来计算其他通证的价值，并将不同通证的通证流合并为单个流。通过这种方式，可以获得合并的通证流以供后续检测。特别的，如果通证流仅包含一种通证，则可以直接将该通证流视为合并流，而无需将其转换为WETH。

在合并通证流的基础上，可以计算返还率，通过检测异常返还率来发现通证泄漏情况。具体的，返还率可以定义为通证对应资源的累积转出量与累积存入量之比。在一个例子中，累积存入量Deposits，累积转出量Withdrawls和返还率rate定义如下：

Deposits＝∑action.amount type＝deposit

Withdrawls＝∑action.amount type＝withdrawal

其中可见，累积存入量是对各个存入动作所涉及的amount的求和(可能涉及“汇率”转换)，累积支取量是对各个支取动作所涉及的amount的求和，各个存入/支取动作，是例如式(1)的元组所记录的目标通证转移动作。

对于每个用户，可以遍历其合并的通证流，在每个操作处计算对应的返回率。对于通证流中的每个操作，可以首先递归搜索与该用户有关系的相关用户，并将其分组在一起。然后，分别计算在该操作之前，该分组中所有用户的累积存入量Deposits和累积支取量Withdrawls，在此基础上进一步计算返还率。

如此计算的返还率分为三种情况：1)返还率小于等于1，这种情况是正常情况，对于漏洞检测可以忽略；2)返还率为无穷大∞，这种情况可以直接报告存在通证泄漏，因为用户支取了通证但没有存入；3)返还率不是∞且大于1，这种情况需要收集起来，进一步确定其返还率是否异常。

具体来说，可以设定一个阈值，例如T＝5。将小于该阈值T的返还率包括在内，并计算它们的平均值ave和标准差std。然后，根据该平均值和标准差确定出正常返还率的标准。例如，该标准返还率可以设置为rate＝ave+5*std。于是，在实际返还率大于该标准返回率rate的情况下，可以认为识别出通证泄漏现象。通过这种方式，可以有效地发现攻击者导致的异常情况。

当检测到上述通证泄露，将发出对应动作的用户确定为攻击者，报告检测结果。

回顾以上过程，可以看到，本说明书实施例的方案，不局限于针对特定应用的特定功能，而是通过追踪交易执行过程，从中定位出发生在用户和应用之间的通证转移，从而检测通证泄露漏洞。该方案适用多种DeApp应用，且检测结果更加准确。

根据另一方面的实施例，提供了一种针对目标应用进行漏洞检测的装置，所述目标应用是基于区块链的去中心化应用，且支持基于若干种类型的通证进行资源交换和转移。图9示出根据一个实施例的检测装置的结构示意图，该检测装置可以部署在任何具有数据存储、计算、处理能力的设备、平台或设备集群中。该检测装置具体可以部署在区块链系统的节点中，或者，也可以部署在区块链之外的设备中，但具有从区块链节点获取相关数据的能力。如图9所示，该检测装置900包括：

记录单元910，配置为记录所述目标应用执行过程中涉及智能合约的交易执行轨迹，形成调用树，所述调用树包含交易节点和事件节点；交易节点之间的有向边表示父交易引发子交易；交易节点与事件节点之间的有向边表示，通过该交易发出该事件；

提取单元920，配置为基于所述调用树，提取通证转移事件并挖掘各个交易涉及的角色，从而确定出发生在用户和所述目标应用之间的目标转移动作，各目标转移动作形成通证流；其中所述角色包括代表用户的用户角色和代表目标应用的应用角色；

检测单元930，配置为将针对各个类型通证的所述通证流进行合并，基于合并通证流确定累积转入量和累积转出量，根据该累积转入量和累积转出量，确定是否存在通证泄露漏洞。

以上装置中各个单元的实现方式，可以参照之前结合图5的描述。通过以上装置，可以准确而有效地对目标应用的通证泄露漏洞进行检测。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图5所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图5所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。