URL içinde erişim belirteci taşımak neden risklidir?

URL içinde erişim belirteci taşımak neden risklidir?​

URL içindeki erişim belirteci, bağlantıyı gören veya kaydeden herhangi bir kişinin oturum açmadan kaynağa erişebilmesine yol açabilir. Örneğin https://example.com/download?access_token=abc123 adresindeki belirteç; tarayıcı geçmişine, sunucu ve proxy günlüklerine, analiz araçlarına, yer imlerine veya ekran görüntülerine sızabilir. HTTPS aktarım sırasında içeriği korusa da belirtecin uygulama ve aracı sistemlerde URL olarak işlenmesini engellemez.

Risk nasıl oluşur?​

Eski tasarımlarda erişim belirteci URL'nin sorgusunda veya parçasında taşınabilir. Güncel OAuth güvenlik uygulaması erişim belirtecinin URI sorgu parametresinde geçirilmesini yasaklar. Parça (# sonrası) HTTP isteğine ve Referer başlığına dahil edilmez; onu ancak istemci kodu okuyup ayrıca aktarabilir. Sorun, URL'nin yalnızca hedef sunucuya gönderilen geçici bir veri olmamasıdır; tarayıcı ve altyapı bileşenleri URL'yi farklı amaçlarla saklayabilir veya başka bir isteğin bağlamına dahil edebilir.

Başlıca sızıntı noktaları şunlardır:

• Tarayıcı geçmişi ve yer imleri: Aynı cihazı kullanan başka bir kişi belirteci görebilir.
• Sunucu, CDN, proxy ve WAF günlükleri: Sorgu parametreleri istek kaydıyla birlikte tutulabilir.
• Referer bilgisi: Kullanıcı bağlantıdaki bir sayfadan başka bir kaynağa geçerse, uygun koşullarda önceki sayfanın adresi karşı tarafa taşınabilir.
• Analiz ve hata izleme araçları: Sayfa adresleri üçüncü taraf ölçüm veya hata kayıtlarına gönderilebilir.
• Paylaşım ve kopyalama: Kullanıcı bağlantıyı e-postaya, sohbet mesajına, ekran görüntüsüne veya destek kaydına ekleyebilir.

Belirteç uzun süre geçerliyse, geniş yetki veriyorsa veya iptal edilemiyorsa tek bir URL sızıntısı hesap ya da veri ihlaline dönüşebilir. Belirteç yalnızca okuma yetkisi verse bile özel dosyaların veya kişisel verilerin açığa çıkması mümkündür.

Somut örnek ve doğru tasarım​

Bir uygulama özel raporu şu bağlantıyla indiriyorsa:


bu adresi gören kişi belirteci kopyalayıp raporu indirebilir. Uygulama bunun yerine belirteci URL'den değil, HTTPS isteğinin yetkilendirme başlığından veya güvenli oturum çerezinden almalıdır:


Örnekteki abc123 temsili değerdir. Gerçek tokenı komut geçmişine veya işlem argümanlarına yazmayın; uygulamanın gizli değer mekanizmasını kullanın. Başlık yöntemi URL sızıntısını azaltır; ancak günlüklerde Authorization başlığının kaydedilmediği ayrıca doğrulanmalıdır. Tarayıcı tabanlı oturumlarda çerez; yalnızca HTTPS üzerinden gönderilecek, istemci tarafı betiklerin okuyamayacağı ve uygun site kapsamına sahip olacak şekilde yapılandırılmalıdır.

Aşağıdaki karar tablosu hangi yöntemin ne zaman kullanılacağını özetler:

Mevcut sistemi düzeltme adımları​

1. Sızıntı kapsamını belirleyin. Uygulama kodunda belirteç kabul eden URL parametrelerini bulun; web sunucusu, proxy, CDN, WAF, analiz ve hata izleme günlüklerinde bu alanların kaydedilip kaydedilmediğini kontrol edin. Günlüklerde gerçek belirteç görüyorsanız o değerleri artık güvenilir kabul etmeyin.
2. Eski belirteçleri iptal edin. Sızıntı ihtimali olan tüm aktif belirteçleri veya oturumları sonlandırın ve yeni değer üretin. Beklenen başarı sonucu eski bağlantının yetkisiz erişim hatası vermesi, yeni kimlik doğrulama yönteminin ise yalnız yetkili isteği kabul etmesidir.
3. Kimlik doğrulamayı URL'den çıkarın. API için başlık, tarayıcı oturumu için güvenli çerez veya dar kapsamlı tek kullanımlık işlem belirteci kullanın. URL'deki parametreyi kaldırmadan yalnızca gizlemek çözüm değildir.
4. Günlükleri maskeleyin ve paylaşımı sınırlayın. Query string, yetkilendirme başlığı ve çerez değerlerinin günlük, izleme ve destek kayıtlarında maskelendiğini test edin. Eski kayıtların saklama politikasına göre temizlenmesi veya erişiminin kısıtlanması gerekir.
5. Sızıntı sonrası geçişi test edin. Eski URL'yi gizli bir tarayıcı oturumunda açın; erişim gerçekleşiyorsa iptal veya yetki kontrolü tamamlanmamıştır. Yeni isteği kullanan istemcide beklenen yanıtı alın ve başarısız isteklerin nedenini uygulama günlüğünde belirteç değerini yazmadan inceleyin.

Sık yapılan hatalar​

HTTPS var, sorun yok sanmak: HTTPS ağ üzerindeki aktarımı korur; tarayıcı geçmişi, sunucu günlüğü veya üçüncü taraf izleme kaydı gibi uç noktaları temizlemez.

Belirteci yalnızca kodla gizlemek: Base64, URL kodlama veya benzeri dönüşümler şifreleme değildir. Adreste bulunan değer geri çevrilip kullanılabilir.

Yalnızca Referrer-Policy'ye güvenmek: Referer politikasını kısıtlamak yararlı bir azaltmadır; fakat geçmiş, günlük, kopyalama ve ekran görüntüsü risklerini ortadan kaldırmaz.

Parça bölümünü tam çözüm sanmak: #token bölümü normalde sunucu isteğine gönderilmese de sayfadaki JavaScript tarafından okunabilir, analiz sistemlerine aktarılabilir veya ekran görüntüsüyle paylaşılabilir. Gizli yetki verisini URL tasarımından çıkarmak daha güvenlidir.

Sık sorulan sorular​

Sızmış bir belirteç için yalnızca süresini kısaltmak yeterli midir?​

Hayır. Süreyi kısaltmak etki penceresini daraltır, ancak sızıntı anında hâlâ geçerli olan değer kullanılabilir. Şüpheli belirteç iptal edilmeli, ardından yeni değer üretilmelidir.

URL'de kullanıcı kimliği veya dosya numarası bulunması da aynı risk midir?​

Kimlik veya dosya numarası tek başına yetki vermiyorsa erişim belirteciyle aynı risk değildir; yine de özel bilgi ifşasına ve yetki kontrolü hatalarına yol açabilir. Sunucu her istekte kullanıcının gerçekten erişim yetkisini doğrulamalıdır.

Kısa süreli indirme bağlantısı hiç kullanılmamalı mı?​

Kullanılabilir; fakat kapsamı tek dosya veya tek işlemle sınırlı, süresi kısa ve gerektiğinde iptal edilebilir olmalıdır. Bağlantının paylaşılabileceği varsayılmalı, hassas veriler için ek kullanıcı doğrulaması değerlendirilmelidir.