OAuth 2.0'da istemci sırrı

95

Google drive api'yi kullanmak için, OAuth2.0 kullanarak kimlik doğrulama ile oynamalıyım. Ve bununla ilgili birkaç sorum var.

  1. İstemci kimliği ve istemci sırrı, uygulamamın ne olduğunu belirlemek için kullanılıyor. Ancak bir istemci uygulamasıysa kodlanmış olmaları gerekir. Böylece herkes uygulamamı derleyip kaynak kodundan çıkarabilir. Kötü bir uygulamanın, iyi uygulamanın istemci kimliğini ve sırrını kullanarak iyi bir uygulama gibi davranabileceği anlamına mı geliyor? Yani kullanıcı, aslında kötü bir uygulama tarafından istenmesine rağmen iyi bir uygulamaya izin verilmesini isteyen bir ekran gösteriyor olabilir mi? Varsa ne yapmalıyım? Ya da aslında bunun için endişelenmemeli miyim?

  2. Mobil uygulamada, uygulamamıza bir web görünümü yerleştirebiliriz. Ve web görünümünde parola alanını çıkarmak kolaydır çünkü izin isteyen uygulama aslında bir "tarayıcıdır". Öyleyse, mobil uygulamadaki OAuth, istemci uygulamasının servis sağlayıcının kullanıcı kimlik bilgilerine erişememesi avantajına sahip değil mi?

security  oauth  google-api  oauth-2.0 
— Ayı
kaynak
2
Ayrıca, uygulama onlardan Facebook, Twitter, Dropbox veya diğer kimlik bilgilerini istediğinde insanlar genellikle şüphe duyuyorlar. Pek çok sıradan insanın OAuth spesifikasyonunu okuyup "Şimdi güvendeyim" dediğinden şüpheliyim, ancak bunun yerine sağduyulu davranıyor ve genellikle güvenmedikleri uygulamaları kullanmıyorum.
— Igor Čordaš
Gerçekten harika bir sorunun kesinlikle daha fazla puanı olmalı
— Shravan
ClientId'yi ve sırrı sunucunuzdan indirebilir ve ilk başarılı oturum açma işleminde bir anahtar zincirine kaydedebilirsiniz işte bu
— Shravan
@Sharvan Yanılıyor olabilirim ama anahtar zincirlerinin köklü telefonlarda savunmasız olduğunu düşünüyorum, bu nedenle müşteri sırrınız halka açıklanabilir.
— chichilatte

Yanıtlar:

16

Sorunuza bir yorum yazmaya başladım ama sonra söylenecek çok şey olduğunu öğrendim, bu yüzden cevabın içindeki konuyla ilgili görüşlerim burada.

  1. Evet, bunun için gerçek bir olasılık var ve buna dayalı bazı istismarlar vardı. Öneri, uygulamanızda uygulamayı gizli tutmak değil, spesifikasyonda dağıtılmış uygulamaların bu belirteci kullanmaması gerektiği konusunda bir parça bile var. Şimdi sorabilirsiniz, ancak XYZ çalışması için buna ihtiyaç duyar. Bu durumda, spesifikasyonu düzgün bir şekilde uygulamazlar ve A, bu hizmeti kullanmamalısınız (olası değildir) veya B, sunucunuzu bulmayı veya proxy olarak kullanmayı zorlaştırmak için bazı şaşırtma yöntemlerini kullanarak jetonu korumaya çalışmalısınız.

    Örneğin, Android için Facebook kitaplığında, Logs'a jeton sızdırdığı bazı hatalar vardı, bu konuda daha fazla bilgiyi burada bulabilirsiniz http://attack-secure.com/all-your-facebook-access-tokens-are-belong -bize ve burada https://www.youtube.com/watch?v=twyL7Uxe6sk . Sonuç olarak, üçüncü taraf kitaplıkları kullanımınız konusunda ekstra dikkatli olun (aslında sağduyu, ancak simge kaçırma büyük endişenizse, temkinli olmaya başka bir şey daha ekleyin).

  2. Bir süredir 2. nokta hakkında söylüyorum. İzin sayfalarını değiştirmek için uygulamalarımda bazı geçici çözümler bile yaptım (örneğin yakınlaştırma ve tasarımı uygulamaya uyacak şekilde değiştirmek), ancak kullanıcı adı ve şifre ile web görünümündeki alanlardan değerleri okumaktan beni alıkoyan hiçbir şey yoktu. Bu nedenle, ikinci fikrinize tamamen katılıyorum ve OAuth spesifikasyonunda büyük bir "hata" buluyorum. Spesifikasyondaki "Uygulamanın kullanıcıların kimlik bilgilerine erişememesi" sadece bir rüya ve kullanıcılara yanlış bir güvenlik hissi veriyor… Ayrıca sanırım insanlar, uygulama onlardan Facebook, Twitter, Dropbox veya diğer kimlik bilgilerini sorduğunda genellikle şüphe duyuyorlar. Pek çok sıradan insanın OAuth spesifikasyonunu okuyup "Şimdi güvendeyim" dediğinden şüpheliyim, ancak bunun yerine sağduyulu davranıyor ve genellikle güvenmedikleri uygulamaları kullanmıyorum.

— Igor Čordaš
kaynak
3
İstemci kimliğiniz ve istemci sırrınız, sırf bir SSL tüneline gönderdiğiniz için güvende olmayacaktır. Evet, orta ataklardaki insandan daha güvenlidirler. Bir kullanıcı HTTP çağrılarınıza proxy uygularsa, kötü sertifikayı kabul edebilir ve gönderdiğiniz her şeyi görebilir. Bu arada, mobil cihazlarda birinin istemci sırrını çalmanın en kolay yolu budur.
— EpicThreeDev
5
Yorumunuz için minnettarım ama cevabımla hiçbir şekilde bağlantı kuramıyorum ... Lütfen cevabıma neden yorum yaptığınızı açıklar mısınız çünkü açıkça İstemci sırrının dağıtılmış uygulamalarda kullanılmaması gerektiğini belirttim ve diğer nokta şuydu: OAuth kullanıyor olsa bile uygulamalarda kullanıcı kimlik bilgilerini almak için geçici çözümler vardır, böylece kullanıcılar OAuth'a değil uygulama sağlayıcısına güvenmelidir.
— Igor Čordaš
Ayrıca, "Bir kullanıcı HTTP'lerinizin proxy'sini çağırırsa" derken neyi kastettiğinizi anlamıyorum, evet kullanıcılar HTTP'leri kullanarak gönderdikleri verilere erişebilir ve istedikleri gibi proxy çağrıları yapmakta özgürdürler. Anladığım kadarıyla bunu sırrı öğrenmek için apk'yi sökmeye oldukça güzel bir alternatif olarak öneriyorsunuz, ancak yine de ilk etapta uygulama sırrı göndermemelisiniz.
— Igor Čordaš
Öyleyse, 1. nokta için) kötü uygulamanın aynı sisteme erişmesi ve erişim / yenileme belirtecini aynı cihazdan alması gerekiyor mu?
— gauteh
Bu bağlamda neyi "aynı sistem" olarak gördüğünüz net değil. Uygulama, onay sayfasının gösterildiği bir web görünümü oluşturur ve bu görünümdeki tüm verilere (erişim jetonunu barındıran çerezler veya url parametreleri dahil) erişebilir. Bazı durumlarda uygulamalar arası erişim de mümkündür, örneğin bir uygulama diğer uygulama günlüklerine erişebiliyorsa, fb lib hatasında belirtildiği gibi token'ı orada bulabilir.
— Igor Čordaš
16

Buradaki soru 1 ile aynı soruyu sormuştum ve son zamanlarda kendim biraz araştırma yaptım ve sonucum, "müşteri sırrı" nı sır olarak saklamamanın sorun olmadığıdır. İstemci sırrını korumayan istemcilerin türüne OAuth2 spesifikasyonunda "genel istemci" denir. Kötü niyetli birinin yetkilendirme kodunu alıp ardından jetona erişme olasılığı aşağıdaki gerçeklerle engellenir.

1. Müşterinin, yetkilendirme kodunu hizmetten değil, doğrudan kullanıcıdan alması gerekir

Kullanıcı, müşteriye güvendiği hizmeti belirtse bile, istemci sadece istemci kimliği ve istemci sırrını göstererek hizmetten yetkilendirme kodu alamaz. Bunun yerine, müşterinin yetkilendirme kodunu doğrudan kullanıcıdan alması gerekir. (Bu genellikle daha sonra bahsedeceğim URL yeniden yönlendirme ile yapılır.) Bu nedenle, kötü niyetli istemci için, kullanıcının güvendiği istemci kimliğini / sırrını bilmek yeterli değildir. Kullanıcı kimliğini / sırrını bilmekten daha zor olan yetkilendirme kodunu vermek için bir şekilde kullanıcıyı dahil etmesi veya yanıltması gerekir.

2. Yönlendirme URL'si, istemci kimliği / sırrı ile kaydedilir

Kötü niyetli istemcinin, kullanıcıyı bir şekilde dahil etmeyi ve hizmet sayfasındaki "Bu uygulamayı yetkilendir" düğmesini tıklamasını sağladığını varsayalım. Bu, hizmetten gelen yetkilendirme koduyla birlikte kullanıcının tarayıcısına URL yönlendirme yanıtını tetikleyecektir. Daha sonra, yetkilendirme kodu kullanıcının tarayıcısından yönlendirme URL'sine gönderilecek ve istemcinin yetkilendirme kodunu almak için yönlendirme URL'sini dinlemesi beklenmektedir. (Yönlendirme URL'si de localhost olabilir ve bunun "genel istemcinin" yetkilendirme kodunu almasının tipik bir yolu olduğunu düşündüm.) Bu yönlendirme URL'si hizmete istemci kimliği / sırrı ile kaydedildiğinden, kötü niyetli istemci bunu yapmaz yetkilendirme kodunun nereye verildiğini kontrol etmenin bir yolu var.

— Hideaki
kaynak
3
Bu umut verici, bunun için herhangi bir referansınız var mı? Bilmek güven verici olur.
— gauteh
1
Drive belgelerinde, yüklü uygulamalarda istemci sırrının gerçekte bir sır olmadığını gördüm, ancak orada saklamanın neden uygun olduğunu açıklamadılar. Açıklamanız çok yardımcı oldu!
— Martin Spasov
1

2. soruya cevap: Güvenlik nedeniyle Google API'leri, kimlik doğrulama / oturum açma işleminin Uygulamanın kendi içinde yapılamayacağını (web görüntülemelerine izin verilmediği gibi) ve aşağıda daha fazla açıklanacak şekilde daha iyi güvenlik için Tarayıcı kullanılarak uygulama dışında yapılması gerektiğini zorunlu kılar: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

— vj
kaynak
en azından sorduğumdan 3 yıl sonra "düzeltildi" :)
— Ayı
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.