Security: check/fix scenario where address is reused

[ligi]

Security: check/fix scenario where address is reused

[ligi]

yea - unfortunately we will need to do the quick-fix solution (ideas on the best quick fix still welcome) this year unfortunately. Let's do it proper next year ..-)

[ligi]

One approach to solve this issue I see is: we need a database table that stores orderId to (transactionHash,chainId) - this way we can prevent that one transaction is used to pay for multiple tickets and this data could also be useful later on (allow to perform actions with the sender key to trigger things at the event) Perhaps for this we should also cache from so we do not need to query the chain for it anymore.

[ligi]

Just to throw this in here: in an ideal world we would not centralize around databases but have the receiver be a smart contract/DAO that yields e.g. one NFT / X-DAI. Perhaps next year - for this year this is too risky time-wise ..-(

[carver]

Just to throw this in here: in an ideal world we would not centralize around databases but have the receiver be a smart contract/DAO that yields e.g. one NFT / X-DAI. Perhaps next year - for this year this is too risky time-wise ..-(

Hah, yeah, this seems like the obvious "best" answer, but agree that it seems unwise to try to pull that off in a short time.

[pipermerriam]

@ligi this does appear to be an exploitable attack vector.

The suggested mitigation mechanism seems correct, maintaining a new table that includes tx_hash, order_id, chain_id pairings which would be queried each time to ensure that no existing record is present for a given tx_hash/chain_id pair. Care needs to be taken to ensure that payment.confirm() and the creation of the new record for tx_hash/chain_id/order_id is recorded in an atomic transaction block:

See: https://docs.djangoproject.com/en/2.2/topics/db/transactions/#controlling-transactions-explicitly

[raphaelm]

I agree, the best way to fix this in pretix is a table with the payment object IDs (not order IDs) and the transaction hashs.

[davesque]

After merging #37 , we're now safe against replay attacks, but we're not tracking chainIDs for transactions in our transaction table. I guess there's a risk someone could be prevented from using a transaction to purchase a ticket in the rare event that its hash matches one already in the database from another purchase. But, if I'm not mistaken, wouldn't this require that the same "from" address generated a transaction with the same nonce?