Şu tabloyu hayal edin: Web geliştirme âlemi bir sonraki parlak framework’le ayağa kalkmış, yapay zeka kodları şeker gibi saçıyor, herkes CSRF gibi eski usul hataların tarih olduğunu varsayıyor. Tam tersi. Yapımcılar OAuth ya da JWT’leri yapıştırıp kurşun geçirmez app bekliyor —ama yok, Cross-Site Request Forgery sızıp oturum açık sitelerde eylemleri sahteliyor. Bu oyunu değiştiriyor: Güvenlik bir liste değil, imparatorluğunuzu saran görünmez hendek.
İşte kıvılcım — Eliran Turgeman’ın ‘CSRF for Builders’ yazısı, her gün kod dövenler için berrak bir analiz sunuyor, güvenlik doktora tezi değil.
“CSRF, kötü niyetli bir sitenin tarayıcınızı kandırıp kimlik doğruladığınız meşru bir siteye istenmeyen istek gönderdiği saldırı türüdür.”
Pat. Basit değil mi? Ama açın bakın, sekmenizde soygun filmi dönüyor.
Neden CSRF VR Dünyasında 90’lar Yankesicisi Gibi Hissediliyor
Bakın.
Banka uygulamanız. Oturum açık, çerezler mutlu mutlu çalışıyor. Sonra —pat— şüpheli bir reklama tıklarsınız (ya da kötü niyetli forum yazısına). Aniden tarayıcınız bankaya transfer isteği fırlatır, geçerli oturumunuzla. Puf, 10 bin dolar hacker cennetine. Phishing maili gerek yok; her şey çapraz site sihri.
Canlı değil mi? Popup’la nazikçe soran bir yabancıya imzalı çek defterinizi vermek gibi. İşte CSRF bu — tarayıcınızın sadakatine güveni sömürüyor.
Ama durun yapımcılar. Artık her yerde HTTPS var. Same-origin politikası. Neden hâlâ sorun?
Tarayıcılar evrildi evet, saldırganlar da. Web’i kalabalık bir çarşı gibi düşünün; CSRF dürüst satıcıya ödeme yaparken sizi dürtüp sahte banknot sokan hırsız.
Benim Turgeman’da olmayan sıcak yorumum: Bu 1988’deki Morris Worm‘u andırıyor, Unix araçlarındaki buffer overflow’ları sömüren ilk büyük internet salgını. O zaman ağa güveniyorduk; bugün tarayıcıya. Tarih bağırıyor — klasikleri görmezden gel, geleceğini sahteleştirirler.
Turgeman mekanikleri süssüz anlatıyor. Akışı çiziyor: Kurban evil.com’a girer, site gömer. Tarayıcı uslu uslu doğrular. Şifre istemez. Bitti.
Korkunç kolay.
Açık kaynak savaşçıları için? WordPress eklentileri, GitHub app’leri — durum değiştiren işlemler korumasızsa, ördek gibi avlanıyorlar.
Yan Projeniz Şu An CSRF’ye Para Akıtmıyor mu?
Kısa cevap: Muhtemelen evet.
Test edin. Savunmasız bir uç nokta alın —diyelim /change-email POST’u. Oraya otomatik submit formlu sahte sayfa kurun. Oturum açıkken girin. E-posta değişti mi? Açıklarınız var.
Modern stack’ler yardımcı — Rails’te token yerleşik, Django’da da — ama kendi API’nizi yazıyorsanız? Ya SPA’lar legacy backend’lere fetch atıyorsa? Felaket kapıda.
Turgeman vurguluyor: GET’ler güvenli olsun (idempotent, yan etki yok), POST/PUT/DELETE’lere anti-CSRF kalkanı.
Enerji burada — düzeltin, sadece yama değil, yapay zeka web patlamasına geleceğe hazır olun. LLM’ler dinamik formlar mı üretiyor? Tek hata, sunucu çiftliğinde domino gibi sahte istekler.
Yapımcının Sahtecilik Karşı Cephaneliği — Doldurun
Peki nasıl savaşacaksınız? Panik yok; basit, hatta zarif.
İlk: Synchronizer token’lar. Formlara rastgele, oturuma bağlı token yapıştırın. Sunucu eşleşiyor mu diye bakar. Kötü site tahmin edemez — kriptografik imkânsız.
İkinci — SameSite çerezleri. Strict ya da Lax yapın. Tarayıcılar (Chrome 80+, Firefox) çapraz site gönderileri engeller. Çoğu saldırı biter.
Ama —dikkat— custom header’ları uyutmayın. Fetch API’lerle X-CSRF-Token ekleyin; preflight OPTIONS eksikse çöker.
Turgeman kodu gezdiriyor: Girişte token üret, gizli form alanı ya da header’a göm. Her mutate’te doğrula.
“Anahtar, durum değiştiren her isteğin saldırganın tahmin edemeyeceği ya da kendi sitesinden alamayaceği bir değer içermesi.”
Aynen! API’ler için? Double-submit çerez — token hem çerezde hem header/body’de. Uyuşmazsa reddet.
Heyecan burada: Yarının dağıtık web’inde — Web3, edge fonksiyonlar, gezinen yapay zeka ajanları — CSRF değişiyor. Tahminim?
