In the current implementation, the blockProfile
function allows the owner of the contract to "block" a user's profile by burning the associated token and deleting the mapping that links the address to the profile token. However, this action only removes the profile from the contract, and the user can still create a new profile using the same address. This is because the blockProfile
function only removes the profile, and there is no mechanism to prevent the user from registering new profiles with the same address.
The core issue is that even though a profile can be "blocked" (i.e., burned and deleted), the owner cannot truly prevent the user from creating new profiles with different addresses. This makes the blockProfile
function ineffective in the long term. Nevertheless, even blocking the 'blocked' profile doesn't work because there is no mechanism in place to prevent the same address from registering again.
manuel review
To properly block a user from interacting with the contract, a blacklist mechanism should be implemented. The blacklist would store the addresses of users that are not allowed to register new profiles or interact with the contract.
Here’s how this could be implemented:
Create a blacklist that stores addresses of users who are blocked.
Check the blacklist during the profile registration process to prevent users on the blacklist from registering new profiles.
Modify the blockProfile
function to add the address to the blacklist instead of deleting their profile entirely, so the owner can block the user more effectively.
Likelihood: Low, any blocked users. Impact: High, not really blocked.
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.