The LikeRegistry
contract's likeUser
function allows users to see the likes of a specific person and determine if they have liked their profile. This information can be exploited to force a match with a person who has liked multiple profiles, or to front-run a like transaction. Since all transactions and states are public on the blockchain, this vulnerability can be easily exploited.
In the likeUser
function, the likes
mapping is public, allowing anyone to see who has liked whom. This transparency can be exploited in two ways:
Forced Matching: A user can see if a specific person has liked their profile and then like that person's profile to force a match. This can be used to manipulate the matching process for personal gain.
Front-running: Since all transactions are public on the blockchain, a user can observe a like transaction in the mempool and front-run it by sending their own like transaction first. This can disrupt the intended matching process.
Manipulation of Matching Process: Users can force matches with specific individuals, disrupting the intended matching process and potentially leading to unfair advantages.
Front-running: Users can front-run like transactions, leading to unintended matches and potential user dissatisfaction.
Loss of Trust: The ability to manipulate the matching process and front-run transactions can lead to a loss of trust in the platform.
Manual code review
Consider implementing rate limiting to prevent users from spamming likes and manipulating the matching process.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.