ArkProject: NFT Bridge

Github

https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/ethereum/src/Bridge.sol#L223-L266

Summary

The current cancellation flow in our bridge contract allows for potential exploitation due to inadequate verification checks. Specifically, the startRequestCancellation and cancelRequest functions only verify the existence of the deposit payload but do not check if the deposit has been processed by StarkNet L2. This oversight can be exploited to gain tokens on both L1 and L2 if the L2 fails to send a confirmation proof within the set timeframe.

Impact

If the deposit payload is not confirmed by StarkNet L2 within the expected timeframe, an attacker could potentially exploit this by canceling a deposit that has already been processed. This would allow them to reclaim the tokens on L1 while still retaining the tokens on L2, effectively doubling their assets and leading to significant financial losses for the system.

Proof of Concept

Let's discuss how this issue can arise and attacker/malicious user can exploit it to his advantage:

1. Initiate a Deposit: A user initiates a deposit from L1 to L2.

2. Payload Exists but Not Confirmed: The deposit payload exists on L1, but the confirmation proof from L2 is not received within the set timeframe.

3. Cancel the Deposit: The user calls startRequestCancellation and subsequently cancelRequest to cancel the deposit.

4. Tokens on Both Sides: The user successfully reclaims the tokens on L1, while the tokens remain on L2 due to the lack of confirmation proof, resulting in double spending.

Recommendation

To prevent this exploitation, implement a mechanism to verify the status of the deposit on StarkNet L2.

Also, ensure that a certain period has passed without receiving the confirmation proof before allowing cancellation.

Along with this, implement safeguards to prevent tokens from being claimed on both L1 and L2.