General Topics Software Security

OAuth 2.0 Güvenliği – Ataklar ve Önlemler

Murat Kaya

 |  Jul 12, 2019

Giriş

Bu doküman OAUTH 2.0 için en önemli güvenlik sorunlarına ilişkin ne gibi önlemler alınması gerektiği konusunda detaylar ve tavsiyeler içermektedir.

Doküman güvenlik odaklı olduğundan ve anlaşılabilir olması açısından, öncesinde OAuth hakkında gerekli bilgi sahibi olunması gerekmektedir.

Tavsiyeler

Bu bölüm, OAuth uygulayıcılarına önerilmek üzere OAuth çalışma grubu tarafından dikkate alınması gereken güvenlik mekanizmalarını açıklamaktadır.

Yönlendirme temelli akışların korunması (Redirect-based Flows)

Yetkilendirme sunucusuna yapılacak isteklerde (Authorization Servers), istemci tarafından gönderilen yönlendirme URI bilgisi mutlaka daha önceden yetkilendirme sunucusunda kayıtlı olan URI bilgileri ile eşleştirilmelidir.

Bu sayede istemci üzerinden yapılan farklı URI yönlendirme adreslerine kimlik ve erişim bilgilerinin sızdırılmasını önlenebilir. Ayrıca yönlendirme URI bilgisi, yetkilendirme sunucusu üzerindeki URI bilgisi ile eşleşmediği durumlarda burada bir saldırı olduğu tespit edilebilir ve önlem alınabilir.

Açık yönlendirme (Open Redirect) ataklarına karşı azami önlemin sunucu tarafında alınmış olması gerekmektedir. Mümkün olduğunca istemci tarafından URI vasıtası ile yönlendirme değişkenleri doğrudan işletilmemelidir.

Sunucu ve istemci arasındaki veri iletişimde her iki tarafında aynı işlemin parçası olduğu garanti altına alınabilir. Bunun için tek kullanımlık “Çapraz-Site Sorgusu Engelleme (XSRF/CSRF)” anahtarı oluşturularak farklı bir kaynaktan gelecek ataklar engellenebilir. Bu anahtar bilgisi JWT (Json Web Token) içerisinde yer alan STATE değişkeni ile birlikte gönderilebilir ve kontrol edilebilir. Ayrıca STATE değişkeni de JWT imzasının bir parçası olacağından değiştirilemeyeceği garantilenmiş olur.

İstemci yetkilendirme sunucusu vasıtası ile PKCE (Proof Key for Code Exchange – Kod Değişimi için Konrol Anahtarı) yapısını kullanarak yetkilendirme sunucundan gelen cevaplara sokuşturma (injection) saldırılarına karşı da önlem alabilir.

Yeniden Token Kullanımının Engellenmesi

Yetkilendirme sunucusunda güvenli bir iletişim kanalı kullanılması (TLS) büyük önem taşımaktadır. TLS üzerinden tekrarlama (replay attack) gerçekleştirmek gerçekten çok zordur. Mümkün ise uçtan uca TLS ile güvenli iletişim kurulması önerilmektedir.

Ataklar ve Önlemler

Yetersiz URI Yönlendirme Kontrolleri Saldırıları (Insufficent URI Redirection Validations)

Bazı yetkilendirme sunucuları, istemciden gelen yönlendirme isteklerinde doğrudan yönlendirme yerine (kontrol edilmiş ve sunucuda doğrulanmış), yönlendirme desenlerinin kullanımına izin verir (regex benzeri). Genellikle bu kullanımdaki amaç birden fazla yönlendirme işleminde uyan desene göre hareket etmeyi sağlamak olsa da bu kullanım karmaşaya yol açar ve düzgün biçimde kodlanmamış yapılarda desenin kötüye kullanılması ile açık ortaya çıkar. Örneğin saldırgan direkt olarak yönlendirme URI adresini desene uyacak biçimde fakat kendi çıkarları doğrultusunda değiştirir ve tüm erişim bilgilerinin kendi yönlendirdiği adrese gönderilmesini sağlar.

Yetkilendirme Koduna (Authorization Code) Yapılan Saldılar

Grant Type Code (Yetkili Tip Kodu) akışına uygun ve tüm dünyaya açık yapıyı kullanan istemcilerde aşağıdaki gibi bir senaryo gerçekleşmektedir.

“Abc123red” istemcisi için “https://*.deneme.com/*” gibi bir yönlendirme URI bilgisi verildiğini düşünelim. Bu desen ile “deneme.com” ile ilişkili tüm adreslerinden yönlendirme işlemine izin verilmiş olacaktır. Bir saldırgan deneme.com üzerinde yetkili olduğunda veya bu domain de alt domain tanımlama yetkisine sahip olduğunda “https://xxxx.deneme.com” şeklinde bir alt domain (xxx) oluşturabilecek ve yönlendirme URI adresine bu bilgiyi girdiğinde yetkilendirme sunucundan dönecek olan anahtar ve kimlik bilgileri kendisine gönderilmiş olacaktır. Özellikle amazon, azure, google gibi bulut sistemlerinde çok tehlikelidir.

Atak senaryosu aşağıdaki adımlar ile gerçekleşmektedir;

• Saldırgan öncelikle kullanıcıyı kendi gönderdiği ve kontrolünde olan bir sunucu ile ilişkili bir linkte tıklaması için ikna etmelidir. Oltalama saldırıları bu aşamada önem arz etmektedir. Bu adresin “https://www.deneme.com” olduğunu varsayalım.
• Bu adrese tıklandığında, tıklayan kişinin bilgileri ile yetkilendirme sunucusuna (Authorization Endpoint) doğru bir yetkilendirme talebi başlatır. Örnek bir istek içeriği;  

• Yetkilendirme sunucusu ilgili isteği doğrulama işlemine geçer. Doğrulama işlemi yapılırken desen temelli olduğundan (Pattern) deneme.com ile ilgili olan tüm istekler işleme alınacaktır. Bu yüzden gelen istek talebi geçerli olacak ve işletilecektir. Özellikle otomatik doğrulama yapan servislerde bu işlem daha kolay ve tehlikeli olacaktır. Örneğin yukarıdaki talebi bir kişi yerine sistem yapıyor olsaydı hiçbir şekilde dikkat çekmeden isteğe olumlu cevap dönecekti.
• Kullanıcını dikkatinden kaçan ve başarılı olan bu saldırı sonrası, saldırgan ele geçirdiği kod/kimlik bilgileri ile artık direkt olarak token isteği yapabilecektir.

Not: Bu saldırı biçimi gizliliği sağlanmış (Confidential Clients) istemci/kişiler ile çalışmayacaktır. Çünkü kod değişim sürecince (Code Exchange) istemci gizli anahtarı/bilgisi de gerekmektedir. Bu saldırının başarılı olabilmesi için saldırganın aynı zamanda istemci gizli anahtarını da ele geçirmiş olması gerekmektedir.

Direkt/Örtülü Yetkilendirme Tipine (Implicit Grant) Yapılan Saldırılar

Bu tip yapılara yapılan saldırılar ile Yetkilendirme temelli (Authorization Code) yapıya gerçekleştirilen saldırılar aynı şekilde gelişmektedir. Benzer şekilde kendi kontrolündeki bir domain veya adrese yönlendirme yapması temeline dayanmaktadır.

Bu duruma ek olarak, eğer kullanıcı tarafından gelen isteğin başlık bilgisindeki (headers) yer/kaynak değerinde (location) ek bir tanımlama bilgisi (?, # v.b. ile başlayan tanım bilgileri, parametreler v.b.) yok ise HTTP protokolünün çalışma şekli gereği bu bilgi otomatik olarak yönlendirme bilgisinin sonuna eklenir. Burada eklenecek bilgi token bilgisi olacaktır.

Benzer şekilde “Abc123red” istemcisi için “https://xxx.deneme.com/ab?*” deseni kullanıldığını varsayalım. Burada görüleceği gibi “https://xxx.deneme.com/ab?” den sonra herhangi bir parametrenin gönderilmesine izin verilmiştir. Bu kullanım sonucunda aynı zamanda “Açık Yönlendirme (Open Redirector)” zafiyeti de ortaya çıkmıştır. “redirect_to” kullanımına izin veren bir yapıda saldırgan 302 kodu ile yönlendirme yapma imkanına sahip olmaktadır. Aşağıda adım adım bu senaryonun gerçekleşmesini görebiliriz

• Yetkilendirme temelli akışta olduğu gibi saldırgan öncelikle istemciye/kişiye oltalama saldırı ise kendi kontrolünde bir bağlantı bilgisi gönderir (tampered/malicious link)
• Burada yapılan istek neredeyse “Authorization Code” akış şemasında benzemektedir, tek fark yönlendirme işlemi için “redirect_to” parametresine saldırgan kendi kontrolündeki bir sunucuyu yazacaktır (dem0.com “o” yerine “0” konulmuştur).

• Yapılan istek desen tanımına uygun olduğundan, istek doğrulama kontrolünden geçmiş olacaktır. İlgili yapı çalışarak 302 yönlendirme isteğini işleme alacaktır.

• Burada “demo.com” sunucusuna gelen istek “Açık Yönlendirme” olarak algılanacağından, sistem redirect_to parametresini dikkate alacak ve buradaki değere yönlendirme yapacaktır. Yani istek tekrar 302 kodu ile birlikte “https://xxx.dem0.com/ab” adresine gönderilecektir.

• Bu noktada HTTP 1.1 protokolünün özelliği devreye girmektedir. Location parametresinde herhangi bir ek değer (fragment) yer almadığından, “redirect_to” parametresine otomatik olarak bir önceki istekten gelen değer eklenecektir. Bu da token değeri olacaktır ve yönlendirme uri bilgisi aşağıdaki hali alacaktır.

• Artık saldırgan ihtiyaç duyduğu token bilgisine sahiptir.

Önlemler

Desen ile eşleştirme yönteminin (Pattern matching, regex v.b.) karmaşıklığı ve yönetim zorluğu beraberinde güvenlik sorunlarının da artmasına sebep olacaktır. Bu tür problemlerin ve karmaşıkların ortadan kaldırılabilmesi ve daha güvenli bir yapı kurulabilmesi amacı ile sadece “Tam Eşleşen” URI bilgileri ile yönlendirme işleminin yapılması gerekmektedir. Bu sayede yetkilendirme sunucusu (Authorization Server) kolaylıkla kendisinde tanımlı olan ve istemciden gelen URI bilgilerini karşılaştırarak işleme devam edip etmeyeceğine güvenli biçimde karar verebilecektir.

Bu değişikliğin aşağıdaki yan etkileri olacağı gözden kaçırılmamalıdır:

• Tüm OAuth istemcileri işlem durumunu ve XSRF anahtar bilgisini “state” parametresi üzerinden yönetmek durumundadır. Bu durum daha önce anlatıldığı gibi dinamik URI sorgularında parametre kullanımına izin verildiğinden normal karşılanmalıdır. Pratikte gerçekten kullanılıp kullanılmayacağına mevcut uygulamalardan toplanacak verilerin incelenmesi ile karar verilebilir (Günümüzde yayınlanmış olan global uygulamalar)
• Uygulama geliştiriciler için belirlenmiş sabit bir desen tanımı yoktur. Bu yüzden her bir geliştirici kendine uygun desen eşleşme modelini kullanabilir fakat her durumda önerilen tam URI eşleşmesi ile yönlendirmeye izin vermek olmalıdır.
• Birden fazla yönlendirme URI bilgisine ihtiyaç duyan istemciler için, tüm yönlendirme URI bilgileri açıkça sunucu tarafında da tanımlanmalıdır.
• Tam URI yönlendirmesi yerel web sunucusu kullanan ve yine yerel (Native) uygulamalar için kullanılamaz. Çünkü yerel web sunucularında dinamik port numaraları atanabilmektedir. Bunun önüne geçebilmek için URI bilgisinde port numarası yerine yıldız “*” karakteri kullanılmak zorundadır.

Ek önlemler:

• Geri çağrımları yöneten sunucular (Callback Servers) açık yönlendirici (open redictors) bilgilerini ifşa etmemelidirler.
• Tam URI yönlendirme yerine dijital imza altyapısı da kullanılabilir.

Yetkilendirme Anahtar ve Bilgilerinin Yönlendirme Başlıkları ile Sızdırılması

Bir OAuth istemcisi, başarılı bir yetkilendirmenin sonucu olarak diğer sayfalara (reklamlar, SSS, …) bağlantılar içeren bir sayfa oluşturuyorsa, yetkilendirme kodlarının istemcilere bildirilmemesi olasıdır.

Eğer bir kullanıcı oluşturulan bu linklerden birisine farkında olarak veya olmayarak tıklar ise, yönlendirme (referer) başlık bilgisinde geldiği kaynak olarak token ve yetkilendirme bilgilerinin olduğu link yer alacağından, karşı sisteme bu bilgiler gönderilmiş olacaktır.

Linkin gittiği adres bir şekilde saldırganın kontrolü altındaki bir sistem ise, saldırgan sunucu kayıtlarından referer bilgilerini okuyarak buradaki anahtarları tekrar kullanabilecektir.

Benzer şekilde, saldırgan sayfa içerisine başarılı bir biçimde kendi çapraz domain içeriğini (XSS) yerleştirebilir ise (Örneğin <img src=http://xxx.dem0.com/test.jpg>) bu içerik çağrımında yine “referer” yönlendirme bilgisi olacağından kullanıcını yetki anahtar bilgileri sızmış olacaktır.

Önlemler

• Yetkilendirme kodu bir sefer kullanılabilecek şekilde üretilmelidir. Saldırgan bir şekilde bu kod bilgisine ulaşsa bile tek seferlik kullanım olduğundan işine yaramayacaktır.
• Yetkilendirme kodu PKCE (Proof Key for Code Excanhge – Kod/Anahtar Değişimi için Ön Onaylama Anahtarı ) ile bir döngüye dâhil edilebilir (challenge). Saldırganda Proof Key olamayacağından, kod/anahtar bilgisini alabilmesi için gerekli döngüyü başlatamayacaktır. Farklı olarak yetkilendirme kodu/anahtarı gizli istemcide (confidential client/web application/web server) tutulabilir.
• Bir OAuth yetkilendirme işlem yanıtının sonucu olan sayfalarda harici sitelere bağlantılar eklenmemelidir.
• HTML linklerine ek parametre olarak “rel=noreferrer” eklenebilir. Bu şekilde linkler ile birlikte başlık (header) bilgisinde referer bilgisinin gönderilmesi engellenmiş olacaktır.
• HTML sayfalarında “referer” başlık bilgisi eklenerek ve uygun parametre belirterek (no-referer v.b.) başlık bilgilerinde yönlendirme bilgisi gönderimi engellenebilir.
• Yetkilendirme işlemi sonucu yönlendirme için direkt yönlendirme işlemi yerine Form Gönderim Cevabı (Form Post Response) metodu tercih edilmelidir. Bu yöntemde yetkilendirme sunucusundan gelen veriler form verisi olarak ve şifrelenmiş/kodlanmış biçimde dönecektir. URI üzerinde herhangi bir veri almadığından daha güvenli bir yapı olacaktır.

Tarayıcıya Yönelik Saldırılar

Tarayıcı Belleğinde/Tarihçesinde Yer Alan Erişim Kod (Authorization Code) Bilgileri

Bir kullanıcı uygulamanın yetkilendirme sunucusuna gittiğinde, bu çağrım kullanıcının tarayıcı geçmişine kayıt edilebilir. Örneğin https://demo.com/redirect_enp?code=123abc gibi bir çağrım sonucunda bu istek olduğu gibi tarayıcı geçmişinde yer alabilir. Çağrım yapılan cihaza (tablet, pc veya telefon) erişimi olan bir kişi bu bilgileri tarayıcı geçmişinden elde ederek kullanabilir.

Tarayıcı Belleğinde/Tarihçesinde Yer Alan Erişim Anahtarı (Authorization Token) Bilgileri

Normalde sadece başlık bilgilerinde gönderilmesi gereken erişim anahtarı (Authorization Token) bilgisinin istek sorgu parametreleri ile gönderilmesi sonucu anahtar bilgisi aynı şekilde tarayıcı geçmişine kayıt edilebilir. Örneğin https://demo.com/get_permissions?access_token=1234asbc gibi bir sorgu ile iletilen istek büyük ihtimalle tarayıcı geçmişine kayıt edilecektir.

Örtülü yetkilendirmede de (Implicit Grant) https://demo.com/redir_endp#access_token=123abc gibi bir URL sorgusunda anahtar bilgisi yer alacağından benzer şekilde tarayıcı tarihçesinde kayıtlı olabilmektedir.

Önlem olarak;

• Örtülü akış (Implicit Flow) yapısında form post yapısı kullanılabilir veya yetki kod (authorization code) yapısı tercih edilebilir.
• Asla erişim anahtarları veya kodları URL üzerindeki sorgu parametreleri ile gönderilmemelidir.

Mix-Up (Karıştırma) Saldırıları

Mix-up (Karıştırma) saldırıları genellikle birden fazla uç nokta kullanılan OAuth yapılarında görülmektedir. Örneğin istemci tarafından “cevap tipi” olarak (response type) “kod” (code) kullanıldığında, istemci hem yetkilendirme uç noktasını (authorization endpoint) hem de anahtar uç noktasını (token endpoint) kullanmak zorundadır. Burada önemli olan her iki uç noktanın da aynı yetkilendirme sunucusu üzerinde birlikte kullanılıyor olmasıdır. Bunun tersi durumlarda ise mix-up olarak adlandırılan karıştırma saldırısı gerçekleştirilebilmektedir.

Bu saldırı biçiminde amaç MITM (Man in the middle-araya girme) saldırısına benzer biçimde bir istemcinin iki farklı uç nokta erişimi sırasında anahtar bilgisinin saldırganın belirlediği bir adrese gönderilmesini sağlamaktır.

Senaryo şu şekilde gerçekleşmektedir; İstemci response tip olarak “code” belirttiğinden ilk olarak istemci yetkilendirme noktasına gider buradan alınan bilgi ile birlikte token noktasına devam etmesi gerekmektedir. Bu aşamada araya giren saldırgan token noktası yerine kendi belirlediği bir sunucuya yönlendirme yaparak yetkilendirme sunucusunda üretilen bilgiye sahip olmuş olur.

Önlem olarak;

• İstemci, yetkilendirme sunucusuna bir istekte bulunurken bu sunucuya özel bir yönlendirme URI bilgisini kullanır ve bu bilginin bir kopyasını kendisinde tutar. Yetkilendirme sunucusundan dönen cevapta yer alan yönlendirme URI bilgisi ile kendi üzerinde tuttuğu yönlendirme URI bilgisini karşılaştırarak doğruluğundan emin olabilir.
• Yetkilendirme sunucusu üzerinden dönen “client_id” ve “iss” bilgileri ile karşılaştırma yaparak doğrulama yapılabilir (OpenId Connect’te ID bilgisi dönmektedir).

Kod Enjeksiyon (Code Injection) Saldırıları

Yetkilendirme Kod Enjeksiyon (Authorization Code Injection)

Böyle bir saldırıda, saldırgan, çalınan bir cihazdaki bir yetki kodunu veya anahtarı, kendi kontrolündeki bir cihaza veya uygulamaya enjekte etmeye çalışır.

Fakat bazı durumlar vardır ki saldırının başarılı olabilmesi ya çok zordur ya da mümkün değildir.

Örnek vermek gerekirse;

• Saldırgan, hedef olarak belirlediği istemcideki özel bir fonksiyona veya metoda erişmek istemektedir.
• Bu fonksiyon veya metot erişimi için gerekli olan istemci kimlik bilgilerine sahip değildir.
• Yetkilendirme ve kaynak sunucuları saldırganın direkt olarak erişemeyeceği kısıtlı bir ağ içerisinde yer almaktadır.

Bu durumda saldırı aşağıdaki adımlar ile gerçekleşebilir;

• Saldırgan daha önce yukarıdaki maddelerde bahsedilen yöntemlerin bir veya birkaçını deneyerek yetkilendirme kodunu almayı başarır. Örnek vermek gerekir ise saldırgan, yetkilendirme uç noktasından döndürülen yetkilendirme kodunu, Aktarım Katmanı Güvenliği (TLS) tarafından korunmayan bir iletişim yolu üzerinden araya girerek elde eder.
• Kendi kontrolündeki bir cihaz üzerinde geçerli olan mevcut bir istemci uygulaması ile normal bir OAuth yetkilendirilme sürecini başlatır.
• Saldırgan yetkilendirme sunucusundan dönen cevaba, daha önceden elde ettiği çalıntı yetkilendirme kodunu enjekte eder
• İstemci bu yetki kodunu client_id, client secret ve redirect_uri parametreleri ile yetkilendirme sunucusunun token karşılama/dinleme (endpoint) noktasına gönderir.
• Yetkilendirme sunucusu istemci anahtarını (client secret) kontrol ederek, bu anahtarın gerçekten geçerli bir istemci tarafından ve geçerli bir yönlendirme bilgisi ile (redirect_uri) yapılıp yapılmadığını doğrulamaya çalışır.
• Eğer tüm kontroller sonucunda geçersiz bir durum oluşmaz ise, yetkilendirme sunucusu erişim için gerekli olan token (access token) ve var ise diğer token bilgilerini istemciye gönderir (saldırgan). Bu bilgiler ile artık saldırgan yetkilendirmiş bir kullanıcıyı taklit edebilecektir.

Önlem olarak;

• “nonce” Kullanımı: Nonce guid(rastgele üretilmiş bir değer) ile güçlendirilmiş, bir çeşit zaman damgası denebilir. OpenID Connect yapısında yer alan “nonce” parametresi ile olası yetkilendirme kodu enjeksiyonlarına karşı yapılan ataklar engellenebilir. “nonce” istemci tarafından bir defa kullanılabilecek şekilde ve rastgele oluşturulmuş bir değerdir. İstemci bu değeri kendi oturum bilgisine ekleyerek OpenID servisine gönderir. OpenID ise bu değeri alarak yetkilendirme kodu ve ID Token ile birlikte kullanır. Eğer saldırgan bir şekilde yetkilendirme uç noktasından gelen cevaba kendi bilgilerini (kodunu) enjekte etmek isterse, istemci tarafındaki “nonce” değeri ile ID token üzerindeki “nonce” değer farklı olacağından saldırı tespit edilebilir ve engellenebilir. Çünkü saldırgan yetkilendirme kodunu bir şekilde elde edebilse bile istemci üzerinde oluşturulmuş olan “nonce” değerini elde edemeyecektir.
• “state” Kullanımı: [RFC6749] ‘da belirtilen “state” parametresi yukarıda açıklananlara (nonce) benzer şekilde kullanılabilir. Bu yöntemde, kod değişim uç noktası (code excnahge token endpoint) isteğine “state” olarak başka bir parametre eklenmesi şeklindedir. Yetkilendirme sunucusu daha sonra kodla ilişkilendirilen “state” değerini ve parametredeki “state” değerini karşılaştırır. Bu değerler eşleşmezse, bir saldırı olarak kabul edilir ve istek başarısız olur. Bu yaklaşımın avantajı, mevcut bir OAuth parametresinin kullanılıyor olmasıdır. Ancak, “state”‘in amacını yeniden yorumlamak ve token uç nokta isteğini uzatmak anlamına da gelir.
• “PKCE” Kullanımı: “Proof Key for Code Exchange”‘in kısaltmasıdır. PKCE parametresi (diğer adı ile “code_challenge” veya [RFC7636] ‘deki tanımı olan “code_verifier”), “nonce” veya “state” ile aynı şekilde kullanılabilir. Öncelikle yerel ve mobil uygulamalar tarafından kullanılır, ancak bu yöntem herhangi bir genel istemciye de uygulanabilir. Yetkilendirme sunucusu tarafından ek destek gerektirir, bu nedenle yalnızca belirli sağlayıcılarda desteklenir. Temel amacı kod akışının hiçbir şekilde kesintiye uğramadığını (incercept) ve süreci başlat ile bitirenin aynı kişi/sistem olduğunu garanti etmektir.
• “Token Binding” kullanımı: Bu tür bir kullanımda, yetkilendirme kodu, kullanıcı uygulama aracısı (user agent) ile yetkilendirme sunucusu arasında ve yine kullanıcı uygulama aracısı (user agent) ile istemci arasında bir bağ kurmalıdır (Two leg binding). Her ne kadar “Token binding” güvenli ve kullanışlı bir mekanizma olarak “umut verici” olsa da (özellikle tarayıcı entegrasyonundan dolayı), geniş tarayıcı desteği gerektirmesi gibi bazı engellerden dolayı ve yerel uygulamalar ile birlikte kullanılmasında karşılaşılabilecek sorunlar nedeni ile hala uygunluğu tartışılmaktadır.
• “Per-instance client id/secret” Kullanımı: Web uygulama modeline uygun bir yapı olmamakla beraber temelinde her bir örneklemeye (instance) bir client_id/secret bilgisi eklenmesi/bağlanması durumudur. Her bir kullanıcı için özel ID oluşturulması ve saklanması gerekmektedir. Pratikte bir kullanımı yoktur.

Önceden hazırlanmış client-secret ilgili not: Saldırgan, kontrolü altında bulunan bir cihazda “secret” ya da “code_challenge” dosyasını yaratabilecekse ya da ele geçirebildiyse, saldırgan yukarıda belirtilen önlemleri aşabilir. Yetkilendirme isteklerindeki URI yönlendirmelerinin (URI Redirection) eşleştirilmesi ve kontrol edilmesi, saldırganın kurbanın cihazındaki sahte yetkilendirme işleminde önceden hazırlanmış “client secret” kullanmasını engelleyebilir.

Bu önlem, ne yazık ki, tüm OAuth istemcileri için etkili değildir. Web ve JS uygulamaları için ve talep edilen URL’lere sahip yerel uygulamalar için etkilidir. Web ve JS uygulamaları için ve talep edilen URL’leri doğrulayabilen yerel uygulamalar için etkilidir.

Bu yapıda (önceden hazırlanmış secret); Yetkilendirme sunucusunun, PKCE veya “nonce” yapısı ile kullanımda tek bir seferlik işleme izin vermesi / bu tür değerlerin tek bir defa kullanımına zorlaması dışında, özel şemalar ve yapılar kullanarak yerel uygulamalara yapılan saldırıların önlenmesi mümkün olmamaktadır.

BÖLÜM 1 – SON