QR Login Zafiyet Teknikleri

Bu yazıda QR Login mekanizmasının temel yapısını ve bu mekanizmada ortaya çıkabilecek zafiyetleri ve istismar tekniklerini ayrıntılı olarak ele alıyoruz.

QR Login, masaüstü veya web uygulamalarında kullanıcıların telefonları üzerinden QR kod tarayarak authentication gerçekleştirmesine olanak sağlayan bir yöntemdir. Bu süreçte QR kodun kendisinin yanında QR oturumunu temsil eden bir QrId, browser session'ı ve mobil uygulama tarafından kullanılan authentication bilgileri/state'i bulunabilir. Bu değerler arasındaki ilişkinin yanlış kurulması authentication bypass ve account takeover'a kadar giden zafiyetlere yol açabilir.

1. QR Login Nedir?

Browser               Server               Mobile App
   |                     |                     |
   |--- Generate QR ---->|                     |
   |<------ QrId --------|                     |
   |                     |<---- Scan(QrId) ----|
   |---- Poll(QrId) ---->|                     |
   |                     |<---- Authorize -----|
   |<------ Login -------|                     |

WhatsApp Web veya Telegram Desktop gibi uygulamalarda gördüğümüz QR tabanlı login akışı da bu genel modele dayanır.

2. QR Login Authentication Flow

QR Login Authentication Flow — tarayıcı, sunucu ve mobil uygulama arasındaki akış

Not: Görseldeki "Durum sorgula (poll)" adımı tek seferlik gibi görünse de, gerçekte tarayıcı QR oluşturulduğu andan itibaren sunucuyu sürekli/periyodik olarak yoklar; bu döngü kullanıcı telefonundan onaylayana kadar devam eder. 4.1 ve 4.4'teki saldırılar tam olarak bu sürekliliğe dayanır.

Basitleştirilmiş bir QR Login akışı şu şekilde düşünülebilir — gerçek implementasyonlar değişkenlik gösterir; bazı sistemlerde QR oturumu bir QrId ile açıkça taşınmak yerine cookie, server-side session veya persistent connection üzerinden takip edilebilir. Aşağıdaki endpoint'ler gerçek bir servise ait değildir; farklı QR Login implementasyonlarında görülebilecek basitleştirilmiş bir örnektir:

POST /qr/generate
Cookie: session=abc123
→ {"qrId": "eb909c5a22b13a5928b288f6626ac9ab"}

POST /qr/scan {"qrId": "eb909..."}

POST /qr/confirm

GET /qr/poll?qrId=eb909...
→ {"status": "LOGGED-IN", "pcToken": "..."}

Kısaca: Bu örnek akışta scan ile mobil cihaz QR oturumunu bulur, confirm ile kullanıcı bu oturumu onaylar, poll ile browser authorization state'ini kontrol eder.

3. QR Login'de Güvenlik Kritik Noktalar

QR Login implementasyonlarında kullanılan değerler uygulamaya göre değişebilse de, tipik olarak QR Login oturumunu veya authorization state'ini temsil eden bir identifier (QrId), tarayıcı session'ı ve mobil/browser tarafındaki authentication token'ları güvenlik açısından kritik hale gelir. Bu yazıdaki örneklerde bu değerler QrId, sessionId, app_token ve pc_token olarak adlandırılmaktadır; gerçek sistemlerde kullanılan isimler ve mekanizmalar farklı olabilir.

QR Login'deki kritik zafiyetlerin önemli bir bölümü, bu değerler arasındaki session ilişkisinin yanlış kurulmasından kaynaklanır.

4. QR Login Saldırı Teknikleri

QR Login Saldırı Teknikleri — 8 temel zafiyet ve istismar senaryosu

Not: Aşağıdaki HTTP istekleri ve endpoint'ler farklı QR Login implementasyonlarında görülebilecek generic örneklerdir; gerçek lab ortamındaki endpoint path'lerini birebir temsil etmez.

4.1 QR Session Hijacking

QR Session Hijacking akışı

QR Login session'ı browser session'a doğru şekilde bağlanmamışsa, saldırgan aynı QrId üzerinden authorization state'i okuyabilir.

if (DB[qrId].status === "LOGGED-IN")
  return { status: "LOGGED-IN", pcToken: DB[qrId].pcToken };   // sessionId kontrol edilmiyor

Victim  → QrId = X
Victim  → Authorize(X)
Server  → X = LOGGED-IN
Attacker → poll(X)
Server  → LOGGED-IN

PoC:

$ curl "/qr/poll?qrId=VICTIM_QRID" -H "Cookie: session=ATTACKER"

Gerçek lab çıktısı:

08:07:00.641  POST /qr/confirm   -> LOGGED-IN
08:07:00.652  GET /qr/poll as=ATTACKER        -> LOGGED-IN
08:07:00.654  GET /qr/poll as=victim-browser  -> LOGGED-IN

Temel problem, server'ın QrId ile browser session arasındaki ilişkiyi doğrulamamasıdır. Bu nedenle saldırgan kendi session'ı üzerinden kurbanın QR oturumunun authorization state'ini okuyabilir.

Sonuç: Saldırgan, kurbanın authorization state'ine kendi session'ı üzerinden erişebiliyor. Elde edilen authorization state kurban hesabının yetkileriyle oluşturuluyorsa saldırı Account Takeover'a kadar ilerleyebilir. Bu PoC'nin kanıtladığı şey, başka bir session'ın kurbanın QR authorization state'ini okuyabildiğidir. Eğer bu state içerisinde kullanılabilir bir pcToken veya eşdeğer web authentication token'ı döndürülüyorsa, saldırı Account Takeover'a kadar ilerleyebilir.

4.2 Controllable QrId

// POST /qr/generate  { "qrId": "VICTIM_QRID" }
const qrId = req.body.qrId || randomId();   // client kendi değerini verebiliyor

Sadece client'ın QrId belirleyebilmesi otomatik olarak hijacking anlamına gelmez — saldırının tamamlanması için saldırganın seçtiği QrId'nin kurban tarafından authorize edilmesi gerekir. Bunun gerçekleşebilmesi için saldırganın oluşturduğu QR oturumunun kurbanın QR Login akışına dahil edilmesi gerekir:

Attacker chooses QrId
        ↓
Server accepts it
        ↓
Victim aynı QrId'yi authorize eder
        ↓
Attacker polls → Victim account

$ curl -X POST /qr/generate -d '{"qrId":"VICTIM_QRID"}'

Temsili çıktı:

[qrId=VICTIM_QRID] (client_supplied=true)    ← saldırgan aynı değeri verdi, KABUL EDİLDİ

Sonuç: QrId'nin istemci tarafından belirlenebilmesi, session binding veya authorization state kontrolleri de yetersizse, QR oturumunun başka bir session tarafından kullanılabilmesine ve kurban tarafından oluşturulan authorization state'in saldırgan tarafından erişilebilir hale gelmesine yol açabilir.

4.3 Predictable QrId

Düşük entropili/tahmin edilebilir QrId tek başına hesap ele geçirme anlamına gelmez. Ancak QrId'nin tahmin edilebilir olması, polling endpoint'inin saldırgan tarafından sorgulanabilmesi ve QrId'nin session ile doğru şekilde bağlanmaması durumunda QrId brute-force saldırısı mümkün hale gelebilir.

$ for i in $(seq -w 0 9999); do
    curl -s "/qr/poll?qrId=$i" | grep -q LOGGED-IN && echo "FOUND: $i"
  done

// Lab örneği
Lab ortamındaki kurbanın QrId değeri: 6968
>>> Geçerli QrId bulundu: 6968

Sonuç: QR kodun kendisini görmeden geçerli bir QrId'nin brute-force yoluyla bulunması mümkün hale gelebilir.

4.4 Reusable QR / Double Login

QR authorization state'i login sonrasında temizlenmiyor ve QrId browser session'a bağlı değilse, aynı QrId başka bir session tarafından tekrar kullanılarak ikinci bir login gerçekleştirilebilir.

Victim:  Generate → Scan → Authorize → Login (kendi tarayıcısında başarıyla tamamlanır)
Attacker: (daha sonra) GET /qr/poll?qrId=VICTIM_QRID → LOGIN

Temsili çıktı:

Victim normal şekilde login oldu.
... 2 saniye sonra, hiçbir şey fark etmeden ...
>>> Saldırgan aynı QrId'yi poll ediyor -> LOGGED-IN

Sonuç: Saldırganın kurbanın login işlemiyle eş zamanlı hareket etmesi gerekmediğinden, QR authorization state'in tüketilmediği implementasyonlarda saldırı daha sonra da gerçekleştirilebilir — kurbanın normal login süreci bozulmadığı için fark edilmeyebilir.

4.5 QR Login Identity Verification Bypass

const user = USERS[account_identifier];   // app_token ile account_identifier arasındaki eşleşme doğrulanmıyor

Lab senaryosunda saldırgan kendi app_token değerini kurbanın telefon numarasıyla eşleştirerek gönderiyor:

$ curl -X POST /qr/confirm -d '{"app_token":"ATTACKER_TOKEN","phone_number":"+905559998877"}'

Temsili çıktı:

>>> {"status":"LOGGED-IN","user":"[email protected]"}

Attacker Token + Victim Phone Number = Victim Account

Sonuç: Server, app_token ile hesap identifier'ı (telefon numarası, e-posta, kullanıcı ID'si vb.) arasındaki ilişkiyi doğrulamadığı için saldırgan kendi geçerli token'ını kurbanın identifier'ıyla eşleştirebiliyor. Böylece QR'a dokunmadan, session çalmadan veya parola bilmeden kurban hesabına ait bir authentication state elde edilebiliyor. Bu state'in üretim ortamında tam yetkili bir web session'ına dönüşüp dönüşmediği ayrıca doğrulanmalıdır.

4.6 QR Login Credential Leakage

$ curl "/qr/poll?qrId=..."

// Lab örneği
>>> {"status":"LOGGED-IN", "pcToken":"...", "legacy_password":"REDACTED"}

QR Login akışında parolanın istemciye geri gönderilmesi normal bir authentication gereksinimi değildir; uygulamanın authentication tasarımındaki hatalı bir veri akışından kaynaklanır.

Sonuç: Ön koşul, saldırganın kurban hesabının QR Login session'ına veya authentication response'una yetkisiz erişim sağlamasıdır. Bu erişimle birlikte authentication response'unda hassas bilgilerin bulunması credential disclosure'a yol açar; sızdırılan parolanın başka servislerde yeniden kullanılması durumunda credential stuffing riskine dönüşebilir.

4.7 QR Expiration Bypass

QR Login uygulamalarında QR kodların belirli bir süre sonra geçersiz hale gelmesi beklenir. Ancak yalnızca frontend'de çalışan countdown mekanizması güvenlik kontrolü değildir. Sunucu, QR'ın süresinin dolup dolmadığını server-side olarak doğrulamadığı durumda süresi dolmuş bir QR tekrar authorize edilebilir.

$ curl -X POST /qr/generate   # expires=300
$ sleep 301
$ curl -X POST /qr/confirm -d '{"qrId":"..."}'

Sunucu expiration'ı server-side olarak kontrol etmiyorsa, bu istek dizisi süresi dolmuş bir QrId'yi yine de authorize edebilir.

Sonuç: Client-side expiration, server-side expiration'ın yerini tutmaz.

4.8 QRLJacking

QRLJacking klasik bir phishing/social engineering saldırısıdır. Saldırının gerçekleşmesi için QR Login uygulamasında doğrudan bir authentication bypass zafiyeti bulunması gerekmez.

Attacker → kendi QR session'ını oluşturur
        ↓
Phishing page
        ↓
Victim scans
        ↓
Attacker session authenticated
        ↓
Account takeover

QRLJacking, QR Login kullanan servislerde uzun süredir bilinen bir phishing saldırı tekniğidir. Bu saldırının otomasyonu için EvilQR gibi araçlar da kullanılabilir.

5. Gerçek Dünya Örnekleri

5.1 Taobao — Authorization Hijacking

Taobao.com, QrId ile browser session arasındaki binding'in yeterli olmaması nedeniyle Authorization Hijacking saldırısına açıktı (bkz. 4.1). Bulgu NVDB-CAPPVD-2024143978 ile raporlandı. [1]

5.2 Chinese National Digital Library — Credential Leakage

Sistem QR Login'i parola girişinin ön adımı olarak kullanıyor ve login tamamlandığında kullanıcının gerçek parolasını response içerisinde plaintext olarak geri gönderiyordu (bkz. 4.6). Parolanın başka servislerde yeniden kullanılması durumunda bu durum credential stuffing riskine dönüşebilir. Bulgu NVDB-CAPPVD-2024678490 ile raporlandı. [1]

6. Sonuç

QR Login, kullanıcı açısından yalnızca kamerayla okutulan bir QR koddan ibaret değildir. Arka planda QrId, browser session, mobile authentication ve login state arasında karmaşık bir güven ilişkisi bulunur. Bu ilişkilerden birinin yanlış kurulması session hijacking, double login, authentication bypass, credential leakage veya account takeover gibi sonuçlara yol açabilir.

Bu nedenle QR Login'in güvenliği QR kodun kendisinden çok, bu değerlerin nasıl üretildiğine, nasıl eşleştirildiğine, ne kadar süre geçerli olduğuna ve authentication state'in nasıl tüketildiğine bağlıdır.

Kaynaklar

[1] Zhang, X. vd. — Demystifying the (In)Security of QR Code-based Login in Real-world Deployments, USENIX Security 2025
[2] OWASP QRLJacking
[3] EvilQR (kgretzky)
[4] Lab kodu: kendi çalışmamız (Docker, Node.js)