ArkProject: NFT Bridge

Summary:

Bridge.sol contract currently lacks explicit mechanisms to prevent replay attacks, which could pose a security risk

Vulnerability Details

The contract is susceptible to replay attacks without mechanisms to track and prevent the reuse of request hashes.

1. Request Hash Storage: The contract does not maintain a record of processed request hashes. This omission allows the possibility of replaying the same request if its hash is not verified for uniqueness.

2. Message Consumption: Although the _consumeMessageStarknet function is utilized for message processing, it does not appear to mark requests as completed or prevent their reprocessing.

3. Absence of Nonce or Timestamp: The contract does not incorporate a nonce or timestamp in its requests, which are essential for ensuring that each request is unique and processed only once.

Impact:

Without tracking the uniqueness of request hashes, attackers could potentially replay valid requests, resulting in unauthorized or duplicate actions which might result in the unintended transfer of assets, leading to financial losses

Tools Used

Manual review

Recommendations

Hash Storage Implementation

1. Hash Storage Mapping

A mapping is introduced to store hashes of processed requests:

2. Hash Verification and Storage

Before processing any request, verify if the hash has already been processed. If it has, revert the transaction to prevent duplicate processing. Once a request is processed, store its hash to ensure it cannot be reused:

3. Optional Hash Clearing

Consider implementing a mechanism to clear stored hashes after a specified period to manage storage efficiently.