账户安全随笔

原文出处：账户安全随笔—Enoch

本公众号已获得转载权限。

账户类型

在互联网金融和电商企业中，账户安全直接关系到用户及系统账户的资金安全。

在金融企业中，常见的账户类型包括以下几种：

1.出入金账户：用于用户充值和提现操作的账户。

2.现货交易账户：专门用于用户进行现货交易的账户。

3.期货交易账户：用于用户参与期货交易的账户。

4.杠杆交易账户：为用户提供杠杆交易服务的账户，允许通过借贷提高交易资金。

5.质押账户：用于用户在不同场景下进行资产抵押的账户。

6.子账户：属于母账户的从属账户，用户可以在母账户和子账户之间进行资金的自由划转。

7.系统账户：平台用于业务运营的内部账户。

8.系统归集账户：用于平台活动、产品销售等场景下收款的账户。

9.财务账户：企业财务部门专用的账户，用于处理企业内部的财务管理事务。

如果所有交易和资产都记录在一个账户上，不仅会使账目混乱，还无法满足不同类型的交易需求。因此，金融、电商企业通常设置不同类型的账户，以便分门别类地管理各种交易活动和资产。

资金划转问题

由于不同账户具有不同的功能和用途，用户在实际操作中常常需要在各类账户之间进行资金划转。这种划转需求通常源于用户为了参与不同类型的交易或调整资金配置。

例如，用户可能需要将资金从现货交易账户划转至期货交易账户，以便参与期货交易，满足期货交易中的保证金要求。

而在划转过程中，常见的漏洞之一为并发划转漏洞。

漏洞的成因是在涉及用户账户->系统账户、系统账户->用户账户、或用户账户->用户账户等类型的资金划转时，系统没有对划转操作进行锁定、没有采用其他同步控制机制、处理请求时发生延时，导致账户之间的资金状态出现不一致的情况。

假设账户A余额为1000元，账户B余额为1000元。

现在，账户A的用户同时发起两个并发的划转请求：请求1为从账户A向账户B划转300元；请求2为从账户A向账户B划转500元。

若系统在处理这两个请求时没有适当的锁机制，导致它们几乎同时执行。可能的情况是：

1.请求1和请求2同时读取账户A的当前余额1000元。

2.请求1计算新的余额：1000元 - 300元 = 700元，并将这个新余额700元写回账户A。

3.请求2计算新的余额：1000元 - 500元 = 500元，并将这个新余额500元写回账户A。

4.两个加款操作均成功，将相应的金额添加到账户B。

5.账户A的最终余额被请求2覆盖为500元，而不是200元。但此时账户B余额为1800元。

这就是典型的多进程/并发请求下导致的资金划转漏洞。

为彻底杜绝并发划转导致的资金不一致问题，可以采取以下措施并同时实施：

（一）所有涉及资金的变动操作，必须先将相应资金进行冻结处理。只有在确保冻结成功后，才能进行进一步的动账操作。

（二）所有冻结资金的操作以及冻结资金的划转过程必须严格加锁，防止并发操作引发超额冻结或超额划转的风险，确保每笔划转在同一时间只能执行一次。

（三）在外部服务器调用内部服务器进行动账操作时，外部服务器必须传输一个唯一的事务ID。该事务ID必须具有幂等性，以确保同一事务的多次请求只会被处理一次，防止重复划转或资金不一致的情况发生。

（四）对于不同业务线之间的资金划转，应设置小时级的对账机制，确保短时间内的资金划转能够被及时检测。同时设定安全阀值，若划转金额或次数超过阀值，系统将立即触发告警。

（五）所有账户，包括用户账户和系统账户，均禁止出现负余额的情况。任何动账操作必须在确保账户余额足够的前提下进行，避免资金透支或其他异常现象发生。

通过以上步骤，能够在基础服务中有效杜绝并发划转问题，但在外部服务器中仍可能存在其他安全隐患。

1.幂等ID使用错误

在外部系统中，订单号是唯一的，应使用订单号作为幂等ID来确保扣款操作的唯一性。而时间戳每秒钟都会变化，若使用时间戳作为幂等ID，当同一秒内同时发起多个请求时，将导致并发问题的出现，进而引发资金损失问题。

通常，这种错误源于研发人员对安全性的重要性认识不足或技术理解能力不够。

2.多接口并发问题

在一笔订单中，如果同时进行提现和划转等操作，可能会导致多个接口的并发问题。

假设某账户A在Paypal中持有10万元，若账户同时发起10万元提现的请求和将10万元划转到Buypal的请求，可能会发生以下情况：

两个请求同时读取账户A的当前余额10万元。

提现请求：系统判断10万元 - 10万元 >=0.000，允许账户提现10万元。

划转请求：系统判断10万元 - 10万元 >=0.000，允许账户划转10万元。

最终，用户成功提现10万元，而其Buypal账户中也虚增了10万元。

尽管基础服务已实施限制，系统的总账依然平衡，每笔交易在总账中都能体现，但业务账目可能会出现不一致。这种情况可能导致系统归集账户和系统账户的资金被恶意刷光。

类似地，在购物平台上同时发起提现和购买操作，也可能存在该类漏洞。

通常，这种错误源于应用程序只对提现和划转操作做了事务锁，但缺乏表锁或冻结资金的逻辑。

精度问题

精度问题通常发生在不同业务或系统之间的资金划转过程中。当A业务与B业务的金额精度设置不一致时，可能导致资金安全隐患。

作者Enoch在工作中曾遇到类似情况，并通过SlowMist赏金计划向某交易所报告了该漏洞。交易所当天迅速修复问题，并为其提供了2500美元的漏洞赏金。

例如，在A业务中使用的精度为小数点后7位，而B业务则使用小数点后10位。如果在A业务向B业务划转过程中，涉及的金额为0.00000001，可能出现的情况是：因精度限制，在A业务中，账户金额未能扣除；而在B业务中，金额却被成功加上。

其他划转问题

在杠杆交易中，资金通常需要划转到特定的交易品种。例如，划转参数可能如下所示：

这表示用户希望将100个BTC划入BTC/USDT交易对中，以充当保证金。然而，如果使用不兼容的参数进行划转，就可能导致资金划转问题。

例如，若突破业务限制，成功将100个YFI（Yearn Finance的原生代币）划入YFII（Yearn Finance II）的交易对，划转参数可能如下所示：

在实际的杠杆交易中，如果交易失败并导致YFII的爆仓，由于YFI无法在YFII/USDT交易对中进行交易，该币种的资金将无法被清算。如果系统设计较弱，甚至可能导致资产虚增的情况发生。

特殊资金盗取问题

通常情况下，在加密货币领域存在点卡和体验金，这些资金在划转时受到限制，并会在规定时间后被收回。如果在这一时间段内，能够将这笔资金从A server划转到B server，就能够避免这笔资金的回收，导致账户资产虚增问题。

科学计数法问题

在处理数字时，科学计数法问题时常出现。虽然这种问题不直接导致资产虚增，但在电商系统和支付软件中，该问题较为严重。大多数情况下，这类问题源于Java的BigDecimal类，其可能导致系统在处理数字时出现异常，引发拒绝服务问题。

作者Enoch和同事利用这一问题，成功在多家国内头部电商、领先的支付软件以及世界知名交易所中进行测试，累计获得了近十万元的漏洞奖励。