Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding K-V storage to conditions allowing to implement protection between conditions #173

Merged
merged 8 commits into from
Oct 19, 2021

Conversation

aaitor
Copy link
Member

@aaitor aaitor commented Oct 14, 2021

Description

To add a better protection to fulfillment of conditions dependant on other conditions, this PR adds a KV storage related with the Condition Ids. This allow to publish parameters in the fulfillment of conditions that can be used by other conditions to validate/control the access/fulfillment.
This is implemented in the TransferNFT721 condition

Is this PR related with an open issue?

Related to Issue #

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • Follows the code style of this project.
  • Tests Cover Changes
  • Documentation

@aaitor aaitor requested review from a team as code owners October 14, 2021 13:44
@aaitor aaitor requested a review from mrsmkl October 14, 2021 15:31
@aaitor aaitor linked an issue Oct 14, 2021 that may be closed by this pull request
@@ -138,6 +138,14 @@ contract TransferNFT721Condition is Condition, ITransferNFT, ReentrancyGuardUpgr
lockConditionState == ConditionStoreLibrary.ConditionState.Fulfilled,
'LockCondition needs to be Fulfilled'
);

// Check that nft receiver is the same enabled in the lock payment condition
require(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this helps...

The scenario I was thinking is the following:

  • TransferCondition contract is approved by LockPaymentCondition contract to transfer token id (not certain if this can even happen currently, but for the case nftOwner == _lockConditionAddress it is needed)
  • Correct flow: a lock payment condition is created, and a transfer condition depending on that. The lock payment condition is fulfilled
  • Attack flow: another pair of conditions is created with the attacker as receiver. Attacker fulfills the bogus lock payment condition, and then can fulfill the transfer condition as receiver.

One possible solution could be to set the receiver when the token is sent to _lockConditionAddress ...

Copy link
Contributor

@mrsmkl mrsmkl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Not sure that all new checks are necessary now that only the nft owner can fulfill.

@aaitor
Copy link
Member Author

aaitor commented Oct 19, 2021

I'm gonna leave the Conditions Key-Value implementation there because it can be useful/necessary for some complex service agreements

@aaitor aaitor merged commit dcbdac3 into master Oct 19, 2021
@aaitor aaitor deleted the fix/nft_transfer branch October 19, 2021 08:43
@aaitor aaitor restored the fix/nft_transfer branch October 25, 2021 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TransferNFT721 condition needs to have a better protection
2 participants