Bridge::depositTokens(...)
function has is vulnerable to replay attacks.
There are few problems with the implementation as it stands:
salt
is user-inputed: This means that a depositor could generate the same hash for two different deposits by using the same salt.
msg.sender
(the depositor) is not part of the hash: This means that two different depositors could generate the same request hash if they use the same salt
, collectionL1
, ownerL2
, and ids
.
useAutoBurn
is not part of the hash: This means that an attacker could potentially burn tokens for a user when they don't want to.
Described above. Note that the same applies for Starknet deposits.
Manual review.
Include msg.sender
and useBurnAuto
in the hash. This can be done by modifying the requestHash
:
Ensure that each salt is unique for each deposit:
Or consider not making salt
not user-inputted but incrementing the salt for each deposit.
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.