Kısa bir OAuth güvenlik özeti

Giriş#

Birkaç gün önce, ilginç bir OAuth güvenlik açığı makalesi bizi vurdu. SALT laboratuvarı tarafından A-new-oauth-vulnerability-that-may-impact-hundreds-of-online-services. Bu belirli yazı, Expo, OAuth ve diğer işlevlerin uygulanması için yaygın olarak kullanılan bir çerçeve olan güvenlik açığını öne çıkarır. Özellikle expo-auth-session kütüphanesindeki bir güvenlik açığına odaklanır, bu zaten atandı ve düzgünce çözüldü.

Eğer OAuth ile ilgileniyorsanız veya bizim gibi bir CIAM ile ilgili ürün üzerinde çalışıyorsanız, bu makaleyi okumanızı şiddetle tavsiye ederiz. Oldukça ilham verici ve yardımcı içgörüler sağlar. Bu beyaz şapka raporları, en basit özelliğin bile güvenlik açıkları oluşturabileceğini hatırlatır. Siber güvenlik ve yetkilendirme söz konusu olduğunda, kullanıcı bilgilerinin güvenliğini ve gizliliğini sağlamak konusunda asla çok dikkatli olamayız. Bu makale ilginizi çekerse, bizimle büyük ölçüde hemfikir olacağınıza inanıyorum.

Bize ilk başladığımız zamanı hatırlatıyor. OAuth ve OIDC protokollerinin ayrıntılarını öğrenmek ve araştırmak için çok zaman harcadık. Acı verici ve sıkıcıydı, ancak faydaları çok büyüktü. Ekibimizdeki herkesin bir OAuth uzmanı olması belki de gerekmez, ama herkes güvenlik ve dikkatlilik konusunda sürekli çaba göstermeye kararlıdır. Bu adamakıllı çabalarla, Logto ürünü bugünkü haliyle gelişti.

Bu harika fırsata teşekkürler, OAuth'un güvenlik detaylarını burada yeniden hatırlayalım.

OAuth Yetkilendirme Kodu Akışının bir göz atın#

OAuth 2.0 farklı müşteri türler ve gereksinimlere hitap eden çeşitli yetkilendirme akışları sunar. Bunlar arasında Implicit Flow, Client Credentials Flow, Resource Owner Password Credentials Flow ve Device Authorization Flow bulunur. Ancak Yetkilendirme Kodu Akışı, en güvenli ve yaygın olarak kullanılan olarak öne çıkar. Diğer akışların aksine, kullanıcı kimlik doğrulamasını istemci uygulamadan ayırır ve bir Yetkilendirme Kodu'nun belirteçlerle değiştirilmesini içerir. Bu yaklaşım, hassas belirteçlerin istemciye hiçbir zaman maruz kalmamasını sağlar. Ek olarak, Yetkilendirme Kodu Akışı, sunucu tarafı belirteç yönetimini destekler, bu da sağlam güvenlik ve kullanıcı erişimi üzerinde gelişmiş kontrol gerektiren web uygulamaları için uygundur.

İşte en basit bir Yetkilendirme Kodu Akışı diyagramı:

Yetkilendirme Kodu hibe akışında yapılan iki en önemli isteğe ve bunların içindeki dolandırıcılığa karşı kritik bir rol oynayan gözden kaçabilecek parçalarına bakalım.

yetkilendirme uç noktası:

belirteç değiştirme uç noktası:

İstemci Kimlik Bilgileri#

OAuth'ta, İstemci Kimlik Bilgileri bir istemci uygulamanın kimlik doğrulaması ve kendini yetkilendirme sunucusuna belirtme için kullanılan kimlik bilgilerini ifade eder. Bu kimlik bilgileri, istemci kayıt süreci sırasında elde edilir ve istemci, yetkilendirme sunucusuna yapılan istekler sırasında kimliğini doğrulamak için kullanılır. (İstemci kimlik bilginizi Logto'nun Admin konsolunda, uygulamanızı ilk kaydettiğinizde bulabilirsiniz.)

İstemci kimlik bilgileri genellikle iki bileşenden oluşur:

1. İstemci ID: İstemci uygulamasına yetkilendirme sunucusu tarafından atanmış benzersiz bir tanımlayıcı. Genellikle hassas kabul edilmeyen bir genel değerdir.
2. İstemci Secret: Yalnızca istemci ve yetkilendirme sunucusunun bildiği gizli ve güvenli bir şekilde saklanan değer. İstemci uygulaması için bir tür kimlik doğrulama görevi görür ve yetkilendirme sunucusuna yapılan istekler sırasında istemcinin kimliğini doğrulamak için kullanılır.

Gördüğünüz gibi, İstemci ID ve İstemci Secret kombinasyonu, istemciyi doğrulamak ve Erişim Belirteçleri elde etmek için belirteç isteği sırasında kullanılır.

İstemci kimlik bilgileri, OAuth akışının güvenliğini sağlamakta hayati bir rol oynar. Yetkilendirme sunucusunun istemci uygulamaların doğruluğunu doğrulamasına ve korunan kaynaklara erişimi kontrol etmesine yardımcı olurlar. İstemci kimlik bilgilerini güvenli bir şekilde işlemeniz ve yetkisiz erişimden korumanız önemlidir. Logto, istemci uygulamalarını iki farklı güvenlik seviyesine göre sınıflandırır:

• Gizli istemciler: Bunlar, sunucu tarafında render edilen web uygulamaları ve makine ile makine (M2M) uygulamalarını içerir. Gizli istemciler durumunda, tüm yetkilendirme ile ilgili kimlik bilgileri, istemci kimlik bilgileri de dahil olmak üzere güvenli bir şekilde sunucu tarafında saklanır. Ayrıca, tüm ara yönlendirme istekleri veri gizliliğini sağlamak için şifrelenir. Gizli istemciler için istemci kimlik bilgileri sızıntı riski çok düşüktür, bu nedenle doğası gereği daha güvenlidirler. Bu nedenle, gizli istemciler varsayılan olarak daha yüksek bir güvenlik seviyesi ile muamele görürler. Belirteç değişim akışında, İstemci Secret sunumu bir ZORUNLULUKTUR.
• Public clients: Bu, tek sayfalık web uygulamalarını (SPA) ve yerel uygulamaları içerir. Kamu istemcileri için, istemci kimlik bilgileri genellikle istemci tarafında sabit kodlanmıştır, örneğin bir JavaScript paketinde veya yerli bir platformdaki bir uygulama paketinde. Gizli istemcilere göre kimlik bilgilerinin sızmış olma riski daha yüksektir çünkü istemci kimlik bilgileri istemci tarafı kodunda doğal olarak maruz kalır. Belirteç değişim akışında, İstemci Secret sunumu İSTEĞE BAĞLI. Logto, bir kamu istemcisinden gelen kimlik bilgilerine varsayılan olarak güvenmez.

State#

OAuth akışında, state parametresi, istemcinin yetkilendirme sunucusuna gönderdiği yetkilendirme isteğine dahil edilen rastgele oluşturulan bir değerdir. Amacı, yetkilendirme süreci boyunca istemcinin isteğinin durumunu veya bağlamını sürdürmektir.

state parametresi, cross-site request forgery (CSRF) saldırılarını önlemek için bir güvenlik önlemi olarak işlev görür. Yetkilendirme sunucusu, kullanıcıyı kimlik doğrulama ve yetkilendirmenin ardından istemci uygulamasına yönlendirirken, yanıtta aynı durum değerini içerir. İstemci uygulaması, bu değeri yetkilendirme isteğinde gönderdiği orijinal state değeriyle karşılaştırmalıdır MUST.

Durum parametresini doğrulayarak, istemci, yetkilendirme sunucusundan aldığı yanıtın, gerçekleştirdiği başlangıç isteğiyle uyumlu olduğunu sağlar. Bu, bir saldırganın istemciyi, başka bir kullanıcı veya uygulama için tasarlanmış bir yanıtı kabul etmeye çalıştığı saldırıları önler.

Aşağıdaki kurgusal bir kullanım durumunda CSRF saldırısına örnek olarak şunu alın:

CSRF saldırısı: Sosyal hesabı bağlamak için dolandırıcılık - problem

Etkili bir durum doğrulama mekanizması ile istemci, saldırganın web sitesine yönlendirilmesini ve Kullanıcının önlenir:

CSRF saldırısı: Sosyal hesabı bağlamak için dolandırıcılık - çözüm

PKCE#

Daha önce de belirtildiği gibi, SPA web uygulamaları ve yerel uygulamalar gibi kamuya açık istemciler, yetkilendirme sunucusu tarafından verilen Yetkilendirme Kodu da dahil olmak üzere kimlik doğrulama kimlik bilgilerinin sızmasına daha yüksek bir risk taşır.

PKCE, Proof Key for Code Exchange için duruyor. Bu, kamuya açık istemcilerin güvenliğini artıran OAuth 2.0 Yetkilendirme Kodu Akışı'na bir uzantıdır.

PKCE, bir saldırganın Yetkilendirme Kodunu ele geçirip, istemcinin bilgisi olmadan bir Erişim Belirteci ile değiştirmesine karşı önlem alarak tanıtıldı. Yetkilendirme Kodu İntersepsiyon saldırısı olarak bilinen bu tür bir saldırı, İstemci uygulamanın bir müşteri sırrını güvenli bir şekilde saklayamadığı ortamlarda daha yaygındır.

PKCE'yi uygulamak için, istemci uygulaması rastgele bir Kod Doğrulayıcı oluşturur ve belirli bir hash algoritması (genellikle SHA-256) kullanarak bunun Çıktılı bir Kod meydan okuması çıkarır. Kod Meydan Okuması, yetkilendirme sunucusuna gönderilen ilk yetkilendirme isteğine dahil edilir.

Yetkilendirme sunucusu Yetkilendirme Kodunu verdiğinde, istemci uygulaması token isteğinde orijinal Kod Doğrulayıcıyı içerir. Sunucu, Kod Doğrulayıcının depolanan Kod Meydan Okuması ile eşleştiğini doğrular ve yalnızca o zaman Erişim Belirteci verir.

PKCE kullanarak, işemci uygulama, Yetkilendirme Kodu'nun kendi başına bir Erişim Belirteci almak için yeterli olmadığını sağlar. Bu mekanizma, özellikle Müşteri Sırlarının depolamasının zor olduğu kamu istemcileri için yetkilendirme akışına ek bir güvenlik katmanı ekler.

Logto, tüm kamu istemcisi tipi uygulamalar için PKCE'yi YALNIZCA yetkilendirme akısı kullanır. Ancak, PKCE ve gizli istemciler için atlanabilir.

Redirect URI#

Bir Redirect URI(Uniform Resource Identifier), OAuth'da, yetkilendirme ve yetkilendirme sürecinin ardından yetkilendirme sunucusunun kullanıcıyı geri yönlendirdiği belirli bir uç nokta veya URL'dir.

OAuth akışı sırasında, istemci uygulaması başlangıç yetkilendirme isteğinin bir parçası olarak bir Yönlendirme URI'si ekler. Bu URI, kullanıcı başarıyla kimlik doğruladıktan ve istemciye izinler verdikten sonra yönlendirileceği geri arama URL'si olarak işlev görür.

Kullanıcı kimlik doğrulama sürecini tamamladıktan sonra, yetkilendirme sunucusu bir yanıt oluşturur ki bu bir Yetkilendirme Kodu içerir, ve kullanıcıyı belirtilen Yönlendirme URI'sine yönlendirir.

Yönlendirme URI doğrulaması, OAuth akışının güvenliğini ve bütünlüğünü sağlamanın önemli bir adımıdır. Yetkilendirme isteğinde ve ardından yönlendirmelerde kullanılan Yönlendirme URI'nin geçerli ve güvendiği konumunu doğrulamayı içerir.

Hadi geri dönüp orijinal OAuth güvenlik açığı raporu'na bakalım. (Aşağıdaki bölüm, orijinal yayına atıfta bulunur)

Kullanıcı “facebook ile giriş yap” özelliğini Expo Go'daki Mobil UYGULAMA'yı kullanarak tıkladığında, kullanıcıyı aşağıdaki bağlantıya yönlendirir:

https://auth.expo.io/@moreisless3/me321/start?authUrl=https://www.facebook.com/v6.0/dialog/oauth?code_challenge=...&display=popup&auth_nonce=...&code_challenge_method=S256&redirect_uri=https://auth.expo.io/@moreisless3/me321&client_id=3287341734837076&response_type=code,token&state=gBpzi0quEg&scope=public_profile,email&returnUrl=exp://192.168.14.41:19000/--/expo-auth-session

** Yanıtta, auth.expo.io aşağıdaki çerezleri ayarlar: ru=exp://192.168.14.41:19000/--/expo-auth-session. RU'nun değeri, daha sonra adım 5'te Return Url olarak kullanılacaktır. Daha sonra kullanıcıya bir onay mesajı gösterir ve kullanıcı onaylarsa - yetkilendirme sürecine devam etmek için onu Facebook girişine yönlendirir **

…

Bu sayfa sorgu parametresi “returnUrl” okur ve çereze buna göre ayarlar.

Diyelim ki returnUrl'u hTTps://attacker.com (https izin verilmiyor, bu yüzden büyük harf girmeyi denedim ve işe yaradı) ile değiştirelim, bu çerezdeki RU (Return Url)'ı https://attacker.com yapar.

…

Yukarıdaki durumda, orijinal redirect_uri parametrelerini atarak, Expo returnUrl adı verilen yeni bir parametre tanıtıyor. Bu parametrin doğru bir şekilde doğrulanmaması, saldırganlara Facebook'tan dönen Yetkilendirme koduna erişim fırsatı sağladı. Daha fazla ayrıntı için, orijinal yayına bakınız.

Redirect URI doğrulama, birkaç önemli amaca hizmet eder:

1. Phishing saldırılarını önleme: Yönlendirme URI'yi doğrulayarak, yetkilendirme sunucusu, kullanıcının güvenilir ve yetkili bir uç noktaya yönlendirileceğini garanti eder. Bu, saldırganların kullanıcıları kötü niyetli veya yetkisiz konumlara yönlendirmesini önler.
2. Açık yönlendirmelere karşı koruma: Açık yönlendirmeler, kullanıcıların kötü niyetli web sitelerine yönlendirilmesi için kullanılabilecek güvenlik açıklarıdır. Yönlendirme URI'yi doğrulayarak, yetkilendirme sunucusu yönlendirmenin yetkili alan veya güvendiği alanlar kümesi sınırları içinde kalmasını sağlar.
3. Yetkilendirme yanıtlarının doğru rota ile yönlendirilmesini sağlama: Yönlendirme URI'sini doğrulamak, yetkilendirme sunucusu kullanıcısını ilgili istemci uygulamasına yönlendirmeyi garanti eder. Bu, Yetkilendirme Kodu veya Erişim Belirteci gibi bir yanıtın doğru hedefe teslim edildiğini garanti eder.

Logto'da, redirect_uri kaydı, tüm uygulama türleri için zorunludur. Kaydedilenlerle karşılaştırarak ve eşleştirerek Logto sunucusunda kaydedilenleri alınan değeri kontrol ederiz. Bu, herhangi özel arama parametrelerini içerir. Yetkilendirme isteği, eksik, geçersiz veya uyumsuz bir redirect_uri değeri nedeniyle doğrulama işlemini başarısızlığa uğrarsa, dosyada kaydedilen redirect_uri'ye geçersiz bir Yönlendirme URI hatası iade edilecektir.

Summary#

Bu detayların karmaşık ve ayrıntılı doğası nedeniyle, genellikle göz ardı edildiğini anlamak olasıdır. Bazıları sadece state gibi bir rastgele dize.

Ancak, bu güvenlik önlemlerinin kullanıcı yetkilendirmesine koruma katmanları eklediğine dikkat etmek önemlidir, CSRF saldırıları, Yetkilendirme Kodu hırsızlığı ve yetkisiz yönlendirmeler gibi riskleri azaltır.

Bu, OAuth protokolü tarafından sunulan kapsamlı güvenlik özelliklerinin yalnızca küçük bir parçasıdır. OAuth, güvenli kimlik doğrulama ve yetkilendirme için sağlam bir çerçeve sunar. Ayrıca, gerçek dünya ürün uygulamalarındaki çeşitli gereksinimleri karşılamak için esnek ve açık uç noktalar sunar.

Geliştiriciler ve hizmet sağlayıcılar olarak, kullanıcı yetkilendirme akışının güvenliğini sürekli olarak önceliklendirmek hayati önem taşır. Uyanık kalma, en iyi uygulamalara bağlı kalma ve OAuth ekosistemindeki en son gelişmeleri takip etme, kullanıcı kimliklerinin ve hassas verilerin bütünlüğünü ve korunmasını sağlamak için önemlidir. Kullanıcılarımızın gizliliğini ve güvenini korumak için OAuth'un uygulanmasındaki en yüksek güvenlik standartlarını uygulamaya devam edeceğiz.