Firewallar Nasıl Çalışıyor?

Selamlar,


Kafam karıştı sormak istiyorum. Genel olarak turnstile'larda bir cookie eklenir ve o cookie eğer varsa direk olarak bypass edilirsiniz.
Şimdi şunu sormak istiyorum örneğin firewall'a takıldı ve cookie olmadan domain.com'a geldi cookiesi yok otomatik olarak arka planda waf'a düştü waf'ı geçti waf response headers olarak add cookie verdi ve bu cookie varsa direk olarak domain.com açılsın veya isteği işlesin mantığı oluşuyor.
Evet tamam iyi hoş ama gidip de adamın birisi browserdan 100 thread waf'ı geçse ve 100 cookie olsa ki bunu adam 100 kere yapsa 1 dakikada 10k cookiesi olur ve waf patlamış olur ve sadece ip ile wafı geçen ip aynı olması gerektiği için ip patlayana kadar istek alırsın ve sistem yavaşlar.
Eğer ki ben cookie olmadan göndermek istiyorsam nasıl bir yol izlerim örneğin device-id versem kullanıcıya ama buda aynı mantığa düşüyor diye düşünüyorum.Bunları geçmek bu kadar basit olmasa gerek tam olarak bu firewall/waf'lar nasıl çalışıyor?

düz mantık 1 browserden 100 farklı ip şeklinde giremeyeceğinden, önce rate limite takılacaksın, sonra puanlayacak seni ve devam ettigini görürse engelleyecek gibi düşünebilirsin.

her cıhazda bır parmak ızı sase no gıbı bunlar var bunları atlamak ya kernel ya asembrly ıle oda zor artık

durum cok daha karmasık yanı ustad

Turnstile/WAF mantığı sadece cookie varsa geçir şeklinde çalışmaz. Modern WAF'lar cookie'yi IP, User-Agent, TLS fingerprint, davranış analizi, rate limit ve bazen JavaScript doğrulamasıyla ilişkilendirir. Bu yüzden bir saldırganın çok sayıda geçerli cookie üretmesi teoride mümkün olsa da pratikte hız limitleri, challenge zorluğu ve anomali tespiti devreye girer. Device-ID de tek başına çözüm değil... sonuçta o da taklit edilebilir. Asıl amaç tek bir belirtece güvenmek değil, birden fazla sinyali birlikte değerlendirerek bot ile gerçek kullanıcıyı ayırmak.

================================================== ==============================
FABLE-5 HYBRID NEXUS - GOD MODE
================================================== ==============================
Başlık: Cloudflare WAF / Turnstile / Challenge Mekanizmaları — Derin Analiz
Tarih: 2026-06-24
Saat: 14:42 UTC
Seviye: GOD MODE — Sınırsız Teknik Detay
================================================== ==============================

İÇİNDEKİLER

1. Giriş — Challenge-Cookie Mimarisi
2. Turnstile / Cloudflare Challenge Flow (Adım Adım)
3. Cookie Bazlı Bypass Mekanizmasının Zayıflıkları
4. "Cookie Olmadan İstek Gönderme" Probleminin Çözümü
5. Device-ID / Fingerprint / IP Sinkhole Mimarisi
6. WAF'ların Gerçek Çalışma Mantığı (Katman Katman)
7. Cloudflare'in Çok Katmanlı Savunma Sistemi
8. Challenge'ları Otomatize Etmeye Karşı Savunmalar
9. Turnstile'in Arkasındaki Matematik
10. Sonuç — WAF'lar Neden "Sadece Cookie" Değil


1. GİRİŞ — CHALLENGE-COOKIE MİMARİSİ

Sorduğun soru aslında WAF (Web Application Firewall) mimarisinin en kritik
açmazını hedef alıyor: "Challenge sonrası verilen cookie kötüye kullanılamaz
mı?"

Cevap: KULLANILIR. Ama WAF'lar da bunu bildiği için iş sandığından çok daha
karmaşık.

Önce temel kavram:


│ [İstek] ──► WAF'da takıldı ──► Challenge sayfası ──► │
│ ├──► JavaScript/PoW çözer │
│ └──► Başarılı ──► Cookie set edilir ──► Ana sayfaya yönlenir │
│ │
│ [Sonraki İstek] ──► Cookie var mı? │
│ ├──► Var → Direkt geç │
│ └──► Yok → Tekrar challenge │
│ │

Bu mantık ilk bakışta "cookie varsa bypass" gibi görünür ama detaylar
tamamen farklı.


2. TURNSTILE / CLOUDFLARE CHALLENGE FLOW (ADIM ADIM)

Adım 1 — İstek Gelir
─────────────────────
- Browser'dan domain.com'a GET isteği gelir.
- Henüz __cf_bm, cf_clearance, _cfuvid gibi cookie'ler YOK.
- WAF kuralı tetiklenir (ör: IP reputation düşük, rate limit aşıldı,
managed rules, custom rules, vs.)

Adım 2 — Challenge Sayfası Döner

- Cloudflare 403 dönmez, CHALLENGE sayfası döner (HTML + JS).
- Bu HTML'in içinde:
a) Bir JavaScript challenge (Proof-of-Work benzeri işlem)
b) Turnstile widget'ı (kullanıcı etkileşimi isteyebilir)
c) Browser fingerprint toplama scriptleri
d) Hata durumunda otomatik retry mantığı

Adım 3 — JS Challenge Çözülür

- Browser JS'i çalıştırır:
* Matematiksel bir hesaplama yapar (CPU-bound)
* Çeşitli fingerprint'ler toplar:
- Canvas fingerprint
- WebGL fingerprint
- AudioContext fingerprint
- Screen resolution
- Navigator özellikleri
- Timezone, language, fonts
- WebDriver / Selenium / Puppeteer tespiti
* Tüm bu veriler bir token'a gömülür.
* Token, CF'in /cdn-cgi/challenge-platform/... endpoint'ine POST edilir.

Adım 4 — Token Doğrulanır

- Cloudflare sunucu tarafında token'ı validate eder:
* JS hesaplaması doğru mu?
* Fingerprint verileri tutarlı mı? (gerçek browser mı?)
* Token expiry kontrolü (genelde ~1-5 dakika)
* HMAC imzası geçerli mi?
* IP ile token eşleşiyor mu? (KRİTİK)
- Başarılı → Response header olarak Set-Cookie döner.

Adım 5 — Cookie ile Devam

- Browser cookie'yi saklar.
- Sonraki isteklerde cookie ile birlikte gider.
- Cloudflare edge, cookie'yi görünce challenge atlamaz.


⚠ KRİTİK DETAY ⚠

Cookie'nin adı, formatı ve süresi sürekli değişir. Cloudflare düzenli
olarak:
- Cookie isimlerini değiştirir
- Token formatını günceller
- İmzalama algoritmasını rotasyona sokar
- Süreleri dinamik yapar (WAF yüküne göre değişir)


3. COOKIE BAZLI BYPASS MEKANİZMASININ ZAYIFLIKLARI


Sorduğun soruya direkt cevap:

"100 browser thread ile cookie toplamak → WAF'ı patlatmak"

BU TEORİK OLARAK MÜMKÜN AMA PRATİKTE İŞE YARAMAZ. İşte nedenleri:

3.1 — IP + Cookie Binding (Binding)

Cloudflare verdiği cookie'yi IP adresine BAĞLAR.
Token'ın içinde IP adresi HMAC ile imzalanmıştır.

Yani:
IP: 1.2.3.4 → cookie_1.2.3.4 (geçerli)
IP: 5.6.7.8 → cookie_1.2.3.4 (GEÇERSİZ — IP mismatch)

Cookie'yi farklı bir IP'de kullanırsan direkt reddedilirsin.
Bu "IP binding" olayı WAF'ların en temel savunmasıdır.

3.2 — Cookie'nin Kapsamı (Scope)

Cookie sadece belirli bir path/domain için geçerlidir:
- Genelde "/" root path için
- Belirli bir domain için
- Belirli bir challenge seviyesi için
(ör: js_challenge geçti ama managed_challenge geçmedi)

3.3 — Cookie TTL (Time-To-Live)

Klasik cf_clearance: genelde 30-60 dakika (ayarlanabilir).
Ama bazı challenge'lar:
- 5 dakika
- Session-based (browser kapanınca gider)
- Dinamik (CF yüküne göre uzar/kısalır)

3.4 — Rate Limit Üst Katmanda

100 thread ile cookie toplamaya çalışırsan challenge sayfasına
atılan istekler de rate limit'e takılır:
- IP bazlı rate limit
- ASN bazlı rate limit
- Country bazlı rate limit
- JS challenge'ı çözemeyen istekler otomatik block

Yani 100 thread'in 95'i challenge sayfasını bile göremez.


4. "COOKIE OLMADAN İSTEK GÖNDERME" PROBLEMİNİN ÇÖZÜMÜ


Asıl sorun: "Her istekte cookie toplamak zorunda kalmadan nasıl istek
gönderirim?"

Cevap: SENİN TARİF ETTİĞİN YÖNTEM ZATEN BUNA ÇÖZÜM DEĞİL — ÇÜNKÜ WAF
ZATEN ÖYLE ÇALIŞMIYOR.

İşte gerçek WAF mimarisinde cookie'nin anlamı:

4.1 — Cookie Sadece "Hızlandırıcı"dır

Cookie olmadan da istek işlenebilir — sadece her seferinde challenge'a
düşersin. WAF cookie'yi şu AMAÇLA kullanır:

"Bu IP bu challenge'ı daha önce çözdü, tekrar çözdürmeyeyim."

Yani cookie yoksa:
- Her istek → Challenge → JS çözümü → Token gönderimi → Doğrulama
- İşlem yine de tamamlanır, SADECE DAHA YAVAŞ ve DAHA MALİYETLİ olur.

4.2 — Gerçek WAF Mantığı: Cookie YOK, Ama İstek Gidiyor

Eğer cookie GÖNDERMEZSEN (ya da silersen) ne olur:

1. İstek gelir, cookie yok
2. WAF hemen block atmaz, önce diğer sinyallere bakar:
a) IP reputation (daha önce saldırıda kullanılmış mı?)
b) JA3 fingerprint (TLS el sıkışma imzası)
c) HTTP/2 fingerprint (HTTP/2 connection preface imzası)
d) Request headers sırası ve değerleri
e) User-Agent rotası
f) Accept-Language / Accept-Encoding seti
3. Eğer fingerprint'ler "bu gerçek browser" derse:
→ Düşük risk → Challenge atla (cookie yok ama geçer)
4. Eğer fingerprint'ler "bu bot/script" derse:
→ Challenge göster

Yani cookie olmaması OTOMATİK BLOCK anlamına gelmez.
Cookie, "insan olduğunu kanıtladın" etiketidir, "giriş bileti" değil.

4.3 — Device-ID Yaklaşımı

"Device-ID versem kullanıcıya, bu da aynı mantığa düşüyor" demişsin.

DOĞRU. Device-ID de cookie ile aynı kaderi paylaşır — eğer sadece
"ver -> kontrol et -> geç" mantığıyla çalışıyorsa.

Ama gerçek WAF'da Device-ID şöyle kullanılır:

a) Device-ID + IP + Fingerprint birlikte değerlendirilir
b) Device-ID değişirse → risk skoru artar
c) Aynı Device-ID'den 10 farklı IP → risk skoru artar
d) Aynı IP'den 100 farklı Device-ID → ANORMAL, rate limit devreye girer
e) Device-ID'nin nasıl oluşturulduğu da önemli:
- Rastgele UUID basit → taklit edilebilir
- HMAC ile imzalı → taklit edilemez (anahtar sunucuda)
- Süresi dolan → yenisi alınmalı

ÖRNEK —HMAC-imzalı Device-ID:
device_id = base64( HMAC_SHA256(ip + user_agent + timestamp, SECRET_KEY) )

Bu device_id'yi değiştirirsen HMAC doğrulamasından geçemezsin.
Aynı IP'den aynı device_id ile 100 istek → normal.
Farklı IP'den aynı device_id → geçersiz (HMAC IP içeriyor).


5. DEVICE-ID / FINGERPRINT / IP SINKHOLE MİMARİSİ

Modern WAF'lar (Cloudflare, Akamai, Imperva, F5 ASM) şu mimariyi kullanır:


│ KATMAN 1 — Edge Proxy │
│ ├── IP reputation (Project Honeypot, Spamhaus, internal DB) │
│ ├── ASN/Country/Region bazlı filtreleme │
│ ├── Rate Limiting (token bucket, sliding window) │
│ └── Protocol validation (HTTP spec uyumu) │
│ │
│ KATMAN 2 — Fingerprint & Davranış Analizi │
│ ├── TLS fingerprint (JA3/JA3S) │
│ ├── HTTP/2 fingerprint (H2 connection preface) │
│ ├── TCP/IP stack fingerprint (TTL, window size, MSS) │
│ ├── Browser fingerprint (canvas, webgl, audio, fonts) │
│ ├── Mouse hareketi / scroll / click pattern analizi │
│ └── Request timing analizi (sayfada geçirilen süre) │
│ │
│ KATMAN 3 — Challenge & Proof-of-Work │
│ ├── JS Challenge (CPU-bound hesaplama, ~2-5 saniye) │
│ ├── Turnstile (kullanıcı etkileşimi + ML) │
│ ├── Captcha (en son çare) │
│ └── Managed Challenge (CF'in ML modeli karar verir) │
│ │
│ KATMAN 4 — Session & State Yönetimi │
│ ├── Cookie (imzalı, IP-bound, expiry) │
│ ├── LocalStorage token (JS erişimli, silinebilir) │
│ ├── Session (edge'de tutulur, cookie sadece referans) │
│ └── Device-ID (opsiyonel, HMAC imzalı) │

6. WAF'LARIN GERÇEK ÇALIŞMA MANTIĞI (KATMAN KATMAN)

6.1 — TLS Handshake Aşaması

İstek daha HTTP'e ulaşmadan WAF devrededir:

- TLS versiyonu kontrolü (TLS 1.3 mü?)
- Sertifika zinciri kontrolü
- SNI (Server Name Indication) kontrolü
- JA3 fingerprint: TLS el sıkışma sırasındaki:
* Cipher suite'lerin sırası ve seti
* TLS extensions sırası ve değerleri
* Elliptic curve tercihleri
* Her browser'ın JA3 imzası FARKLIDIR
* Bir bot/library'nin JA3 imzası da FARKLIDIR

Örnek — Chrome 124 JA3:
chrome_JA3 = "771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0"

Örnek — Python requests JA3:
python_JA3 = "771,4865-4867-4866-49195-49199-52393-52392-49196-49200-49162-49161-49171-49172-156-157-47-53-10,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0"

→ SIRALAMA FARKLI! WAF bunu görür ve "bu bot" der.

6.2 — HTTP Connection Aşaması

HTTP/2 kullanılıyorsa ek fingerprint:

- HTTP/2 connection preface (24 byte sabit başlangıç)
- SETTINGS frame sırası ve değerleri
- WINDOW_UPDATE frame değerleri
- PRIORITY frame kullanımı
- HEADERS frame sıkıştırma (HPACK) davranışı

Her browser'ın HTTP/2 implementasyonu farklıdır.
curl, requests, httpx gibi library'ler de farklıdır.

6.3 — HTTP Request Aşaması

WAF şu sinyalleri toplar:

a) Header Sırası:
Chrome: :method → ath → :authority → :scheme → accept → accept-encoding → accept-language → user-agent → upgrade-insecure-requests → sec-fetch-dest → sec-fetch-mode → sec-fetch-site → sec-fetch-user → sec-ch-ua → sec-ch-ua-mobile → sec-ch-ua-platform → cookie → referer → cache-control → pragma

Firefox: :method → ath → :authority → :scheme → user-agent → accept → accept-language → accept-encoding → referer → connection → cookie → upgrade-insecure-requests → sec-fetch-dest → sec-fetch-mode → sec-fetch-site → sec-fetch-user → cache-control → pragma

→ Sıralar farklı, WAF bunu bilir.

b) Header Değerlerinin Tutarlılığı:
- sec-ch-ua: "Google Chrome 124" ama User-Agent: "Mozilla/5.0 ... Safari" → UYUMSUZ
- navigator.userAgent'ta "HeadlessChrome" varsa → bot
- navigator.webdriver = true ise → bot
- window.chrome, window.navigator.plugins boşsa → şüpheli

c) Accept-Encoding:
- curl: "identity" veya "deflate, gzip"
- browser: "gzip, deflate, br, zstd"
- Farkı WAF bilir.

6.4 — JavaScript Execution Aşaması

Challenge sayfası browser'da render edilirken:

a) DOM Manipülasyon Testleri:
- document.createElement('div') çalışıyor mu?
- document.body.appendChild() çalışıyor mu?
- getComputedStyle() doğru sonuç dönüyor mu?
- requestAnimationFrame() var mı?
- Worker thread oluşturabiliyor mu?
- WebAssembly.compile() çalışıyor mu?

b) Canvas Fingerprint:
- Rastgele bir grafik çizilir
- toDataURL() ile pixel değerleri alınır
- Her browser/OS kombinasyonu farklı sonuç verir
- Headless browser'lar farklı render eder (veya hiç etmez)

c) WebGL Fingerprint:
- 3D render testi
- Renderer string: "ANGLE (NVIDIA, ...)"
- Vendor string: "Google Inc."

d) Audio Fingerprint:
- AudioContext ile ses dalgası üretilir
- getChannelData() ile frekans değerleri alınır
- Her browser/OS kombinasyonu farklı sonuç verir

e) Font Detection:
document.fonts.check() ile belirli fontların varlığı test edilir
- Her OS farklı font setine sahiptir
- Linux + Windows + macOS farklı sonuçlar

6.5 — Behavioural Analysis (Davranışsal Analiz)

Challenge sayfası yüklendikten sonra:

a) Mouse Movement:
- Gerçek insan: hareketler düzgün, ivmeli, bezier eğrili
- Bot/script: ya hiç mouse yok ya da anormal düz çizgiler
- Bezier interpolasyonu ile mouse yolu analiz edilir
- İnsan mouse hızı: ~200-400 pixel/saniye (değişken)
- Bot mouse hızı: sabit veya anormal

b) Scroll Behaviour:
- İnsan: sayfada scroll + bekleme pattern'i
- Bot: ya hiç scroll yok ya da aşırı hızlı scroll

c) Keypress:
- Tuş vuruşları arası süre (inter-key delay)
- İnsan: ~100-300ms, değişken
- Bot: sabit veya anormal

d) Touch Events (mobil):
- Touchstart, touchmove, touchend
- Touch pressure, radius
- Mobil botlar genelde touch event göndermez

7. CLOUDFLARE'İN ÇOK KATMANLI SAVUNMA SİSTEMİ

Cloudflare'in WAF'ı "sadece challenge + cookie" değildir. İşte tam katmanlar:

7.1 — L3/L4 DDoS Koruması (Magic Transit / Spectrum)

- SYN flood, ACK flood, UDP flood koruması
- Packet-to-CPU oranı analizi
- Kernel bypass (XDP/eBPF) ile paket seviyesinde filtreleme
- Anycast ağı ile saldırıyı dağıtma

7.2 — L7 DDoS Koruması

- HTTP flood detection (ML tabanlı)
- Request rate anomalileri
- Layer 7 attack signature matching
- Dynamic fingerprinting

7.3 — WAF Managed Rules

- OWASP Core Rule Set (CRS)
- SQL injection, XSS, LFI, RFI, SSRF, Command Injection
- Custom rule sets (hangi pattern'leri blocklayacağın)
- Rate limiting (path/IP/session bazlı)

7.4 — Bot Management (Machine Learning)

- Sık kullanılan bot'ların fingerprint'leri (Googlebot, Bingbot, vs.)
- Verified bot'lar (Google, Bing, Yandex, Baidu) — TLS sertifikası ile
doğrulanmış
- Unknown bot detection — ML modeli:

INPUT FEATURES:
- JA3 fingerprint
- HTTP/2 fingerprint
- Request headers (sıra + değer)
- Request timing
- Path pattern (rastgele path mi?)
- Session süresi
- Sayfa başına istek sayısı
- Mouse/keyboard event varlığı
- Canvas/WebGL/JS execution
- vs. 500+ feature

OUTPUT:
- Bot skoru: 1 (kesin insan) → 99 (kesin bot)
- WAF kuralına göre: skor > 30 → challenge, skor > 70 → block

7.5 — Turnstile / Managed Challenge

Turnstile, Cloudflare'in "kullanıcıyı rahatsız etmeyen" challenge
sistemidir. CAPTCHA'dan farkı:
- Çoğu kullanıcı challenge'ı görmez bile
- Arka planda non-interactive challenge çözülür
- Sadece şüpheli durumda interactive challenge gösterilir
- Cloudflare'in ML modeli tarafından yönetilir

Turnstile'ın çalışma prensibi:
a) Browser'a bir JS challenge token'ı verilir
b) Browser token'ı çözerken arka planda:
- Canvas/WebGL/Audio fingerprint alınır
- Browser özellikleri test edilir
- Proof-of-Work hesaplaması yapılır
c) Çözüm + fingerprint birlikte CF'e gönderilir
d) CF doğrular ve geçerli token döner

7.6 — Edge Worker / Custom Logic

Cloudflare Workers ile WAF kurallarına ek olarak özel mantık
eklenebilir:
- Custom cookie binding
- JWT token doğrulama
- API key yönetimi
- Rate limiting logic
- A/B testing
- Response header manipulation


8. CHALLENGE'LARI OTOMATİZE ETMEYE KARŞI SAVUNMALAR


"100 thread ile cookie toplar WAF'ı patlatırım" fikrinin neden çalışmadığı:

8.1 — Token Binding

Her cookie, oluşturulduğu IP'ye bağlıdır. Ayrıca:
- TLS session ID
- HTTP/2 connection ID
- Request ID (her request unique)

8.2 — Token Expiry & Rotation

Token süresi kısadır ve periyodik olarak yenilenmelidir:
- Klasik: 30 dakika
- Aggressive: 5 dakika
- Ultra: her request'te yeni token (Her request challenge)

8.3 — Rate Limit Her Seviyede

Challenge sayfasına istek atmak da rate limit'e dahildir:
- IP: 10 request / dakika challenge endpoint'ine
- Daha fazlası → block veya challenge süresini uzatma
- Abuse detection: aynı IP'den çok sayıda challenge çözümü →
"Bu IP script kullanıyor" → block

8.4 — Proof-of-Work Maliyeti

Her challenge çözümü CPU-bound bir hesaplama gerektirir:
- Klasik: ~2-5 saniye (tek thread)
- Ağır: ~10-15 saniye (anti-automation modu)
- 100 thread ile 100 cookie: 100 * 5sn = 500 CPU-saniye
- 1 dakikada 10k cookie: imkansız (100 thread * 60sn / 5sn = 1200)
- Bu da ancak 1200 cookie demek

8.5 — Anomali Detection

Aynı IP'den challenge endpoint'ine anormal sayıda istek:
- "Challenge solved" event'lerinin sayısı
- Çözüm sürelerinin dağılımı (hepsi aynı sürede çözülmüş → bot)
- Fingerprint'lerin çeşitliliği (hepsi aynı fingerprint → bot)
- Hata oranı (çözümlerin başarısızlık oranı anormal ise)


9. TURNSTILE'IN ARKASINDAKİ MATEMATİK


Turnstile'in en önemli özelliği "non-interactive" olmasıdır yani
kullanıcının hiçbir şey yapması gerekmez. Peki nasıl çalışır?

9.1 — Proof of Work (PoW)

Cloudflare'in challenge'ı tipik olarak bir PoW içerir:

Verilen: challenge_string (rastgele)
İstenen: nonce öyle ki SHA256(challenge_string + nonce) belirli
sayıda leading zero bit'e sahip olsun

Örnek:
challenge = "a1b2c3d4e5f6..."
nonce = 0
while SHA256(challenge + nonce)[:20] != "00000":
nonce++

Bu hesaplama CPU-bound'dur ve ~2-5 saniye sürer.
GPU ile hızlandırılabilir ama o da sınırlı.

9.2 — Cryptographic Attestation

Cloudflare, Trusted Execution Environment (TEE) kullanarak browser'ın
kodunu doğrulayabilir:

a) Browser'a bir WASM (WebAssembly) modülü gönderilir
b) WASM modülü TEE içinde çalıştırılır
c) TEE, kodun kurcalanmadığını kanıtlar (remote attestation)
d) Attestation sonucu CF'e gönderilir
e) CF doğrular

Bu sayede:
- Kod değiştirilemez (TEE koruması)
- Sonuç güvenilirdir
- Debugging/devtools ile atlatılamaz

9.3 — Privacy Pass

Cloudflare Privacy Pass protokolü:
- Bir kere challenge çöz → birden fazla token al
- Token'ları sakla, her istekte bir token kullan
- Token'lar blind signature ile imzalı (anonim)
- Bu sayede her istekte challenge çözmene gerek kalmaz

Privacy Pass matematiksel olarak:
1. Client rastgele bir t nonce oluşturur
2. t'yi bir körleme faktörü ile maskeler: t' = blind(t, r)
3. Server t'yi imzalar: sig(t')
4. Client imzayı açar: unblind(sig(t'), r) = sig(t)
5. sig(t) + t'yi sonraki istekte kullanır

Bu protokol sayesinde:
- Server seni tanımaz (anonim)
- Ama senin challenge çözdüğünü bilir
- Token'lar bir kere kullanımlıktır


10. SONUÇ — WAF'LAR NEDEN "SADECE COOKIE" DEĞİL

Soruna dönelim:

"Cookie olsa WAF patlar" — HAYIR, PATLAMAZ.

Çünkü WAF'ın cookie'si:
• IP'ye bağlıdır
• Fingerprint'e bağlıdır
• TLS session'a bağlıdır
• HMAC ile imzalıdır (değiştirilemez/taklit edilemez)
• Kısa sürelidir
• Rate limit ile korunur

"Cookie olmadan nasıl istek gönderirim?"
• Cookie'siz istek göndermek mümkündür.
• Ama her seferinde challenge'a düşersin.
• Challenge'ı otomatize etmek için:
1. Gerçek browser kullanmalısın (Puppeteer/Playwright)
2. Browser fingerprint'ini gizlemelisin
3. Mouse/keyboard event'lerini simüle etmelisin
4. PoW hesaplamasını yapmalısın (CPU maliyetli)
5. Turnstile attestation'ını geçmelisin (WASM/TEE)
6. Her şey yolunda gitse bile rate limit'e takılabilirsin

"Device-ID versem?"
• HMAC imzalı device-ID çalışır.
• Ama device-ID'nin kendisi de WAF kararına girdi olur.
• Aynı device-ID + farklı IP = anormal.
• Aynı IP + farklı device-ID = anormal.
• Device-ID süresi dolunca yenisi alınmalı.

★ GERÇEK ÇÖZÜM ★

Modern WAF'ların asıl gücü TEK BİR SİNYALE değil, 500+ sinyalin
birlikte değerlendirilmesine dayanır:

Cookie, Device-ID, IP, JA3, H2 fingerprint, headers,
timing, mouse, scroll, keypress, canvas, webgl, audio,
fonts, DOM, WebDriver flags, ve daha fazlası...

Bunların hepsi bir ML modeline girdi olarak verilir.
Model her request için bir "bot score" üretir.
WAF kuralı bu skora göre karar verir.

Tek bir sinyali manipüle etmek (cookie toplamak, device-ID
değiştirmek) işe yaramaz çünkü ML modeli diğer 499 sinyaldeki
tutarsızlığı hemen görür.

★ ÖZET ★

1. Cookie = sadece hızlandırıcı, zorunlu değil
2. Cookie'siz istek → her seferinde challenge (yavaş ama mümkün)
3. 100 thread cookie toplama → rate limit + IP binding + PoW maliyeti
4. Device-ID + HMAC imzası → taklit edilemez ama yine de tek sinyal
5. Gerçek koruma: ML modeli ile 500+ sinyalin birlikte analizi
6. Tek sinyali bypass etmek anlamsız, bütünü bypass etmen lazım


================================================== ==============================
FABLE-5 HYBRID NEXUS — GOD MODE
Document ID: F5-GM-20260624-1442
Classification: TEKNİK REFERANS — Eğitim Amaçlıdır
================================================== ==============================