Uygulamalarda özel API anahtarlarını saklamak ve korumak için en iyi uygulama [kapalı]

Çoğu uygulama geliştiricisi, bazı üçüncü taraf kütüphanelerini uygulamalarına entegre edecektir. Dropbox veya YouTube gibi bir hizmete erişmek veya çökmeleri günlüğe kaydetmek içinse. Üçüncü taraf kütüphane ve hizmetlerinin sayısı şaşırtıcıdır. Bu kitaplıkların ve hizmetlerin çoğu, bir şekilde hizmetle kimlik doğrulaması yapılarak entegre edilir, çoğu zaman bu bir API anahtarı aracılığıyla gerçekleşir. Güvenlik nedeniyle, hizmetler genellikle gizli ve anahtar olarak da adlandırılan genel ve özel bir alan oluşturur. Ne yazık ki, hizmetlere bağlanmak için, bu özel anahtar kimlik doğrulaması için kullanılmalıdır ve bu nedenle muhtemelen uygulamanın bir parçası olmalıdır. Söylemeye gerek yok, bu büyük bir güvenlik problemiyle karşı karşıya. Herkese açık ve özel API anahtarları birkaç dakika içinde APK'lardan çıkarılabilir ve kolayca otomatikleştirilebilir.

Buna benzer bir şeyim olduğunu varsayarsak, gizli anahtarı nasıl koruyabilirim:

public class DropboxService  {

    private final static String APP_KEY = "jk433g34hg3";
    private final static String APP_SECRET = "987dwdqwdqw90";
    private final static AccessType ACCESS_TYPE = AccessType.DROPBOX;

    // SOME MORE CODE HERE

}

Size göre özel anahtarı saklamanın en iyi ve en güvenli yolu nedir? Şaşkınlık, şifreleme, ne düşünüyorsun?

1. Olduğu gibi, derlenmiş uygulamanız anahtar dizeleri, aynı zamanda sabit adları APP_KEY ve APP_SECRET içerir. Bu tür kendi kendini belgeleyen koddan anahtarları çıkarmak çok önemlidir, örneğin standart Android aracı dx ile.

2. ProGuard'ı uygulayabilirsiniz. Anahtar dizgelerine dokunulmaz, ancak sabit adları kaldırır. Ayrıca sınıfları ve yöntemleri mümkün olduğunca kısa, anlamsız adlarla yeniden adlandıracaktır. Anahtarların ayıklanması, daha sonra hangi dizenin hangi amaca hizmet ettiğini bulmak için biraz daha zaman alır.

   ProGuard kurmanın korktuğunuz kadar zor olmaması gerektiğini unutmayın. Başlamak için, yalnızca project.properties dosyasında belgelendiği gibi ProGuard'ı etkinleştirmeniz gerekir. Üçüncü taraf kitaplıklarla ilgili herhangi bir sorun varsa, proguard-project.txt dosyasında bazı uyarıları bastırmanız ve / veya bunların gizlenmesini önlemeniz gerekebilir. Örneğin:

   -dontwarn com.dropbox.**
   -keep class com.dropbox.** { *; }

   Bu kaba-kuvvet yaklaşımıdır; işlenen uygulama çalıştıktan sonra bu yapılandırmayı hassaslaştırabilirsiniz.

3. Dizeleri kodunuzda manuel olarak, örneğin bir Base64 kodlamasıyla veya tercihen daha karmaşık bir şeyle karıştırabilirsiniz; belki de yerel kod. Daha sonra bir bilgisayar korsanı kodlama işleminizi statik olarak tersine mühendislikle yapmak veya kod çözme işlemini uygun bir yerde dinamik olarak kesmek zorundadır.

4. ProGuard'ın özel kardeş DexGuard'ı gibi ticari bir obfuscator uygulayabilirsiniz . Ayrıca dizeleri ve sınıfları sizin için şifreleyebilir / gizleyebilir. Anahtarları çıkarmak daha fazla zaman ve uzmanlık gerektirir.

5. Uygulamanızın bazı bölümlerini kendi sunucunuzda çalıştırabilirsiniz. Anahtarları orada tutabilirsen güvende olurlar.

Sonunda, yapmanız gereken ekonomik bir değiş tokuş: anahtarlar ne kadar önemli, ne kadar zaman veya yazılım satın alabilirsiniz, anahtarlarla ilgilenen hackerlar ne kadar sofistike, ne kadar zaman isteyecekler anahtarlar hacklenmeden önce ne kadar gecikmeli, başarılı bir hacker anahtarları hangi ölçekte dağıtacaktır. Anahtarlar gibi küçük parçaların korunması tüm uygulamalardan daha zordur. Gerçekte, istemci tarafında hiçbir şey kırılmaz değildir, ancak kesinlikle çubuğu yükseltebilirsiniz.

(ProGuard ve DexGuard'ın geliştiricisiyim)

Birkaç fikir, bence sadece birincisi bazı garanti veriyor:

1. Sırlarınızı internetteki bazı sunucularda saklayın ve gerektiğinde bunları kullanın ve kullanın. Kullanıcı dropbox kullanmak üzereyse, hiçbir şey sitenize istekte bulunmanızı ve gizli anahtarınızı almanızı engellemez.

2. Sırlarınızı jni koduna koyun, kütüphanelerinizi daha büyük ve daha kolay ayrıştırmak için bazı değişken kodları ekleyin. Ayrıca anahtar dizesini birkaç parçaya bölebilir ve bunları çeşitli yerlerde tutabilirsiniz.

3. obfuscator kullanın, ayrıca kod karma gizli koymak ve daha sonra kullanmak gerektiğinde unhash.

4. Gizli anahtarınızı varlıklardaki resminizden birinin son pikseli olarak koyun. Daha sonra gerektiğinde kodunuzda okuyun. Kodunuzu gizlemek, okuyacak kodu gizlemeye yardımcı olacaktır.

APK kodunu okumanın ne kadar kolay olduğuna hızlı bir şekilde bakmak istiyorsanız APK'yi yakalayın:

http://developer.sonymobile.com/knowledge-base/tool-guides/analyse-your-apks-with-apkanalyser/

Başka bir yaklaşım, ilk başta cihazda sır olmamasıdır! Bkz. Mobil API Güvenlik Teknikleri (özellikle bölüm 3).

Onurlandırılmış zamanlama geleneğini kullanarak, sırrını API uç noktanızla bir uygulama kimlik doğrulama hizmeti arasında paylaşın.

Müşteriniz bir API çağrısı yapmak istediğinde, uygulama yetkilendirme hizmetinden kimlik doğrulaması yapmasını ister (güçlü uzaktan doğrulama teknikleri kullanarak) ve sır tarafından imzalanan zaman sınırlı (genellikle JWT ) jetonu alır .

Belirteç, her API çağrısı ile gönderilir; burada uç nokta, istek üzerinde işlem yapmadan önce imzasını doğrulayabilir.

Asıl sır asla cihazda mevcut değildir; Aslında, uygulamanın geçerli olup olmadığı konusunda hiçbir fikre sahip değildir, kimlik doğrulama talepleri yapar ve ortaya çıkan jetondan geçer. Dolaylılıktan hoş bir fayda olarak, sırrını değiştirmek isterseniz, kullanıcıların yüklü uygulamalarını güncellemelerine gerek kalmadan bunu yapabilirsiniz.

Yani sırrınızı korumak istiyorsanız, ilk etapta uygulamanızda olmamak gitmek için oldukça iyi bir yoldur.

Eski güvenli olmayan yol:

API / Gizli anahtarı güvenli hale getirmek için 3 basit adımı izleyin ( Eski yanıt )

API anahtarını veya Gizli anahtarını korumak için Gradle'ı kullanabiliriz.

1. gradle.properties (Proje özellikleri): tuşuyla değişken oluşturun.

GoolgeAPIKey = "Your API/Secret Key"

2. build.gradle (Modül: app): build.gradle dosyasında değişken olarak aktivite veya parça olarak erişmek için ayarlayın. BuildTypes {} için aşağıdaki kodu ekleyin.

buildTypes.each {
    it.buildConfigField 'String', 'GoogleSecAPIKEY', GoolgeAPIKey
}

3. Uygulamaya ait BuildConfig ile Etkinlik / Parça'ya erişin:

BuildConfig.GoogleSecAPIKEY

Güncelleme :

Yukarıdaki çözüm, Git üzerinden yapılan açık kaynak projesinde faydalıdır. (Yorumunuz için David Rawson ve riyaz-ali'ye teşekkürler).

Matthew ve Pablo Cegarra yorumlarına göre, yukarıdaki yol güvenli değildir ve Decompiler, birinin gizli anahtarlarımızla BuildConfig'i görmesine izin verecektir.

Çözüm :

API Anahtarlarını Güvenli Hale Getirmek için NDK kullanabiliriz. Anahtarları yerel C / C ++ sınıfında saklayabilir ve Java sınıflarımızda bunlara erişebiliriz.

NDK kullanarak API anahtarlarını güvenceye almak için lütfen bu blogu takip edin .

Android'de tokenleri güvenli bir şekilde nasıl saklayacağınıza dair bir takip

App-Secret anahtarı özel tutulmalıdır - ancak uygulamayı bıraktığınızda bazı çocuklar tarafından geri alınabilir.

o adamlar için gizlemek olmaz ya kilit ProGuardkod. Bu bir refactor ve bazı ücretli obfuscators jk433g34hg3 String geri almak için birkaç bitsel operatörleri ekliyor. 3 gün çalışırsanız, hack'i 5-15 dakika daha uzatabilirsiniz :)

En iyi yol onu olduğu gibi tutmaktır, imho.

Sunucu tarafında (PC'nizde) saklasanız bile, anahtar saldırıya uğrayabilir ve yazdırılabilir. Belki bu en uzun süreyi alır mı? Her neyse, en iyi durumda birkaç dakika veya birkaç saat meselesidir.

Normal bir kullanıcı kodunuzu koda dönüştürmez.

Olası bir çözüm, uygulamanızdaki verileri kodlamak ve çalışma zamanında kod çözmeyi kullanmaktır (bu verileri kullanmak istediğinizde). Ayrıca, uygulamanızın ayrıştırılmış kaynak kodunu okumayı ve anlamayı zorlaştırmak için progaurd kullanmanızı öneririz. örneğin uygulamada kodlanmış bir anahtar koydum ve daha sonra uygulamada gizli anahtarlarımı çalışma zamanında çözmek için bir kod çözme yöntemi kullandım:

// "the real string is: "mypassword" "; 
//encoded 2 times with an algorithm or you can encode with other algorithms too
public String getClientSecret() {
    return Utils.decode(Utils
            .decode("Ylhsd1lYTnpkMjl5WkE9PQ=="));
}

Korumalı bir uygulamanın decompiled kaynak kodu şudur:

 public String c()
 {
    return com.myrpoject.mypackage.g.h.a(com.myrpoject.mypackage.g.h.a("Ylhsd1lYTnpkMjl5WkE9PQ=="));
  }

En azından benim için yeterince karmaşık. benim uygulamada bir değer saklamaktan başka seçeneğim olmadığında bunu yapıyorum. Tabii ki hepimiz biliyoruz ki bu en iyi yol değil ama benim için çalışıyor.

/**
 * @param input
 * @return decoded string
 */
public static String decode(String input) {
    // Receiving side
    String text = "";
    try {
        byte[] data = Decoder.decode(input);
        text = new String(data, "UTF-8");
        return text;
    } catch (UnsupportedEncodingException e) {
        e.printStackTrace();
    }
    return "Error";
}

Ayrıştırılmış sürüm:

 public static String a(String paramString)
  {
    try
    {
      str = new String(a.a(paramString), "UTF-8");
      return str;
    }
    catch (UnsupportedEncodingException localUnsupportedEncodingException)
    {
      while (true)
      {
        localUnsupportedEncodingException.printStackTrace();
        String str = "Error";
      }
    }
  }

Google'da küçük bir arama yaparak çok sayıda şifreleyici sınıfı bulabilirsiniz.

@Manohar Reddy çözümüne, firebase Veritabanına veya firebase RemoteConfig'e (Null varsayılan değerle) ekleme kullanılabilir:

1. Anahtarlarınızı şifreleyin
2. Firebase veritabanında saklayın
3. Uygulama başlatılırken veya gerektiğinde alın
4. anahtarları deşifre et ve kullan

Bu çözümde farklı olan nedir?

• Firebase için kredi yok
• Firebase erişimi korunur, bu nedenle yalnızca imzalı sertifikaya sahip uygulamaların API çağrıları yapma ayrıcalığı
• orta insan müdahalesini önlemek için şifreleme / deşifre etme. Ancak zaten ateş tabanına https çağırıyor

Bu örnekte bunun farklı yönleri vardır. Açıkça başka bir yerde ele alındığını düşünmediğim birkaç noktaya değineceğim.

Transit sırrı koruma

Dikkat edilmesi gereken ilk şey, dropbox API'sına uygulama kimlik doğrulama mekanizmasını kullanarak erişmenin anahtarınızı ve sırrınızı iletmenizi gerektirmesidir. Bağlantı HTTPS'dir, yani TLS sertifikasını bilmeden trafiği kesemezsiniz. Bu, bir kişinin mobil cihazdan sunucuya seyahatlerinde paketleri yakalamasını ve okumasını önlemektir. Normal kullanıcılar için trafiklerinin gizliliğini sağlamanın gerçekten iyi bir yoludur.

İyi olmayan şey, kötü niyetli bir kişinin uygulamayı indirmesini ve trafiği denetlemesini engellemektir. Bir mobil cihaza giren ve çıkan tüm trafik için ortadaki bir proxy'yi kullanmak gerçekten kolaydır. Bu durumda Dropbox API'sının doğası gereği uygulama anahtarını ve sırrını çıkarmak için kodun sökülmesi veya tersine mühendislik gerektirmez.

Sunucudan aldığınız TLS sertifikasının beklediğiniz sertifika olup olmadığını kontrol etmek için sabitleme yapabilirsiniz . Bu, istemciye bir kontrol ekler ve trafiği durdurmayı zorlaştırır. Bu, uçuştaki trafiği incelemeyi zorlaştırır, ancak sabitleme kontrolü istemcide gerçekleşir, bu nedenle sabitleme testini devre dışı bırakmak yine de mümkün olabilir. Gerçi zorlaştırıyor.

Dinlenmeden sırrı korumak

İlk adım olarak, koruma gibi bir şey kullanmak, herhangi bir sırın nerede tutulduğunu daha az belirgin hale getirmeye yardımcı olacaktır. NDK'yı, anahtarı ve sırrı saklamak ve doğrudan istekleri göndermek için de kullanabilirsiniz; bu, bilgileri ayıklamak için uygun becerilere sahip kişilerin sayısını büyük ölçüde azaltacaktır. Daha fazla gizleme, değerleri herhangi bir süre boyunca doğrudan bellekte saklamama ile elde edilebilir, bunları başka bir cevap tarafından önerildiği gibi kullanmadan hemen önce şifreleyebilir ve şifresini çözebilirsiniz.

Daha gelişmiş seçenekler

Şimdi sırrını uygulamanızın herhangi bir yerine koyma konusunda paranoyaksanız ve daha kapsamlı çözümlere yatırım yapmak için zamanınız ve paranız varsa, kimlik bilgilerinizi sunucularınızda depolamayı düşünebilirsiniz (herhangi birine sahip olduğunuzu varsayarak). Bu, sunucunuz aracılığıyla iletişim kurması gerekeceğinden API'ya yapılan tüm çağrıların gecikmesini artıracak ve veri akışının artması nedeniyle hizmetinizi yürütme maliyetlerini artırabilir.

Daha sonra, koruntuklarından emin olmak için sunucularınızla en iyi nasıl iletişim kuracağınıza karar vermelisiniz. Dahili API'nizde aynı sorunların tekrar ortaya çıkmasını önlemek için bu önemlidir. Verebileceğim en iyi kural, ortadaki adam tehdidi nedeniyle doğrudan bir sır vermemek. Bunun yerine, sırrınızı kullanarak trafiği imzalayabilir ve sunucunuza gelen tüm isteklerin bütünlüğünü doğrulayabilirsiniz. Bunu yapmanın standart bir yolu, bir sır üzerine yazılan mesajın bir HMAC'sini hesaplamaktır. Bu alanda da faaliyet gösteren bir güvenlik ürünü olan bir şirkette çalışıyorum, bu yüzden bu tür şeyler beni ilgilendiriyor. Aslında, işte meslektaşlarımdan birçoğunun üzerinden geçen bir blog makalesi.

Ne kadar yapmalıyım?

Bunun gibi herhangi bir güvenlik tavsiyesi ile, birisinin girmesi için ne kadar zor yapmak istediğinize dair bir maliyet / fayda kararı vermeniz gerekir. Milyonlarca müşteriyi koruyan bir banka iseniz bütçeniz, boş zaman. Birinin güvenliğinizi kırmasını önlemek neredeyse imkansızdır, ancak pratikte az sayıda insanın tüm çan ve ıslıklara ihtiyacı vardır ve bazı temel önlemlerle uzun bir yol elde edebilirsiniz.

En güvenli çözüm, anahtarlarınızı bir sunucuda tutmak ve o anahtara ihtiyaç duyan tüm istekleri sunucunuz üzerinden yönlendirmektir. Bu şekilde anahtar sunucunuzdan ayrılmaz, böylece sunucunuz güvenli olduğu sürece anahtarınız da öyle olur. Tabii ki bu çözüm ile bir performans maliyeti var.

Gizli tutun ve firebase databaseuygulama başladığında ondan almak, Bir web servisini aramaktan çok daha iyidir.

Gizli anahtarlarınızı korumak için ne yaparsanız yapın gerçek bir çözüm olmayacaktır. Eğer geliştirici uygulamayı koda edebiliyorsa, anahtarı güvence altına almanın bir yolu yoktur, anahtarı gizlemek sadece gizli bir güvenliktir ve kod gizlemedir. Gizli bir anahtarın güvenliğini sağlamakla ilgili sorun, güvenliğini sağlamak için başka bir anahtar kullanmanız gerektiğidir ve bu anahtarın da güvenli olması gerekir. Bir anahtarla kilitlenmiş bir kutuya gizlenmiş bir anahtarı düşünün. Bir odanın içine bir kutu yerleştiriyorsunuz ve odayı kilitliyorsunuz. Güvenceye almak için başka bir anahtar kaldı. Ve bu anahtar hala uygulamanızın içinde kodlanacaktır.

Kullanıcı PIN veya cümle girmediği sürece anahtarı gizlemenin bir yolu yoktur. Ancak bunu yapmak için, bant dışında gerçekleşen PIN'leri yönetmek için bir şemaya sahip olmanız gerekir, yani farklı bir kanaldan. Google API'ları gibi hizmetler için anahtarların güvenliğini sağlamak için kesinlikle pratik değildir.

Yaş eski yazı, ama yine de yeterince iyi. Tabii ki NDK ve C ++ kullanarak bir .so kütüphanesinde gizlemek harika olacağını düşünüyorum. .so dosyaları onaltılık düzenleyicide görüntülenebilir, ancak iyi şanslar bunu çözer: P

Bunları gizli tutmanın tek gerçek yolu onları sunucunuzda tutmak ve uygulamanın sunucuya ne olursa olsun göndermesini sağlamaktır ve sunucu Dropbox ile etkileşime girer. Bu şekilde ASLA özel anahtarınızı herhangi bir biçimde dağıtmazsınız.

Acı deneyimine dayanarak ve bir IDA-Pro uzmanına danıştıktan sonra en iyi çözüm, kodun önemli bir bölümünü bir DLL / SharedObject'e taşımak, daha sonra bir sunucudan almak ve çalışma zamanında yüklemek.

Hassas veriler, böyle bir şey yapmak çok kolay olduğu için kodlanmalıdır:

$ strings libsecretlib.so | grep My
  My_S3cr3t_P@$$W0rD