After having audited quite a few orderbookimplementations, I've compiled a list of common vulnerabilities that auditorsshould be vigilant of. I hope this can provide you with insights for your nextaudit of such an implementation.
These issues are not solely for generalorderbooks (User A creates an order and User B accepts it) but also for generalorderbook implementations where the price is already matched and work on a FiFobase.
Orderbooks are inherently susceptible toDoS attacks through various scenarios that disrupt their normal flow. Here are a few examples:
Multi-Offer Creations with 1 Wei: Attackerscan spam the orderbook with offers that are economically insignificant but canclog the system, preventing genuine transactions from being processed. (ForFiFo implementations)
Revert Upon ETH Receipt: If an orderbookimplementation accepts ETH and reverts transactions upon receiving ETH forcertain orders, the order creator may DoS the orderbook (For FiFoimplementations)
Blacklisting Scenario for Recipients: Incases where a recipient is blacklisted from receiving certain tokens (likeUSDT), the orderbook can be manipulated to reject transactions, causing adisruption in service. (For FiFo implementations)
Malformed Tokens: Utilizing tokens thatrevert on transfer attempts (for specific callers) can cause transactions tofail, leading to a denial of service. (For FiFo implementations)
For general orderbooks (User A creates anorder and User B accepts it), the DoS potential is rather low as each “brokenorder” would not pose a risk to the system.
Frontrunning poses a significant threat tothe integrity of orderbook systems, enabling attackers to manipulate orders totheir advantage:
Increase Price: By changing an order andincreasing the price just before it's accepted, an attacker can drain theentire approved amount from a victim. This is an issue which was almost presentin all orderbook implementations I have audited.
Cancel and Replace: If the system allows,an attacker could cancel an existing order and replace it with their a new usingthe same ID, exploiting the orderbook's logic (if it is vulnerable to this).
Ensuring the correctness of index handlingis crucial for the integrity of order creations. Flawed indexing can lead tooverwrites, lost orders, or duplicate entries, compromising the system'sreliability.
Order cancellation mechanisms must besecure and robust. Incorrect handling can lead to situations where orders areeither not properly cancelled, allowing them to be filled subsequently, orimproperly releasing locked funds.
Reentrancy vulnerabilities are almostalways existent, specifically for orderbook contracts that perform externalcalls could be vulnerable to reentrancy, or if they transfer tokens withincallbacks or native ETH.
6.Sophisticated: Order to self
An attacker placing orders to themselvescan exploit potential flaws in the system's logic, leading to unexpectedbehavior such as draining funds or locking up the orderbook. This would be amore creative exploit idea.
