Bot, Gmail nokta-alias kayıtlarıyla altı saatte altı API key topladı

Gecede altı kayıt

Bir geliştirici, dev.to üzerinde bir botun belgelenmiş Gmail davranışından yararlanarak altı saat içinde servisinden altı API key çektiğini anlattı: Gmail, adresin yerel kısmındaki noktaları anlamsız sayar; yani [email protected] ve [email protected] aynı inbox'a ulaşır. Bu davranış bilinçlidir; Gmail'in ilk dönemlerinden kalma, adreslerin çoğunlukla elle yazıldığı bir çağın tasarım tercihidir.

Gece boyunca yapılan kayıtlarda [email protected] gibi noktalı varyantlar kullanıldı. Servisin benzersizlik kontrolü adresi eşleştirmeden önce yalnızca küçük harfe çevirdiği için her noktalı dizi yeni bir hesap sayıldı ve her yeni hesaba kendi key'i verildi.

Noktaları kaldırmak ikinci bir sürpriz ortaya çıkardı. Adresler saldırganın kontrolündeki tek bir mailbox'a daralmadı; altı farklı, makul kişisel isme çözüldü. Yazara göre bu mutasyon, listeyi çalıştıran otomatik araca gömülü standart bir kaçınma davranışına benziyordu; bu servise özel bir taktik değildi. Sonuç, doğrulama e-postalarının ürünü hiç duymamış altı yabancının adresine düşmesiydi — ve yazarın da belirttiği gibi, genç bir gönderen domain'ine karşı birkaç spam raporu, tam da gerçek kullanıcılar gelmeye başladığı anda teslim edilebilirliği sessizce mahvedebilir.

Korunan kapı, açık olanın yanındaydı

Zamanlama acı vericiydi. Bir gün önce ekip, package-security sorgulamasını key'siz çağrılara açmıştı; bilinçli şekilde ayarlanmış limitlerle: adres başına saatte yirmi istek, istek başına beş package ve aşım bilgisi dokümantasyona bırakılmak yerine yanıt içinde döndürülüyordu.

Bir API key tüm bunları bypass eder ve edinmenin iki yolu vardı. Key isteme endpoint'i key'i postayla gönderir ve yazıldığı günden beri adres başına günlük beşlik bütçeyi zorunlu kılar; bir kod yorumu, bütçenin key-farming'i sınırlamak için var olduğunu belirtir. Kayıt endpoint'i ise e-posta ve şifre alıyordu ve hiçbir throttle uygulanmıyordu — ayrıca deployment'ta e-posta doğrulaması varsayılan olarak kapalı olduğundan, çalışan bir key'i doğrudan HTTP yanıtında döndürüyordu; inbox'a gerek yoktu.

Çözüm yaklaşık dört satır koddan ibaretti: mevcut throttle fonksiyonunu kayıtta yeniden kullanmak ve bütçe tükenince 429 döndürmek. Yazarın teşhisi şu: tehlikeli görünen endpoint'ler özenle yazılırken, sıkıcı olanlar — kayıt formları gibi — diğer tüm limitleri etkisiz kılan credential'ı dağıtsalar bile incelenmeden kalıyor.

Bariz çözüm, yanlış çözümdür

Gmail aliasing'ine karşı cazip tepki, karşılaştırmadan önce her adresi normalize etmektir — noktaları ve artı işaretinden sonrakileri atmak. Yazı bunu global olarak yapmaya karşı çıkıyor. Noktalar yalnızca Gmail'de anlamsızdır; Outlook'ta [email protected] ve [email protected] iki ayrı mailbox'tır ve potansiyel olarak aynı şirketteki iki farklı kişiye aittir. Noktaları her yerde katlarsanız, sonunda gerçek bir kullanıcıya hesabının zaten var olduğunu söylersiniz ve o kullanıcı bunu bildirmek yerine sessizce gider. Artı etiketleri daha güvenlidir ama yine de evrensel değildir; çünkü artı işareti yerel kısımda yasal bir karakterdir ve yalnızca bazı sağlayıcılar buna göre yönlendirme yapar.

Bu nedenle canonicalisation sağlayıcıya özel olmalıdır: artı etiketlerini yönlendirdiği bilinen bir domain kümesi ve — googlemail.com dahil Gmail'in domain'lerini kapsayan — çok daha küçük, noktaları yok saydığı bilinen bir küme tutun. Uygulamada iki ayrıntı, fonksiyonun kendisinden daha önemlidir. Birincisi, canonical formu unique index altında kendi sütununda saklayın ve orijinal adresi tam yazıldığı gibi koruyun: posta kullanıcının yazdığı adrese teslim edilmelidir; canonical değer yalnızca iki adresin aynı mailbox olup olmadığını yanıtlamalıdır. İkincisi, başarısız bir unique-index migration'ını yararlı bir sinyal olarak görün — bu, iki mevcut hesabın zaten aynı inbox'ı paylaştığı anlamına gelir ve bunun insert anındaki bir kontrol tarafından sessizce emilmesinden çok, gürültülü biçimde keşfedilmesi daha iyidir.

Neden önemli

Yazarın temel dersi şu: throttling yalnızca dikkatın tesadüfen yoğunlaştığı yerlerde tasarlanıyor. Key'siz katmana tam bir gün özen harcanırken, bu sayıları bypass eden key'leri veren komşu yol ölçümsüz kaldı; çünkü o sadece bir kayıt formuydu. Önerdikleri denetim basit: eğer bir ücretsiz katman özenle seçilmiş bir sayı içeriyorsa, o sayıyı yok sayan credential'ı dağıtan her rotayı inceleyin.

Olay ayrıca e-postanın göründüğünden daha zayıf bir kimlik olduğunu hatırlatıyor. Gmail'in nokta davranışı belgelenmiş ve kalıcıdır; nokta-mutasyonu otomatik kayıt istismarında rutin bir araçtır ve doğrulama varsayılanları hem istismara açıkliği hem de genç bir domain'in gönderen itibarını şekillendirir. Yazar, adresleri kullanılan altı kişiye bir özürle kapanmış: hesaplar silinmiş ve postayla hiçbir şey yapılmamış.