TIMING ATTACKS

INFORMATION DISCLOSURES

leveraging the differences in response delays, a threat actor can uncover information they should not have access to. For example, timing differences can be used to enumerate the usernames of an application, making it easier to stage a password-guessing attack and gain access to accounts.

RACE CONDITIONS

similar to business logic flaws in that a threat actor can cause the application to perform unintended actions. However, the issue's root cause is how the web application processes requests, making it possible to cause the race condition. For example, if we send the same coupon request several times simultaneously, it might be possible to apply it more than once.

#identifying potential race condition vulnerability through source code review
if user['balance'] >= amount:
  conn.execute('UPDATE users SET balance = balance + ? WHERE account_number = ?', (amount, target_account_number))
  conn.commit()

  conn.execute('UPDATE users SET balance = balance - ? WHERE account_number = ?', (amount, session['user']))
  conn.commit()
  
 * in the above code, you can pinpoint areas where multiple database operations are performed without proper transaction handling
    - if user['balance'] >= amount, the application first updates the recipient's 
      balance with the command UPDATE users SET balance = balance + ? WHERE 
      account_number = ?, followed by a commit. Then, it updates the sender’s 
      balance using UPDATE users SET balance = balance - ? WHERE account_number = ? 
      and commits again. Since these updates are committed separately and not part of 
      a single atomic transaction, there’s no locking or proper synchronisation 
      between these operations. This lack of a transaction or locking mechanism 
      makes the code vulnerable to race conditions, as concurrent requests could 
      interfere with the balance updates.

MITIGATIONS

• Use Atomic Transactions: implement atomic database transactions to ensure that all steps of a fund transfer (deducting and crediting balances) are performed as a single unit. This ensures that either all steps of the transaction succeed or none do, preventing partial updates that could lead to an inconsistent state.

• Implement Mutex Locks: Mutex Locks ensures that only one thread accesses the shared resource (such as the account balance) at a time. This would prevent multiple requests from interfering with each other during concurrent transactions.

• Apply Rate Limits: implementing rate limits on critical functions like funds transfers and withdrawals would limit the number of requests processed within a specific time frame, reducing the risk of abuse through rapid, repeated requests.