Lesson 15 - Reentering events

[Mike4751]

In the sub lesson about Reentrancy attacks, there's a note that pops up about the ItemBought event being vulnerable to a reentrancy attack. How would a malicious actor go about doing this, and is this risk mitigated through the OpenZeppelin nonReentrant modifier?

[krakxn]

Could you paste the relevant code, or some sort of context to your doubt. Thank you

[Mike4751]

The event is emitted in the buyItem function.

Patrick states that we've set the contract up in a way that is safe from a reentrancy attack, but my question comes from this popup in the video. What capabilities does a hacker have that will let them abuse an event such as this?

[krakxn]

Does .safeTransferFrom comply with the practices involved for re-entrancy attacks prevention? If so, I do think the function is safe from such attacks. If not, transferring money/tokens is always a bad idea and susceptible to such attacks. (interested? read about pull over push practices)

So, if that function follows pull over push it should be safe.

Also, we could further secure it from such attacks by adding a require conditional (or a if-statement paired with a custom error revert) which checks if the token was really transferred or not, before emitting the event as ItemBought.

The above should solidify any chances of a re-entrancy attack. Hope this helps!

Note for Patrick: @PatrickAlphaC Am I correct here? I thought about it for a while, seems like the conditional further secures it. I could be missing something here though!