Missing Access Control in Airdrop::claim()
function allows anyone to claim love tokens even though they dont have soulmates.
The Airdrop::claim()
function has two checks:
Checks if a soulmate is divorced
Checks if amountAlreadyClaimed >= numberOfDaysInCouple * 10 ** loveToken.decimals()
Now the isDivorced()
only checks if a soulmate called the getDivorced()
function and broke up with their soulmate.
Airdrop::claim()
function is ONLY checking if the soulmate is divorced and is not checking if a user even had a soulmate in the first place. Therefore a random user who has never had a soulmate could easily call Airdrop::claim()
and get his share of love tokens for the day.
He could also do a block.timestamp
manipulation -> Travel to the future 🏃♂️💨 -> and claim
a HUGE amount of love tokens 🪙
Random users can claim love tokens without even finding a soulmate. Malicious attackers can manipulate the block.timestamp
and empty the vault.
Add the following code to the AirdropTest.t.sol
testsuite
Manual review
Making custom modifiers to check whether a user is a soulmate of someone and implementing it in the Airdrop::claim()
function.
Or adding require statement that checks if a user has a soulmate inside the Airdrop::claim()
function.
High severity, This issue is separated from the flawed `isDivorced()` check presented in issue #168 as even if that is fixed, if ownership is not checked, isDivorced would still default to false and allow bypass to claim airdrops by posing as tokenId 0 in turn resulting in this [important check for token claim is bypassed.](https://github.com/Cyfrin/2024-02-soulmate/blob/b3f9227942ffd5c443ce6bccaa980fea0304c38f/src/Airdrop.sol#L61-L66). #220 is the most comprehensive issue as it correctly recognizes both issues existing within the same function.
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.