ArkProject: NFT Bridge

Summary:

The depositTokens function does not verify if the caller actually owns the NFTs they are attempting to bridge. This vulnerability can be exploited by a malicious actor through a front-running attack.

Vulnerability Details:

Steps for a Potential Front-Running Attack:
Legitimate User's Intent:

A legitimate user, Alice, wants to deposit her NFT (ID: 123) from collectionL1 to Starknet.
Alice calls the depositTokens function with the necessary parameters, including the NFT ID: 123.

Transaction Broadcast:

Alice's transaction is broadcasted to the Ethereum network but is not yet mined.

Malicious Actor's Exploit:

A malicious actor, Bob, monitors the mempool and sees Alice's pending transaction.
Bob notices that the depositTokens function does not verify ownership of the NFT.
Bob quickly sends his own transaction to the depositTokens function with the same NFT ID: 123, but from his own address.

Transaction Mining:

If Bob's transaction is mined before Alice's, the contract will process Bob's request.
The contract does not check ownership, so it assumes Bob owns the NFT and proceeds with the deposit.

Result:

Bob's transaction succeeds, and the NFT ID: 123 is marked as deposited.
When Alice's transaction is mined, it fails because the NFT is already marked as deposited or Bob's transaction has already altered the state.

Impact:

resulting in the incorrect transfer or bridging of NFTs. This can lead to the legitimate owner losing access to their NFT

Tools Used:

Manual review

Recommendations:

Ownership Verification:

Check Ownership Before Processing: Modify the depositTokens function to include a check that verifies the caller's ownership of the NFT before proceeding with the deposit. This can be done using the ownerOf function from the NFT's smart contract. Ensure that the caller's address matches the owner of the specified NFT ID.