The depositTokens
function constructs a request hash and sends it to Starknet, but it does not track or store these hashes. This oversight makes the contract vulnerable to replay attacks.
The depositTokens
function generates a request hash based on the provided inputs but does not save this hash in storage. Without tracking these hashes, a malicious actor can replay the same request, leading to potential duplicate deposits.
Replay attacks could result in multiple unintended token deposits or withdrawals, affecting the accuracy and reliability of token transfers between L1 and L2.
Manual Code Review
Implement a mechanism to store processed request hashes. For instance, you can use a mapping to keep track of used request hashes:
Update the depositTokens
function to use these methods to prevent replay attacks:
There is no impact here: Transaction cannot be replayed because the blockchain use the nonce in the signature. Hash is computed on-chain. Using or trying to have the same hash mean you need to buy the token, and they will be sent to their origin owner. Why an attacker would buy tokens to give them back ? No real impact.
There is no impact here: Transaction cannot be replayed because the blockchain use the nonce in the signature. Hash is computed on-chain. Using or trying to have the same hash mean you need to buy the token, and they will be sent to their origin owner. Why an attacker would buy tokens to give them back ? No real impact.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.