buytickets function can be completely blocked under high demand
Summary
As outlined in the document provided by the sponsor:
https://docs.google.com/document/d/12kGD8nJ9DiR0cW5ngT8A6gE7GBG7NwiDCOIkGksL8qY/edit,
the process of buying tickets begins with an HTTP request to the API, which returns the available number of tickets, the purchase price, and a signature. The number of tickets is then validated by the _checkTicketPurchaseable function and checked against the possible supply, as seen here. Due to the asynchronous nature of these requests, it’s possible that the data and signatures could be generated just before another user completes a purchase, rendering the API data outdated and causing the transaction to revert, effectively paralyzing one of the application's core functions.
When trying to purchase tickets, an HTTP request goes to our API to specify the address of the buyer and the chosen bundle, the response will include the price to pay, the actual number of tickets (after computing potential bonuses and ensuring we don’t exceed the ticket supply or the max holding), a nonce and an ECDSA signature that will allow the contract to verify that this purchase is valid
Root Cause
Signatures and data are generated based on data at a specific moment without considering previous purchase transactions, leading to inconsistencies when other users buy tickets.
Internal pre-conditions
The raffle is created.
There is a possibility of purchasing a large number of promotional ticket bundles, causing the API data to differ from what is shown on the website.
High demand for the raffle and a large volume of API requests.
External pre-conditions
No response
Attack Path
No response
Impact
Most purchase transactions initiated through the buyTickets function will be rejected due to outdated data (ticketCount). This will cause the application's core ticket-buying feature to not function as intended.
PoC
No response
Mitigation
The buyTickets process should involve some form of reservation system for the requested number of tickets. This reservation should be factored into subsequent requests to prevent multiple users from purchasing "the same" tickets. The reservation should also have a time limit to allow other users to purchase tickets if the original user decides not to complete the transaction.
PNS
Medium
buytickets
function can be completely blocked under high demandSummary
As outlined in the document provided by the sponsor: https://docs.google.com/document/d/12kGD8nJ9DiR0cW5ngT8A6gE7GBG7NwiDCOIkGksL8qY/edit, the process of buying tickets begins with an HTTP request to the API, which returns the available number of tickets, the purchase price, and a signature. The number of tickets is then validated by the
_checkTicketPurchaseable
function and checked against the possible supply, as seen here. Due to the asynchronous nature of these requests, it’s possible that the data and signatures could be generated just before another user completes a purchase, rendering the API data outdated and causing the transaction to revert, effectively paralyzing one of the application's core functions.Root Cause
Signatures and data are generated based on data at a specific moment without considering previous purchase transactions, leading to inconsistencies when other users buy tickets.
Internal pre-conditions
External pre-conditions
No response
Attack Path
No response
Impact
Most purchase transactions initiated through the
buyTickets
function will be rejected due to outdated data (ticketCount
). This will cause the application's core ticket-buying feature to not function as intended.PoC
No response
Mitigation
The
buyTickets
process should involve some form of reservation system for the requested number of tickets. This reservation should be factored into subsequent requests to prevent multiple users from purchasing "the same" tickets. The reservation should also have a time limit to allow other users to purchase tickets if the original user decides not to complete the transaction.