🔗 Invalid Redirects & ⏱️ Race Conditions

Invalid Forwarding and Redirecting

Many websites redirect users after certain actions — after login, after completing a form, or when a page has moved. The URL to redirect to is often passed as a parameter: https://school.edu.au/login?redirect=/dashboard. After a successful login, the server sends the user to /dashboard.

The vulnerability occurs when an attacker changes that redirect parameter to point to a malicious site: https://school.edu.au/login?redirect=https://evil-site.com/fake-login. The user sees the legitimate school URL, trusts it, logs in, and is then silently redirected to a fake login page on the attacker's site that asks for their credentials again (claiming "session expired"). The user, believing they are still on the school site, types their password into the attacker's fake page. This is called an open redirect vulnerability.

Why it works: The user looks at the URL, sees school.edu.au, and trusts it. They do not notice the redirect parameter hidden in the URL. The school's own server performs the redirect, so the browser does not show a warning.

Prevention: Whitelist allowed redirect URLs. Only redirect to paths on your own domain (e.g., starting with /). Never redirect to a full URL provided by user input. If you must allow external redirects, validate against a strict whitelist of approved domains.

Race Conditions

A race condition occurs when the outcome of an operation depends on the timing of two or more processes that happen simultaneously. If the code assumes operations happen one at a time, but they actually overlap, unexpected and exploitable behaviour can result.

Think of it like two people trying to withdraw the last $100 from a shared bank account at the same ATM moment. Both ATMs check the balance: $100. Both approve the withdrawal. Both dispense $100. The account now has -$100. The bank just lost money because two operations "raced" each other and neither saw the other's withdrawal before approving its own.

How attackers exploit this: An attacker sends hundreds of simultaneous requests to redeem a discount code, transfer money, or vote in a poll. If the server processes the "check if already used" and "mark as used" steps separately (not atomically), many requests can pass the check before any of them mark the code as used. Result: one discount code used 50 times.

Prevention: Use database transactions and locking to make read-check-write operations atomic (happen as one indivisible step). Use mutex locks or optimistic concurrency control (version numbers). In web applications, use idempotency tokens — each form submission gets a unique token that can only be used once, regardless of how many times the request is sent.

💡 Real-World: Starbucks Gift Card Race Condition

In 2015, a security researcher discovered a race condition in the Starbucks gift card system. By sending simultaneous transfer requests between two cards, they could duplicate the balance. Transfer $5 from Card A to Card B, but send the request multiple times at the exact same moment. Card B receives $5 multiple times before Card A's balance is decremented. The researcher reported it through Starbucks' bug bounty program (responsible disclosure) and it was patched. This is a textbook race condition: check balance → approve transfer → update balance, but the steps were not atomic.