Google OAuth'ta bazı işlevsel aksaklıklar yaşanıyor

 (trufflesecurity.com)
1 puan yazan GN⁺ 2023-12-22 | 1 yorum | WhatsApp'ta paylaş
  • Google OAuth’un email claim alanına güvenerek oturum açma yetkisini belirleyen servislerde, işten ayrılan kişiler şirketin Google kuruluşundan kaldırıldıktan sonra bile Slack·Zoom gibi uygulamalara erişimini sürdürebilir
  • Gmail dışı e-posta adresleriyle de Google hesabı oluşturulabilir; şirket e-postasındaki takma adlar ve artı adres yönlendirmesi kullanılırsa, kuruluşa ait olmayan bir Google hesabı şirket alan adına ait e-posta claim’i gönderebilir
  • Bu Gmail dışı hesap, şirketin Google kuruluşunun yönetici ekranında veya kullanıcı listesinde görünmez; ancak birçok servis yalnızca e-postanın sonundaki alan adına bakarak oturum açmaya izin verir
  • Kuruluşlar Google ile oturum açmayı kapatıp SAML’ı sıkı biçimde uygulayarak riski azaltabilir; ancak bazı servisler veya dahili uygulamalar bu seçeneği sunmayabilir ya da SAML’ı desteklemeyebilir
  • Google’a 4 Ağustos’ta bildirim yapıldı, 5 Ekim’de $1337 ödül ödendi; 16 Aralık’ta, 134 gün sonra kamuya açıklandı, ancak açıklama anına kadar Google’ın azaltım değişikliği dağıtılmamıştı

Güvenlik açığı açıklaması ve zaman çizelgesi

  • Google OAuth güvenlik açığı nedeniyle, şirketten offboarding’i yapılan ve Google kuruluşundan kaldırılan bir çalışan Slack·Zoom gibi uygulamalara erişimini süresiz olarak koruyabilir
  • Açıklama anına kadar Google, bu riski azaltan bir değişiklik dağıtmamıştı
  • Zaman çizelgesi şöyle
    • 4 Ağustos: Google’a bildirim yapıldı ve yüzlerce uygulamanın etkilenme olasılığı iletildi
    • 7 Ağustos: Sorun triage edildi
    • 5 Ekim: Google sorun için $1337 ödeme yaptı
    • 25 Kasım: Zoom·Slack dahil etkilenen onlarca uygulamaya toplu olarak özel bildirim yapıldı
    • 16 Aralık: Google’a bildirimden 134 gün sonra kamuya açıklandı

email claim’i tanımlayıcı olarak kullanmanın riski

  • Truffle Security’nin Forager girişi daha önce Descope’un Microsoft OAuth güvenlik açığından etkilenmişti
  • O dönemde Microsoft’un doğrudan oluşturmadığı veya doğrulamadığı Email claim’in gönderilebildiği ve email claim’in genel olarak güvenilir bir tanımlayıcı olmadığı doğrulandı
  • Google’ın OIDC belgeleri de Email’i birincil tanımlayıcı olarak kullanmama konusunda uyarıyor
  • email_verified claim’i de sıra dışı bir nokta olarak ele alındı, ancak doğrulanmamış e-postalardan email claim oluşturmanın bir yolu doğrulanamadı
  • Buna karşılık email claim’in kendisini kötüye kullanmaya yönelik yeterince örnek doğrulandı

Gmail dışı Google hesapları ve yinelenen email claim

  • Google hesabı, Gmail adresi olmasa da mevcut bir e-posta adresiyle oluşturulabilir
    • Örneğin Yahoo e-posta adresiyle Google hesabı oluşturulabilir
    • Bu hesap, Gmail dışı e-postayı ayarlamış haldeyken ilgili e-postanın email claim’ini gönderebilir
  • Google belgelerinin e-postayı birincil tanımlayıcı olarak kullanmamayı önermesinin nedenlerinden biri, iki farklı Google hesabının aynı email claim’i gönderebilmesidir
    • Ayarlardan Gmail dışı e-posta değiştirildikten sonra
    • Değişiklik öncesindeki e-postayla yeni bir hesap oluşturulursa aynı email claim mümkün hale gelir

Şirket Google kuruluşunun dışında kalan hesap

  • Temel açık, şirket Google kuruluşu e-postası için e-posta takma adları ve artı adres yönlendirmesi kullanılarak kuruluş dışında Google hesabı oluşturulabilmesidir
  • Şirket e-postasının artı adresi, asıl kullanıcının gelen kutusuna yönlendirilebilir
  • Bu akışla şirket Google kuruluşu e-postasını kullanan artı adres tabanlı Gmail dışı bir Google hesabı oluşturulabilir ve bu hesap kuruluş tarafından silinemez veya offboarding’e tabi tutulamaz
  • Birçok servis bu e-postayı ayrıştırdıktan sonra sondaki alan adına göre oturum açılıp açılamayacağını belirler
    • Bu hesapla Zoom’a kaydolunabilir
    • Bu hesapla Slack’e kaydolunabilir
  • Bu tür Gmail dışı Google hesabı, gerçek bir Google kuruluş üyesi olmadığı için yönetici ayarlarında veya Google kullanıcı listesinde görünmez

Kuruluşların, servis sağlayıcıların ve Google’ın azaltım önlemleri

  • Kuruluşlar Google ile oturum açmayı devre dışı bırakıp SAML’ı sıkı biçimde zorunlu kılarsa riski azaltabilir
    • Çoğu servis sağlayıcıda bu yöntem çalışır
    • Bazı servisler bu seçeneği sunmaz
    • Dahili geliştirilmiş uygulamalar etkilenebilir ancak SAML’ı desteklemiyor olabilir
  • Servis sağlayıcılar Google OAuth’un HD claim’ini kullanabilir
    • HD claim, hesabın bağlı olduğu Google kuruluşunun alan adını gönderir
    • Google kuruluş üyesi olmayan hesaplarda HD claim bulunmaz
    • Test edilen servis sağlayıcıların çoğu HD yerine email claim kullanıyordu
  • HD claim için önemli bir sınırlama devam ediyor
    • HD benzersiz bir tanımlayıcı değil, yalnızca alan adıdır
    • Google kuruluşu silinir ve alan adı boşta bırakılırsa başka biri bu alan adını alıp yeni bir Google kuruluşu oluşturabilir
    • Örnek olarak A şirketinin B şirketi tarafından satın alınması, B’nin A’nın servislerini sonlandırması ve mevcut alan adını yenilememesi verilebilir
    • İnternetteki biri A şirketinin alan adını satın alırsa A şirketinin mevcut servis hesaplarına giriş yapabilir
  • Servis sağlayıcılar JIT hesap oluşturmayı genel bir özellik olarak sunmayıp davetle sınırlı ya da LDAP grubu tabanlı hesap provizyonlamaya geçebilir
  • Google, mevcut Google kuruluşu alan adlarıyla oluşturulan Google hesaplarını yasaklayarak geniş kapsamlı bir azaltım uygulayabilir
    • Google kendi içinde google.com hesaplarını yasaklıyor
    • Aynı korumayı diğer kuruluşlara da genişletebilir
  • Google tarafındaki diğer azaltımlar arasında artı adresle Google hesabı kaydını yasaklama, Google e-posta takma adıyla kaydı yasaklama ve kuruluşların ilgili ayarları yapılandırabileceği daha iyi yönetici ayarları sunma yer alır

Ek etki: destek e-postası ve magic link akışları

  • İlk erişim yetkisi olmasa bile bir kuruluşun Zoom·Slack ortamlarına erişmek teknik olarak mümkün olabilir
  • Bu akış, diğer araştırmacıların magic link sign-in flows içinde bulduğu güvenlik açığı araştırmasından yararlanır
  • Zendesk gibi bazı destek ve ticket sistemleri e-postayla destek ticket’ı oluşturabilir
    • Destek ticket’ı e-posta adresiyle Google hesabı oluşturulabilir
    • Ticket içeriği kontrol edilerek hesap oluşturma işlemini tamamlama olasılığı vardır
    • Ardından ilgili destek e-posta adresiyle OAuth girişi denenebilir
  • Ana alan adında email to support özelliğini açık tutmak güvenli değildir; Zendesk destek e-postasını alternatif e-posta adresi olarak yapılandırmak bir seçenek olabilir

Açıklamanın amacı ve kalan sorunlar

  • Slack·Zoom gibi platformlarda eski çalışanların erişimini koruması sorunu, Google OAuth sistemindeki bir açıktan kaynaklanıyor
  • Google, bu sorunu azaltabilecek geniş kapsamlı düzeltme yeteneğine sahip
  • Açıklamanın amacı, küçük bir belge değişikliğinin ötesinde gerçek değişiklikleri teşvik etmek
  • Google sorunu hızlıca triage etmiş olsa da, kendi 90 günlük iyileştirme uygulamasının aksine sorun 134. günde kamuya açıklandı

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-22
Hacker News yorumları

  • Bu alanda çalışıyorum ve son 3-4 yılda çeşitli oturum açma sağlayıcıları ve SaaS şirketlerinde bu açığın varyasyonlarıyla 20'den fazla kez uğraştım. Blog yazısı doğru, ama bana göre temel sorun artık düzeltilemeyecek kadar ilerledi. İnternet genelindeki yetkilendirilmiş kimlik doğrulama tamamen karmakarışık durumda; Google ve Microsoft mühendisleriyle de bu konuda çok konuştum, bu yüzden bu sorun ailesinden zaten haberdar olduklarından eminim. Ancak mevcut davranışı değiştirmek, mevcut hizmetlerin ve onlarca yıllık kurumsal oturum açma uygulamalarının çok fazlasını bozacaktır
    Bu noktada “düzeltme” basit. Bir site “Sign in with XYZ” kullanıyorsa, sağlayıcının gönderdiği e-posta adresine güvenmemeli. Yalnızca e-posta alan adına bakarak özel yetkiler vermemeli ve veritabanında doğrulanmış olarak işaretlemeden önce her zaman kendi doğrulama e-postasını göndermeli. Büyük OAuth sağlayıcıları da belgelerini bunu açıkça belirtecek şekilde güncelledi; yazının kendisi de buna dikkat çekiyor. Bu yüzden ödül verilmiş olması aslında şaşırtıcı

    • Kuruluşların bu alanın gerçekte ne kadar karmaşık olduğunu doğru dürüst anlamamasının sonucu gibi geliyor. Çeşitli şirketlerde OAuth2 + OIDC'nin benimsenme süreçlerine bakınca, bunun güvenlik öncelikli bir bakışla değil, her zaman “x ile oturum aç” gibi bir özellik olarak satıldığını görüyorum. PKCE gibi akışı daha güvenli hâle getirmeye çalışsanız bile, çerez paylaşımı veya yönlendirme işleme gibi konularda her platformun dağınık davranması bunu köstebek avına çeviriyor. 3-legged OAuth2'nin temeli sağlam ve CAS gibi çok sayıda öncül de var, ama OpenID Foundation, OIDC'yi pazarlama ve satma biçimi nedeniyle ciddi şekilde eleştirilmeli
    • “Yalnızca e-posta alan adına bakarak özel yetkiler verme; veritabanında doğrulanmış olarak işaretlemeden önce her zaman kendi doğrulama e-postanı gönder” yaklaşımı, kullanıcı Google'da artı adresle hesap kaydettikten sonra kovulmadan önce o Google hesabıyla hizmete giriş yaptıysa başarısız olmaz mı? Her girişte doğrulama e-postası göndermiyorsanız yani
    • Bu özel örnekte saldırgan doğrulama e-postasını gerçekten alabiliyor; bu doğrulama sürecinin ne anlamı olduğunu bilmiyorum
    • “Veritabanında doğrulanmış olarak işaretlemeden önce her zaman kendi doğrulama e-postanı gönder” demek, kullanıcı açısından x ile oturum aç özelliğini işe yaramaz hâle getirir
    • Google, Google Apps müşterisinin alan adını kullanarak kayıt yapılmasını engelleyemez miydi? Bu pek bir şeyi bozacak gibi görünmüyor

  • Bununla ilgili olarak, daha fazla hizmet sağlayıcının Google belgelerinde önerildiği gibi e-postayı birincil tanımlayıcı olarak kullanmayı bırakması gerekiyor. Google Apps'te kullanıcı adını değiştirdiğimizde Slack, Datadog, GoLinks vb. yerlerde sorunları çözmek için çok zaman harcadım

    • Sağlayıcılar ne kullanmalı? E-postanın kullanıcı için en istikrarlı küresel tanımlayıcı olduğunu hep düşünürdüm, ama anlaşılan bu varsayım yanlış
    • Katılmak zor. Bu tür yönergeler sorumluluğu uygulama geliştiricilerine yıkmaktan başka bir şey yapmıyor; çoğu da ya hiçbir şey yapmayacak ya da herkes kendince uygulayacak
      Burada doğru yön, kullanılacak uygulamanın ihtiyaçlarına uygun ve ek sorumluluğu en aza indiren bir API sağlamak. Bu durumda bence Google, email_verified değerini false olarak ayarlamalıydı; böylece uygulama veya alt IdP ek doğrulama gerektiğini anlayabilirdi

  • user@domain zaten Google posta sunucusunda işleniyor ve bu yüzden artı yönlendirme kuralları uygulanıyorsa, neden user+suffix@domain gibi bir e-postayla yeni bir Google hesabı oluşturulabildiğini anlamıyorum. Kötüye kullanım olmasa bile kafa karıştırıcı e-posta yapılandırmaları yaratmak için çok uygun görünüyor

    • Alan adları posta sunucularını serbestçe taşıyabilir. Google a+b@domain.com adresini belirli bir şekilde işler, ama başka bir sunucu işlemeyebilir. Sonuçta ikisi birbirinden farklı benzersiz e-posta adresleridir ve internet genelinde de böyle ele alınmalıdır
    • Bu takma ad özelliği, taşıyabileceğinden fazla karmaşık hâle gelmiş gibi. Özellikle Google ölçeğinde daha da öyle
    • user+suffix@domainden daha kötü. En azından +XYZ e-posta RFC'sinde belirtilmiş. Google daha da ileri gidip ad içindeki noktaları da normal e-posta sayacağını belirledi. Örneğin hi.my.name@google.com, himyname@google.com ile aynıdır ve tüm postalar ikincisine yönlendirilir
    • Bunun nedeni Google'ın kimlik doğrulama sisteminin çok eski bir legacy olması. “Google hesabı” sadece bir dize

  • “Microsoft’un, Microsoft’un oluşturmadığı veya doğrulamadığı e-posta claim’leri gönderdiğini ve genel olarak e-posta claim’lerinin güvenilir kabul edilmediğini öğrenince şaşırdım” kısmına gelince; asıl niyet bu olmuş olabilir ama OIDC’nin daha esnek olabilmesinin çok faydalı olduğunu düşünüyorum. Örneğin ücretsiz bir oturum açma sağlayıcısı[0] işletiyorum; bu, kimliği üst OIDC ya da doğrudan e-posta üzerinden dördüncü taraf bir kimlik sağlayıcı (IdP) ile doğrulayıp uygulama ile o IdP arasında gizlilik bariyeri oluşturan bir yöntem. Yani Google’ın kullanıcının giriş yaptığı tüm uygulamaları izlemesini engelliyor
    Kendi e-postanızı Google’a getirebilmeniz, Google OIDC’nin güvenliği ve kullanıcı deneyimini e-posta+parolanın gizliliğiyle birlikte elde edebileceğiniz anlamına geliyor; ancak artık Google yerine LastLogin’e güvenmeniz gerektiği gibi büyük bir şart var. Bu bağımlılığı azaltacak bir protokol üzerinde de çalışılıyor. “Google dokümantasyonu aslında e-postayı tanımlayıcı olarak kullanmayın diye uyarmıştı” kısmına ise tamamen karşıyım. E-posta, insanların gerçekten kullandığı tek gerçek birleşik kimliktir. Daha iyi bir alternatif yaygın biçimde dağıtılana kadar e-posta adreslerinin kimlik olarak ele alınması gerektiğine inanıyorum
    [0]: https://lastlogin.io

    • “E-posta adreslerinin kimlik olarak ele alınması gerekir” görüşüne katılmıyorum. Bunun iki nedeni var
      Batı dünyasının dışında cep telefonları bilgisayarlardan daha yaygın ve arayüzleri de genellikle daha kolay olduğu için telefon numarasının kimlik olma olasılığı daha yüksek. Ayrıca bunu yapmak kimliği e-posta sağlayıcısına tamamen teslim etmek anlamına gelir. Google gibi yüzsüz kuruluşlar, önceden haber vermeden ya da itiraz süreci sunmadan erişimi engelleyebilir ve gerçekten de engelliyor; bu yüzden her şeyi kaybedebilirsiniz. Arka plan olarak, Okta’nın OAuth ve OIDC ürününü piyasaya sürdüm, LinkedIn’in ilgili kursunu hazırladım ve şimdi Pangea Cyber’da bunu yeniden yapıyorum
    • “E-posta adresleri kimlik olarak ele alınmalı” ha; kimsenin e-posta adresi paylaşmadığı ve e-postanın çok güvenli olduğu varsayımı mı bu
      Sonsuza kadar bekleyebiliriz ya da bir çözüm üretmeye başlayabiliriz
    • Kendi sisteminiz içindeki e-posta tanımlayıcısı ile bağlı Google hesabının tanımlayıcısı olarak e-posta arasında önemli bir fark var. Kontrol ettiğiniz sistem içinde e-postanın kimlik olarak az çok işe yaradığına katılıyorum; ancak harici bir sisteme bağlanırken Google’ın dediği gibi berbat bir yöntem. Geçici, birden fazla hesaba bağlı olabilir ve kullanılabilecek gerçek bir ID varken bunu kullanmak için bir neden yok
    • LastLogin ile Dex’i karşılaştırırsanız gerçekten harika olur. İkisi de Go ile yazıldığı için özellikle merak ediyorum. Dex’i değerlendirip değerlendirmediğinizi de merak ediyorum
      Portier ve eski Mozilla Persona ile de biraz uğraştım ama sonunda e-posta normalleştirme sorunuyla uğraşmak kaybedilmiş ya da fazla zor bir savaş gibi göründü. İyi bir çözüm öncülük edilmeden önce ölecek gibi olduğunu neredeyse kabullenip ilgimi başka yere çevirdim

  • Bu gerçekten bir Google OAuth sorunu mu, yoksa birçok servis sağlayıcının erişime izin vermeden önce OAuth token’ındaki iddiaları düzgün doğrulayamamasının bir başarısızlığı mı? İkincisi gibi görünüyor

    • Sorun, bu servis sağlayıcıların Google’ın alias kurallarına uyarken e-postanın birincil tanımlayıcı olarak kullanılmaması gerektiği gerçeğini görmezden gelmesi gibi duruyor [1]. İlginç olan şu: Spesifikasyonu daha iyi takip etselerdi sorun olmayacaktı; tersine spesifikasyonu daha az takip edip alias’ları farklı e-postalar olarak ele alsalardı bile en azından daha güvenli olurdu
      [1] https://developers.google.com/identity/openid-connect/openid...
    • OAuth’un beklendiği gibi çalıştığını düşünüyorum. user@domain ve user+wildcard@domain hâlâ kullanıcının “sahip olduğu” e-posta adresleri olarak doğrulanıyor; dolayısıyla bu e-posta adresi için geçerli kimlik doğrulama ve kimlik sağlıyor
      Sorun Google kuruluş web sitesi tarafında. Yönetici, göremediği hesapların ya da e-postaların kimlik bilgilerini iptal edemez. “Bu Gmail dışı Google hesapları aslında Google kuruluşunun üyesi olmadıkları için yönetici ayarlarında ya da Google kullanıcı listesinde görünmüyor” kısmı kilit nokta

  • Bu akışı izleyerek bir destek talebi e-posta adresiyle Google hesabı oluşturabilir, hesap oluşturmayı tamamlamak için talep içeriğini potansiyel olarak kontrol edebilir ve ardından o destek e-posta adresiyle çeşitli servislere OAuth ile giriş yapabilirsiniz. Bu, birçok küçük şirketi etkileyebilir

  • Buradan çıkardığım en büyük sonuç, web kimlik doğrulamasının hâlâ korkunç bir keşmekeş olduğu

    • Çünkü insanlar dokümanları okumuyor ve sadece kendi düşündükleri şekilde çalıştığını varsayıyor
    • Aklı başında ve pratik insanların neden hâlâ basit parola kimlik doğrulaması kullandığını ve talep ettiğini sorarsanız: çünkü parolalar düzgün çalışıyor

  • OIDC spesifikasyonu e-postanın benzersiz tanımlayıcı olarak kullanılmaması gerektiğini söyler. Uygulamanın kullanıcı adı olarak iss ve sub alanları kullanılmalı
    Bunun nedeni, öncelikle kullanıcı e-posta adreslerinin yeniden kullanılabilmesinin açık olması. Bir yüklenici hem Business A hem de Business B için çalışıyorsa ve ikisi de kimlik doğrulama servisinde o kişi için kullanıcı hesabı oluşturduysa, SaaS platformu açısından tek bir e-posta adresini tek bir B2B müşteriye eşlemek mümkün değildir. İkincisi, e-posta adresleri değişir. Şirketler satın alınır, isim değiştirir, birleşir; insanların adları da evlilik, boşanma veya kişisel tercihle değişir. Bir startup’ta SSO uygulamak başlangıçta gerçekten zordu. Doğru yapmak zor ve kullanmadan önce genel kavramları, OIDC’yi ve OAuth2’yi iyi anlamak gerekiyor. Auth0’nun iyi bir kitabı var. Bunu anlamazsanız sağda solda password grant kimlik doğrulaması uygulayıp uygulamanızı güvensiz hâle getirmeniz çok olası

    • Böyle yazıları okuyunca biriken imposter sendromu bazen biraz azalıyor. “Soyut bir aktörü temsil eden bir şey için üçüncü taraf sistemle entegre oluyorsam, kararlı, string’imsi olmayan, güvenilir bir tanımlayıcı olmalı” diye düşünüyorsunuz. Aslında spesifikasyon da bu konuda çok net ve biraz olsun sağlam bir sistem kurarken gereken temel değerlendirmelerin ötesinde bir şey değil

  • Küçük bir minyatür gibi. OAuth2 diye bir şey aslında yok. OAuth2, dev şirketlerin kendi keyfî ve tescilli kimlik doğrulama sistemlerini uygulamasının yalnızca bir yolu. Bir kimlik doğrulama sistemi değil, kimlik doğrulama sistemi oluşturmak için bir araç kutusu. Bu yüzden OAuth2’nin bir standart olması bekleniyordu ama gerçekte, her dev şirketin birbiriyle uyumsuz uygulamalara sahip olduğu bir dünyaya dönüştü. Elbette insanlar dev şirketlerin kullanım senaryolarına göre geliştirme yapacak, ama o zaman “standart” nihayetinde Google’ın yaptığı yönteme benzer bir şeye dönüşüyor
    Ve herkesin böyle küçük hataları var. OAuth1’e dönmeliyiz. O gerçek bir standarttı; standart oluşturmak için bir araç kutusu değildi

    • Bu, bir bug’dan çok belirli bileşenlerin birleşmesiyle ortaya çıkan talihsiz bir yan etkiye yakın. Sahipliği değişebilen alan adları, kendi e-postanı getirme, yedek e-posta ve e-postanın kaynağı, plus alias’lara cömertçe izin verilmesi ve dokümantasyon okumayan servis uygulayıcılarının birleşiminin sonucu. Uygulayıcılar muhtemelen çözümü bir videodan ya da sadelik uğruna bazı şeyleri atlanmış bir örnekten kopyalamıştır
      Birkaç PCB bileşeniyle bir devre tasarlayıp gerilim/akım gereksinimlerine göre direnç ve transistör koymanız gerekiyorsa, veri sayfasını okumanız beklenmez mi? Basit bir örnekten kabaca tahmin edip ilerlerseniz çoğu durumda devre çalışabilir; biraz tezgâh testi ve prob ile çalışır hâle de gelebilir. Ama verimi düşebilir ya da bileşenler kısa devre yaparak ortalama arıza süresini azaltabilir ve müşterileri mutsuz edebilir. En kötü durumda pil alev alıp gerçek zarara yol açabilir. O zaman cihazın erken arızalanması PCB modülü üreticisinin hatası mı, yoksa veri sayfasını okuması gereken cihaz üreticisinin sorumluluğu mu? Tüm yazılımlardan bu kadar katı bir beklentim yok, ama kimlik doğrulama ve yetkilendirmeyle uğraşıyorsa servis sahibinin titiz olması gerektiğini düşünüyorum. Orijinal metin de dokümantasyon izlenirse sorunun var olmadığını söylüyor. Alphabet bir bug bounty ödemesi yaparak zayıflığı kabul etti; dolayısıyla şirket yöneticilerine plus alias’ları ya da var olmayan rolleri izin/engelleme listeleriyle yönetme kontrolü sunabilir veya Apps ile ilişkili e-postaların kuruluş dışı claim’lere taşınmasını kısıtlayabilir. Muhtemelen etkinin kapsamını ölçüyorlar ya da ölçüm önceliğini belirliyorlar, ancak bu, e-posta claim’inin gerçekte olduğundan daha yetkili ve kalıcı olduğunu varsayan bir istemci sorunu olduğu için önceliğin düşük olacağını düşünüyorum. “Bug” tanımı büyük ölçüde “beklenen davranış”ın nasıl tanımlandığına ve kimin beklediğine bağlı, ama en azından bunun amaçlanan davranıştan sapma olmadığını ve dokümantasyonu doğru anlayanlar için beklenmedik olmadığını düşünüyorum
    • Hmm... Öyle kabul edelim. Sağlayıcılar arası uyumluluğun Google OAuth2 güvenliği hakkındaki bu yazıyla ilgisi var mı?

  • Bir şeyi mi kaçırıyorum? Yazıda bahsedilen destek sistemi/Zendesk ve terk edilmiş eski alan adı yöntemi dışında, whatever@mydomain.com ile yeni bir Google hesabı oluştururken doğrulama isteniyor. O hâlde gerçek istismar edilebilirlik ne kadar?

    • Asıl nokta, meşru erişim hakkın varken bunu önceden yapmak ve daha sonra o erişim hakkını kaybetmek
      Örneğin meşru olarak egamirorrim@mydomain.com Google hesabın olduğunu varsayalım. egamirorrim+woopsie@mydomain.com gibi bir alias ile doğrulanmış e-posta adresine sahip yeni bir Google hesabı oluşturabilirsin; bunun sonucunda “Google ile oturum aç” sırasında Google egamirorrim+woopsie@mydomain.com e-posta claim’ini gönderir. Daha sonra mydomain.comdan işten çıkarılırsan, gerçek egamirorrim@mydomain.come bağlı hesap yönetici tarafından devre dışı bırakıldığı için artık giriş yapamazsın. Ama yeni Google hesabı olan egamirorrim+woopsie@mydomain.com kuruluşla bağlantılı olmadığı için giriş yapmaya devam edebilir. Ancak bana göre bu, yalnızca sağlayıcı yetkilendirmeyi sadece e-posta claim’iyle yaptığında sorun olur. Geçmişte OIDC kullanmıştım; kaynak erişim hakkı vermek için e-posta adresi claim’inin metnini parse etmemek gerekir. Yazarın bunu neden sezgilere aykırı bulduğunu anlıyorum, ancak yazıda da dokümantasyonun bunu yapmamak konusunda uyardığı belirtiliyor. Orijinal metinde “Test ettiğim servis sağlayıcıların çoğu HD kullanmadı, e-posta claim’ini kullandı” deniyor; tamam, ama bunu ne için “kullanıyorlar”? Bu numara gerçek dünyadaki servislerde gerçekten çalışıyor mu? Öyleyse isimleri açıklanmalı ki eleştirilsinler. Bu değerin benzersiz ve değişmez olduğu yanlış varsayılsa bile, sırf bu tek başına mutlaka bir erişim hakkı doğurmaz