ArkProject: NFT Bridge

I noticed a crucial function named depositTokens. This function handles the process of depositing tokens into an escrow before they are transferred to Starknet. However, a subtle comment left by a previous developer hinted at a potential issue: "store request hash in storage to avoid replay attack."

This got me curious. I knew that in blockchain systems, replay attacks are a common and dangerous vulnerability. In a replay attack, a previously signed transaction could be reused (or "replayed") to execute the same operation again, leading to unintended consequences.

To confirm my suspicion, I traced the flow of the function and found that while the contract generated a hash for each deposit request, it never stored these hashes. This meant that an attacker could reuse a valid deposit transaction, essentially duplicating the deposit without needing the user to sign a new transaction. This would enable an attacker to drain tokens from users or manipulate the escrowed assets, potentially leading to massive financial losses.

Solution: To counter this vulnerability, I proposed storing each request hash in a mapping within the contract's storage. By doing so, the contract could track whether a specific hash had already been processed, thus preventing any attempts to replay the same transaction.

Location: depositTokens function in ethereum/src/IStarklane.sol

issue: The comment in the depositTokens function mentions a potential replay attack due to the lack of request hash storage. Without proper mitigation, an attacker could reuse a previously signed transaction, replaying it and triggering unintended consequences.

impact: An attacker could replay a valid transaction, causing duplicate operations such as double deposits or incorrect state updates. Without storing request hashes, the system is susceptible to replay attacks where an attacker could reuse a signed transaction to repeat operations, potentially causing asset duplication or loss.

Tools used: Manual Review.

Recommendations: Store and track request hashes to prevent replay attacks. Consider using a nonce or timestamp in the request to ensure uniqueness.

Potential changes: store request hashes and implement a nonce mechanism.