PenTest Playbook
  • Welcome!
  • Web App Pentesting
    • SQL Injection
    • NoSQL Injection
    • XSS
    • CSRF
    • SSRF
    • XXE
    • IDOR
    • SSTI
    • Broken Access Control/Privilege Escalation
    • Open Redirect
    • File Inclusion
    • File Upload
    • Insecure Deserialization
      • XMLDecoder
    • LDAP Injection
    • XPath Injection
    • JWT
    • Parameter Pollution
    • Prototype Pollution
    • Race Conditions
    • CRLF Injection
    • LaTeX Injection
    • CORS Misconfiguration
    • Handy Commands & Payloads
  • Active Directory Pentest
    • Domain Enumeration
      • User Enumeration
      • Group Enumeration
      • GPO & OU Enumeration
      • ACLs
      • Trusts
      • User Hunting
    • Domain Privilege Escalation
      • Kerberoast
        • AS-REP Roast (Kerberoasting)
        • CRTP Lab 14
      • Targeted Kerberoasting
        • AS-REP Roast
        • Set SPN
      • Kerberos Delegation
        • Unconstrained Delegation
          • CRTP Lab 15
        • Constrained Delegation
          • CRTP Lab 16
        • Resource Based Constrained Delegation (RBCD)
          • CRTP Lab 17
      • Across Trusts
        • Child to Parent (Cross Domain)
          • Using Trust Tickets
            • CRTP Lab 18
          • Using KRBTGT Hash
            • CRTP Lab 19
        • Cross Forest
          • Lab 20
        • AD CS (Across Domain Trusts)
          • ESC1
            • CRTP Lab 21
        • Trust Abuse - MSSQL Servers
          • CRTP Lab 22
    • Lateral Movement
      • PowerShell Remoting
      • Extracting Creds, Hashes, Tickets
      • Over-PassTheHash
      • DCSync
    • Evasion
      • Evasion Cheetsheet
    • Persistence
      • Golden Ticket
        • CRTP Lab 8
      • Silver Ticket
        • CRTP Lab 9
      • Diamond Ticket
        • CRTP Lab 10
      • Skeleton Key
      • DSRM
        • CRTP Lab 11
      • Custom SSP
      • Using ACLs
        • AdminSDHolder
        • Rights Abuse
          • CRTP Lab 12
        • Security Descriptors
          • CRTP Lab 13
    • Tools
    • PowerShell
  • AI Security
    • LLM Security Checklist
    • GenAI Vision Security Checklist
    • Questionnaire for AI/ML/GenAI Engineering Teams
  • Network Pentesting
    • Information Gathering
    • Scanning
    • Port/Service Enumeration
      • 21 FTP
      • 22 SSH
      • 25, 465, 587 SMTP
      • 53 DNS
      • 80, 443 HTTP/s
      • 88 Kerberos
      • 135, 593 MSRPC
      • 137, 138, 139 NetBios
      • 139, 445 SMB
      • 161, 162, 10161, 10162/udp SNMP
      • 389, 636, 3268, 3269 LDAP
      • Untitled
      • Page 14
      • Page 15
      • Page 16
      • Page 17
      • Page 18
      • Page 19
      • Page 20
    • Nessus
    • Checklist
  • Mobile Pentesting
    • Android
      • Android PenTest Setup
      • Tools
    • iOS
  • DevSecOps
    • Building CI Pipeline
    • Threat Modeling
    • Secure Coding
      • Code Review Examples
        • Broken Access Control
        • Broken Authentication
        • Command Injection
        • SQLi
        • XSS
        • XXE
        • SSRF
        • SSTI
        • CSRF
        • Insecure Deserialization
        • XPath Injection
        • LDAP Injection
        • Insecure File Uploads
        • Path Traversal
        • LFI
        • RFI
        • Prototype Pollution
        • Connection String Injection
        • Sensitive Data Exposure
        • Security Misconfigurations
        • Buffer Overflow
        • Integer Overflow
        • Symlink Attack
        • Use After Free
        • Out of Bounds
      • C/C++ Secure Coding
      • Java/JS Secure Coding
      • Python Secure Coding
  • Malware Dev
    • Basics - Get detected!
    • Not so easy to stage!
    • Base64 Encode Shellcode
    • Caesar Cipher (ROT 13) Encrypt Shellcode
    • XOR Encrypt Shellcode
    • AES Encrypt Shellcode
  • Handy
    • Reverse Shells
    • Pivoting
    • File Transfers
    • Tmux
  • Wifi Pentesting
    • Monitoring
    • Cracking
  • Buffer Overflows
  • Cloud Security
    • AWS
    • GCP
    • Azure
  • Container Security
  • Todo
Powered by GitBook
On this page
  • Race Conditions
  • Description
  • Example with Scenario
  • Payloads and Test Cases
  • Testing for Race Conditions
  • Mitigation
  1. Web App Pentesting

Race Conditions

Race Conditions

Description

Race conditions occur when a system's behavior depends on the sequence or timing of uncontrollable events such as thread execution. They can lead to unexpected behaviors, including data corruption, unauthorized actions, and system crashes. In web applications, race conditions often arise when multiple concurrent requests manipulate shared resources without proper synchronization.

Example with Scenario

Consider a banking application where users can transfer money between accounts. If the application does not properly handle concurrent transactions, an attacker could exploit a race condition to transfer more money than they actually have.

Scenario: A user initiates a transfer of $100 from Account A to Account B:

  1. Check balance of Account A.

  2. Subtract $100 from Account A.

  3. Add $100 to Account B.

If steps 1 and 2 are not atomic and are executed concurrently by multiple requests, the same balance might be subtracted multiple times, leading to an inconsistent state.

Payloads and Test Cases

Payloads

  1. Transfer Exploit:

    • Multiple concurrent requests transferring the same amount from one account to another.

    • Payload: Repeated POST requests to the transfer endpoint.

  2. Inventory Depletion:

    • Concurrent requests to purchase the last item in stock.

    • Payload: Repeated POST requests to the purchase endpoint.

  3. Balance Withdrawal:

    • Concurrent requests to withdraw more than the available balance.

    • Payload: Repeated POST requests to the withdrawal endpoint.

Test Cases

  1. Test Case 1: Concurrent Transfers

    • Input:

      {
        "from_account": "A123",
        "to_account": "B456",
        "amount": 100
      }
    • Action: Send multiple concurrent requests to the transfer endpoint.

    • Expected Result: Transfer amount should be consistent and not exceed the available balance.

  2. Test Case 2: Inventory Purchase

    • Input:

      {
        "item_id": "ITEM123",
        "quantity": 1
      }
    • Action: Send multiple concurrent requests to the purchase endpoint when only one item is left in stock.

    • Expected Result: Only one request should succeed, and the stock count should not go below zero.

  3. Test Case 3: Balance Withdrawal

    • Input:

      {
        "account_id": "A123",
        "amount": 1000
      }
    • Action: Send multiple concurrent requests to withdraw an amount exceeding the available balance.

    • Expected Result: Withdrawals should be rejected if the balance is insufficient.

Testing for Race Conditions

Using Burp Suite

  1. Setup:

    • Open Burp Suite and configure it to intercept the target application’s traffic.

    • Identify the request that may be vulnerable to a race condition.

  2. Intruder Configuration:

    • Right-click the request and select "Send to Intruder."

    • In the Intruder tab, set the attack type to "Pitchfork."

    • Add multiple payload positions where concurrent execution might cause a race condition.

  3. Payloads:

    • Add payloads to the positions identified.

    • Configure the payload sets to test concurrent execution.

  4. Start Attack:

    • Launch the Intruder attack to send multiple concurrent requests.

    • Analyze the responses to identify any inconsistencies or unexpected behaviors.

Using Turbo Intruder

  1. Setup:

    • Install the Turbo Intruder extension in Burp Suite.

    • Right-click the target request and select "Send to Turbo Intruder."

  2. Script Configuration:

    • Use the provided script template to configure the concurrent request attack.

    • Modify the script to increase the number of threads and specify the target endpoint.

  3. Execute Attack:

    • Run the Turbo Intruder script to send a high volume of concurrent requests.

    • Monitor the responses for signs of race conditions, such as duplicated actions or data corruption.

Using Other Tools

  1. OWASP ZAP:

    • Identify the target request and configure ZAP to intercept it.

    • Use the "Fuzzer" tool to send multiple concurrent requests.

    • Analyze the responses for race condition indicators.

  2. Custom Scripts:

    • Write custom scripts using languages like Python with libraries such as requests and concurrent.futures.

    • Design the script to send concurrent requests and monitor for race condition effects.

  3. Load Testing Tools:

    • Use load testing tools like JMeter or Gatling to simulate high-concurrency scenarios.

    • Configure the tools to send multiple concurrent requests and analyze the application’s behavior.

Mitigation

  1. Atomic Operations:

    • Ensure critical sections of code are executed atomically to prevent race conditions.

    • Use database transactions to enforce atomicity.

  2. Locks and Synchronization:

    • Implement locking mechanisms (e.g., mutexes, semaphores) to synchronize access to shared resources.

  3. Idempotent Operations:

    • Design operations to be idempotent, ensuring that repeated execution has the same effect as a single execution.

  4. Optimistic Concurrency Control:

    • Use versioning or timestamps to detect and prevent conflicting updates.

  5. Rate Limiting:

    • Implement rate limiting to control the frequency of requests.

  6. Security Testing:

    • Regularly perform security testing to identify and fix race condition vulnerabilities.

PreviousPrototype PollutionNextCRLF Injection

Last updated 10 months ago