Canto Identity Protocol contest - glcanvas's results

Lines of code

https://github.com/code-423n4/2023-01-canto-identity/blob/main/src/AddressRegistry.sol#L51-L57 https://github.com/code-423n4/2023-01-canto-identity/blob/main/src/AddressRegistry.sol#L21 https://github.com/code-423n4/2023-01-canto-identity/blob/main/src/AddressRegistry.sol#L40-L49 https://github.com/code-423n4/2023-01-canto-identity/blob/main/src/AddressRegistry.sol#L59-L64

Vulnerability details

Impact

AddressRegistry might has non-actual record, which leads to inconsistent AddressRegistry state, and might affect possible consumers.

Proof of Concept

To register favorite NFT user calls register function from AddressRegistry. Then he sold this NFT to another user, and now he isn't owner of this NFT. From this time AddressRegistry has incorrect state and will have this state till previous owner will not delete this entry by itself.

But if AddressRegistry integrated with some services which produces goods, users may don't delete this record and take all the benefits from another contract.

Tools Used

Manual audit

Recommended Mitigation Steps

Add function to force reset record for user, which is not owner of current NFT item. something like this:

function reset(address addr) external {
    uint256 nftId =  cidNFTs(addr);
    if (nftId == 0) {
        return;
    }
    if (ERC721(cidNFT).ownerOf(nftId) != addr) {
        delete cidNFTs[nftId];
    }
}