Yazılımınızın Özel API'sinde Tersine Mühendislik Eğitimi: Kanepenizi Hacking

Seyahat etmek benim tutkum ve büyük bir Couchsurfing hayranıyım. Kanepe sörfü, kalacak bir yer bulabileceğiniz veya kendi evinizi diğer gezginlerle paylaşabileceğiniz küresel bir gezgin topluluğudur. Bunun da ötesinde, Kanepe Sörfü, yerel halkla etkileşim kurarken gerçek bir seyahat deneyiminin keyfini çıkarmanıza yardımcı olur. 3 yıldan fazla bir süredir Couchsurfing topluluğunun içindeyim. Önce buluşmalara katıldım ve sonunda insanları ağırlayabildim. Ne muhteşem bir yolculuktu! Dünyanın her yerinden çok sayıda inanılmaz insanla tanıştım ve birçok arkadaş edindim. Bütün bu deneyim hayatımı gerçekten değiştirdi.

Kendim pek çok gezgini ağırladım, henüz sörf yaptığımdan çok daha fazlası. Fransız Rivierası'ndaki en önemli turistik yerlerden birinde yaşarken çok sayıda koltuk talebi aldım (yüksek sezonda günde 10'a kadar). Serbest çalışan bir arka uç geliştiricisi olarak, couchsurfing.com web sitesindeki sorunun, bu tür "yüksek yük" durumlarını gerçekten düzgün şekilde ele almaması olduğunu hemen fark ettim. Kanepenizin müsait olup olmadığı hakkında hiçbir bilgi yok - yeni bir koltuk talebi aldığınızda, o sırada zaten birini ağırlayıp ağırlamadığınızdan emin olamazsınız. Kabul edilen ve bekleyen isteklerinizin görsel bir temsili olmalıdır, böylece onları daha iyi yönetebilirsiniz. Ayrıca, koltuk müsaitlik durumunuzu herkese açık hale getirebilirseniz, gereksiz koltuk taleplerinden kaçınabilirsiniz. Ne düşündüğümü daha iyi anlamak için Airbnb takvimine bir göz atın.

Birçok şirket, kullanıcılarını dinlememekle ünlüdür. Couchsurfing'in tarihini bildiğimden, bu özelliği yakın zamanda uygulayacaklarına güvenemezdim. Web sitesi kar amacı gütmeyen bir şirket haline geldiğinden beri topluluk kötüleşti. Neden bahsettiğimi daha iyi anlamak için şu iki makaleyi okumanızı öneririm:

• http://www.nithincoca.com/2013/03/27/the-rise-and-fall-of-couchsurfing/
• http://mechanicalbrain.wordpress.com/2013/03/04/couchsurfing-a-sad-end-to-a-great-idea/

Birçok topluluk üyesinin bu işlevselliğe sahip olmaktan mutlu olacağını biliyordum. Ben de bu sorunu çözmek için bir uygulama yapmaya karar verdim. Görünen o ki, herkese açık bir Couchsurfing API'si yok. Destek ekibinden aldığım yanıt şöyle:

"Maalesef API'mizin aslında herkese açık olmadığını ve şu anda bunu herkese açık hale getirmek için bir planımız olmadığını size bildirmek zorundayız."

Kanepeme Girmek

Couchsurfing.com'a girmek için en sevdiğim yazılım tersine mühendislik tekniklerinden bazılarını kullanmanın zamanı gelmişti. Mobil uygulamalarının arka ucu sorgulamak için bir çeşit API kullanması gerektiğini varsaydım. Bu nedenle, bir mobil uygulamadan arka uca gelen HTTP isteklerini engellemek zorunda kaldım. Bu amaçla yerel ağda bir proxy kurdum ve HTTP isteklerini engellemek için iPhone'umu ona bağladım. Bu şekilde, özel API'lerinin erişim noktalarını bulabildim ve JSON yük biçimini anlayabildim.

Sonunda, insanların koltuk isteklerini yönetmelerine yardımcı olma ve sörfçülere koltuk müsaitlik takvimi gösterme amacına hizmet eden bir web sitesi oluşturdum. Topluluk forumlarında buna bir bağlantı yayınladım (bence de oldukça bölümlere ayrılmış ve orada bilgi bulmak zor). Karşılama çoğunlukla olumluydu, ancak bazı insanlar web sitesinin gerçekten bir güven meselesi olan couchsurfing.com kimlik bilgilerine ihtiyaç duyması fikrinden hoşlanmadı.

Web sitesi şu şekilde çalıştı: web sitesinde couchsurfing.com kimlik bilgilerinizle oturum açıyorsunuz ve birkaç tıklamadan sonra couchsurfing.com profilinize yerleştirebileceğiniz html kodunu alıyorsunuz ve işte - otomatik olarak güncellenen bir takviminiz var. senin profil. Aşağıda takvimin ekran görüntüsü ve işte nasıl yaptığımla ilgili makaleler:

• https://github.com/nderkach/couchsurfing-python

Kanepe Sörfü için harika bir özellik yarattım ve doğal olarak çalışmamı takdir edeceklerini varsaydım - belki de geliştirme ekiplerinde bana bir pozisyon bile teklif edebilirler. Jobs(at)couchsurfing.com'a web sitesinin bağlantısını, özgeçmişimi ve referansımı içeren bir e-posta gönderdim. Kanepede sörf yapan misafirlerimden birinin bıraktığı bir teşekkür notu:

Birkaç gün sonra tersine mühendislik çalışmalarımı takip ettiler. Cevapta, endişelendikleri tek şeyin kendi güvenlikleri olduğu açıktı, bu yüzden API hakkında yazdığım blog yazılarını ve nihayetinde web sitesini kaldırmamı istediler. Niyetim, kullanım şartlarını ihlal etmek ve kullanıcı kimlik bilgilerini araştırmak değil, kanepe sörfü topluluğuna yardım etmek olduğu için gönderileri hemen kaldırdım. Bir suçlu gibi davranıldığıma dair bir izlenim edindim ve şirket yalnızca web sitemin kullanıcı kimlik bilgileri gerektirdiği gerçeğine odaklandı.

Onlara uygulamamı ücretsiz vermeyi teklif ettim. Bunu kendi ortamlarında barındırabilir ve Facebook kimlik doğrulaması yoluyla bağlayabilirler. Sonuçta, bu harika bir özellik ve topluluğun buna ihtiyacı vardı. İşte aldığım son karar:

"Tatilden sonra burada işlerin hızına dönüyoruz ve takip etmek istedik.

Başvurunuz ve kimlik bilgilerini üçüncü taraf bir siteye girdiklerinde Kanepe Sörfü kullanıcılarının verilerinin gizliliğinden ve güvenliğinden potansiyel olarak ödün vermeden, gösterdiği yaratıcılığı ve inisiyatifi nasıl onurlandırabileceğimiz konusunda bazı şirket içi tartışmalar yaptık.

Takvim, şu anda üzerinde çalıştığımız daha büyük bir projenin parçası olan bir özellik olan sitemizdeki bir özellik boşluğunu açıkça dolduruyor.

Ancak kullanıcı adlarını ve şifreleri toplama sorunu devam ediyor. Bu verilere erişmenize izin vermeden veya sitenizi iş ürünümüz olarak görmeden kendi tarafımızda barındırabilmemiz veya destekleyebilmemiz için onu kurmanın kolay bir yolunu bulamadık.

Şu anda mevcut olan API, yakında ona erişen uygulamalardan kimlik doğrulama/yetkilendirme gerektirecek bir sürümle değiştirilecek.”

Bugün bu tersine mühendislik yazılımı eğitimini yazarken (olaylardan bir yıl sonra), Couchsurfing'de takvim özelliği hala uygulanmadı.

Masumiyete Dönüş - Kanepemi Tekrar Hacklemek

Birkaç hafta önce, özel API'lerde tersine mühendislik yapma teknikleri hakkında bir makale yazmak için ilham aldım. Doğal olarak, bu konuda daha önce yazdığım makaleleri özetlemeye ve birkaç ayrıntı daha eklemeye karar verdim. Yeni makaleyi yazmaya başladığımda, güncel bir API ile tersine mühendislik sürecini sergilemek ve API korsanlığına başka bir saplama yapmak istedim. Önceki deneyimlerime ve Couchsurfing'in yakın zamanda tamamen yeni bir web sitesi ve mobil uygulamasını duyurduğu gerçeğine dayanarak http://blog.couchsurfing.com/the-future-of-couchsurfing-is-on-the-way/ API'lerini tekrar hacklemeye karar verdi.

Neden bu tersine mühendislik işlemini yapıyorum? Her şeyden önce, genel olarak yazılımları tersine mühendislik yapmak çok eğlenceli. Bu konuda özellikle sevdiğim şey, sadece teknik becerinizi değil, aynı zamanda sezginizi de içermesi. Bazen, bir şeyleri çözmenin en iyi yolu, bilinçli bir tahminde bulunmaktır - kaba kuvvete kıyasla size çok zaman kazandırır. Geçenlerde, tescilli API'lerle ve çok az belgeyle veya hiç belgeyle çalışmak zorunda olan bir şirketten bir hikaye duydum. Günlerdir bilinmeyen bir biçimde API yanıt yükünün şifresini çözmek için uğraşıyorlardı, sonra biri url'nin sonunda ?decode=true denemeye karar verdi ve uygun bir JSON'a sahip oldular. Bazen, eğer şanslıysanız, tek yapmanız gereken JSON yanıtını güzelleştirmek.

Bu öğreticiyi yapmamın bir başka nedeni de, bazı şirketlerin kullanıcıları tarafından talep edilen belirli bir özelliği benimsemelerinin uzun zaman almasıdır. Uygulanmasını beklemek yerine, onların özel API'sinin gücünden faydalanabilir ve onu kendiniz oluşturabilirsiniz.

Böylece yeni couchsurfing.com API'si ile benzer bir yaklaşımla başladım ve en son iOS uygulamasını yükledim.

İlk olarak, bir ortadaki adam saldırısı (MITM) gerçekleştirerek uygulamadan API'ye gelen HTTP isteklerini taklit etmek için LAN'ınızda bir proxy kurmanız gerekir.

Şifrelenmemiş bağlantılar için saldırı oldukça basittir - bir istemci proxy'ye bağlanır ve gelen istekleri hedef sunucuya ileri geri iletirsiniz. Gerekirse, yükü muhtemelen değiştirebilirsiniz. Halka açık bir WLAN'da, WiFi yönlendiricinin kimliğine bürünerek bunu gizlice gerçekleştirmek oldukça kolaydır.

Şifreli bağlantılar için küçük bir fark vardır: tüm istekler uçtan uca şifrelenir. Saldırganın, bir şekilde özel anahtara (elbette bu etkileşimler sırasında gönderilmeyen) erişmediği sürece mesajın şifresini çözmesi mümkün değildir. Bununla birlikte, API iletişim kanalı güvenli olsa bile, uç noktalar - özellikle istemci - o kadar güvenli değil.

SSL'nin düzgün çalışması için aşağıdaki koşulların karşılanması gerekir:

• Sunucunun sertifikası, güvenilir bir sertifika yetkilisi (CA) ile imzalanmalıdır.
• Sunucunun sertifikadaki ortak adı, sunucunun alan adıyla eşleşmelidir

Bir MITM saldırısında şifrelemenin üstesinden gelmek için Proxy'mizin bir CA (Sertifika Yetkilisi) olarak hareket etmesi ve anında sertifikalar oluşturması gerekir. Örneğin, bir istemci www.google.com'a bağlanmaya çalışırsa, proxy dinamik olarak www.google.com için bir sertifika oluşturur ve bunu imzalar. Artık müşteri proxy'nin aslında www.google.com olduğunu düşünüyor.

Özel API'yi tersine çevirmek için kullanılan bir koklama proxy'sini uygulamak için mitmproxy adlı aracı kullanacağım. Başka herhangi bir şeffaf HTTPS proxy'si kullanabilirsiniz. Charles, güzel bir GUI'ye sahip başka bir örnektir. Bu işi yapmak için aşağıdakileri ayarlamamız gerekiyor:

Telefonunuzun WiFi bağlantısı varsayılan ağ geçidini proxy olacak şekilde yapılandırın (böylece proxy ortada olur ve tüm paketler geçer) Telefona proxy sertifikası yükleyin (böylece istemcinin güven deposunda proxy'nin genel anahtarına sahip olur)

Sertifikayı yüklemeyle ilgili olarak proxy'nizin belgelerini kontrol edin. İşte mitmproxy için talimatlar. Ve işte iOS için sertifika PEM dosyası.

Yakalanan HTTP isteklerini izlemek için mitmproxy'yi başlatmanız ve cep telefonunuzdan bağlanmanız yeterlidir (varsayılan bağlantı noktası 8080'dir).

Mobil tarayıcınızda bir web sitesi açın. Bu noktada mitmproxy'deki trafiği görebilmeniz gerekir.

Her şeyin planlandığı gibi çalıştığından emin olduktan sonra, seçtiğiniz özel API'yi keşfetmeye başlamanın zamanı geldi. Temel olarak, bu noktada uygulamayı açabilir, onunla oynayabilir ve API uç noktaları ve istek yapısı hakkında bir fikir edinebilirsiniz.

Bir yazılım API'sinin nasıl tersine mühendislik yapılacağına dair katı bir algoritma yoktur - çoğu zaman sezginize güvenir ve varsayımlarda bulunursunuz.

Benim yaklaşımım, API çağrılarını çoğaltmak ve farklı seçeneklerle oynamak. Mitmproxy'de yakaladığınız bir isteği yeniden yürütmek ve çalışıp çalışmadığını görmek iyi bir başlangıçtır (bir isteği yeniden yürütmek için 'r'ye basın). İlk adım, hangi başlıkların zorunlu olduğunu bulmaktır. Mitmproxy ile başlıklarla oynamak oldukça uygundur: düzenleme moduna girmek için 'e'ye, ardından başlıkları değiştirmek için 'h'ye basın. Kullandıkları kısayollarla vim bağımlıları kendilerini evlerinde hissedecekler. API'yi test etmek için Postman gibi tarayıcı uzantılarını da kullanabilirsiniz, ancak bunlar gereksiz başlıklar ekleme eğilimindedir, bu yüzden mitmproxy veya curl'e bağlı kalmanızı öneririm.

Mitmproxy döküm dosyasını okuyan ve bir kıvrılma dizesi oluşturan bir komut dosyası yaptım - https://Gist.github.com/nderkach/bdb31b04fb1e69fa5346

Giriş yaparken gönderilen istekle başlayalım.

 POST https://hapi.couchsurfing.com/api/v2/sessions ← 200 application/json 

Fark ettiğim ilk şey, her isteğin, her seferinde farklı olan zorunlu bir X-CS-Url-Signature başlığı içermesidir. Ayrıca bir süre sonra sunucuda bir zaman damgası denetimi olup olmadığını kontrol etmek için bir isteği yeniden oynatmaya çalıştım ve yok. Bundan sonra yapılacak şey, bu imzanın nasıl hesaplandığını bulmaktır.

Bu noktada ikiliyi tersine mühendislik yapmaya ve algoritmayı bulmaya karar verdim. Doğal olarak, iPhone için geliştirme deneyimine sahip olduğum ve elimde bir iPhone'a sahip olduğum için iPhone ipa (iPhone uygulaması teslim edilebilir) ile başlamaya karar verdim. Birinin şifresini çözmek için çıkıyor, jailbreak yapılmış bir telefona ihtiyacım var. Durmak! Çekiç süresi.

Sonra, onların da bir Android uygulaması olduğunu hatırladım. Android veya Java hakkında hiçbir şey bilmediğim için bu yaklaşımı denemekte biraz tereddüt ettim. Sonra yeni bir şeyler öğrenmek için iyi bir fırsat olacağını düşündüm. Java bayt kodunu çözerek insan tarafından okunabilir yarı kaynak kodu elde etmenin, yoğun şekilde optimize edilmiş iphone makine kodundan daha kolay olduğu ortaya çıktı.

Apk (Android uygulaması teslim edilebilir) temelde bir zip dosyasıdır. İçeriğini açmak için herhangi bir zip çıkarıcıyı kullanabilirsiniz. Bir Dalvik bayt kodu olan class.dex adlı bir dosya bulacaksınız. Dalvik, Android'de çevrilmiş Java bayt kodunu çalıştırmak için kullanılan sanal bir makinedir.

.dex dosyasını .java kaynak koduna dönüştürmek için dex2jar adlı aracı kullandım. Bu aracın çıktısı, çeşitli araçlarla derleyebileceğiniz bir jar dosyasıdır. Eclipse veya IntelliJ IDEA'da bir kavanoz bile açabilirsiniz ve tüm işi sizin için yapacaktır. Bu araçların çoğu benzer bir sonuç üretir. Çalıştırmak için tekrar derleyip derlemediğimizi gerçekten umursamıyoruz, sadece kaynak kodunu analiz etmek için kullanıyoruz.

İşte denediğim araçların bir listesi:

• FernFlower (artık IntelliJ IDEA'nın bir parçası)
• CFR
• JD-GUI
• Krakatau
• procyon

CFR ve FernFlower benim için en iyi sonucu verdi. JD-GUI, kodun bazı kritik kısımlarını çözemedi ve işe yaramazdı, diğerleri ise kalite olarak hemen hemen aynıydı. Neyse ki, Java kod kodunun karıştırılmadığı görülüyor, ancak ProGuard http://developer.android.com/tools/help/proguard.html gibi kodun gizliliğini kaldırmanıza yardımcı olacak araçlar var.

Java ayrıştırma, bu tersine mühendislik eğitiminin kapsamı değildir - bu konu hakkında yazılmış çok şey var, bu yüzden Java kodunuzu başarıyla derlediğinizi ve kodunu çözdüğünüzü varsayalım.

X-CS-Url-Signature'ı hesaplamak için kullanılan tüm ilgili kodları aşağıdaki özde birleştirdim: https://Gist.github.com/nderkach/d11540e9af322f1c1c74

İlk olarak, RetrofitHttpClient içinde bulduğum X-CS-Url-Signature bahsedenleri aradım. Belirli bir çağrı ilginç görünüyordu - EncUtils modülüne. İçine kazdıkça, HMAC SHA1 kullandıklarını fark ettim. HMAC, bir mesajın karmasını hesaplamak için bir şifreleme işlevi (bu durumda SHA1) kullanan bir mesaj doğrulama kodudur. Bütünlüğü sağlamak (yani ortadaki bir adamın isteği değiştirmesini önlemek için) ve kimlik doğrulamasını sağlamak için kullanılır.

X-CS-Url-Signature hesaplamak için iki şeye ihtiyacımız var: özel anahtar ve kodlanmış mesaj (muhtemelen bazı HTTP istek yükü ve URL varyasyonları).

 final String a2 = EncUtils.a(EncUtils.a(a, s)); final ArrayList<Header> list = new ArrayList<Header>(request.getHeaders()); list.add(new Header("X-CS-Url-Signature", a2));

Kodda a bir mesajdır ve s , a2 başlığını hesaplamak için kullanılan anahtardır ( EncUtils yapılan çift çağrı sadece bir HMAC SHA1 hex özetini hesaplar).

Anahtarı bulmak sorun değildi - ApiModule içinde düz metin olarak saklandı ve RetrofitHttpClient'in ikinci parametresini başlatmak için kullanıldı.

 RetrofitHttpClient a(OkHttpClient okHttpClient) { return new RetrofitHttpClient(okHttpClient, "v3#!R3v44y3ZsJykkb$E@CG#XreXeGCh"); }

EncUtils çağrısına bakarsak, yukarıdaki dize değişmezinin, this.b tanımlandığı durum dışında, HMAC'yi hesaplamak için bir anahtar olarak kelimesi kelimesine kullanıldığını görebiliriz. İkinci durumda, this.b , kendisine bir nokta ile eklenir.

 String s; if (this.b == null) { s = this.a; } else { s = this.a + "." + this.b; }

Şimdi, sadece koda bakarak this.b nerede ve nasıl başlatıldığı benim için net değildi (keşfedebildiğim tek şey, this.a(String b) imzalı bir yöntemde çağrıldığı, ancak kodun hiçbir yerinde bir arama bulamadım).

 public void a(final String b) { this.b = b; }

Derlemenizi ve kendinizi keşfetmenizi tavsiye ederim :)

Mesajın oldukça basit olduğunu anlamak - kodda bunun url yolunun bir birleşimi olduğunu görebilirsiniz, yani /api/v2/sessions ve (varsa) JSON yüküne sahip bir dize.

 final byte[] b = this.b(request.getUrl()); byte[] a; if (request.getBody() != null && request.getBody() instanceof JsonTypedOutput) { System.out.println("body"); // this.a(x, y) concatenates byte arrays a = this.a(b, ((JsonTypedOutput)request.getBody()).a); } else { a = b; }

Sadece koda bakarak, HMAC hesaplaması için tam algoritmayı bulmak zordu. Bu yüzden, uygulamanın tam olarak nasıl çalıştığını anlamak için uygulamayı hata ayıklama sembolleriyle yeniden oluşturmaya karar verdim. Dalvik bayt kodunu smali https://code.google.com/p/smali/ kullanarak sökmek için apktool https://code.google.com/p/android-apktool/ adlı bir araç kullandım. https://code.google.com/p/android-apktool/wiki/SmaliDebugging adresindeki kılavuzu takip ettim.

Apk'yı oluşturduktan sonra imzalayıp cihazınıza yüklemeniz gerekir. Android cihazım olmadığı için Android SDK ile gelen emülatörü kullandım. Biraz kaşıkla besleme ile, işte bunu nasıl yaparsınız:

 jarsigner -verbose -keystore ~/.android/debug.keystore -storepass android -keypass android <path_to_your_built_apk> androiddebugkey jarsigner -verify -verbose -certs <path_to_your_built_apk> zipalign -v 4 <path_to_your_built_apk> <path_to_your_output_signed_apk>

Sorunsuz çalışmasını sağlamak için SDK ile birlikte gelen yerleşik bir Android öykünücüsü ve HAXM etkinleştirilmiş bir Atom x86 sanal görüntüsü kullandım.

 tools/emulator -avd mydroid -no-boot-anim -cpu-delay 0

İşte sanal bir görüntünün nasıl kurulacağına dair güzel bir kılavuz: http://jolicode.com/blog/speed-up-your-android-emulator

HAXM'in etkinleştirildiğinden emin olmak için, emülatör başlatılırken HAX hattının çalıştığını ve emülatörün hızlı sanal modda çalıştığını gördüğünüzden emin olun.

Ardından emülatöre apk'yı yükledim ve uygulamayı çalıştırdım. Apktool kılavuzunu izleyerek, öykünücüye bağlanmak ve bazı satır kesme noktaları ayarlamak için IntelliJ IDEA uzaktan hata ayıklayıcısından yararlandım:

Uygulamayla biraz oynayarak, RetrofitHttpClient başlatmak için kullanılan özel anahtarın, bir oturum açma isteği imzasının HMAC'sini hesaplamak için kullanıldığını anlayabildim. Oturum açma POST'una yanıt olarak bir kullanıcı kimliği ve accessToken ( X-Access-Token ) alırsınız. Erişim belirteci, aşağıdaki tüm istekleri yetkilendirmek için kullanılır. Tüm oturum açma sonrası istekleri için HMAC, anahtarın orijinal özel anahtara . .<user_id> eklenerek oluşturulması dışında, oturum açma isteğiyle aynı şekilde oluşturulur.

Yetkilendirildikten sonra, uygulama aşağıdaki isteği gönderir:

 POST https://hapi.couchsurfing.com/api/v2/users/1003669205/registerDevice ← 200 application/json

Deneysel olarak çıkarabildiğim gibi, bu istek kimlik doğrulama için isteğe bağlıdır. Ne için kullanıldığını anlarsan bonus puanlar!

Kimliğiniz doğrulandıktan sonra, sizin (veya başka birinin kullanıcı profilinin) alınması için aşağıdaki gibi bir istek gönderebilirsiniz:

 GET https://hapi.couchsurfing.com/api/v2/users/1003669205 ← 200 application/json 

Ayrıntılara fazla girmedim, ancak bir profilin bir PUT isteği ile güncellendiğini fark ettim. Sadece eğlence olsun diye, aynı istekle başka bir profili güncellemeye çalıştım - yetki verilmedi, bu yüzden görünüşe göre güvenlik temelleri uygulandı.

couchsurfing.com kimlik bilgilerinizi kullanarak giriş yapmak ve kullanıcı profilinizi almak için basit bir Python betiği yazdım: https://Gist.github.com/nderkach/899281d7e6dd0d497533. İşte API için Python sarıcı: https://github.com/nderkach/couchsurfing-python pypi deposunda bulunan bir paketle (pip install couchsurfing).

Sonraki adımlar

Bu sefer API ile tam olarak ne yapacağımdan emin değilim. Kullanıcı profillerinde HTML koduna artık izin verilmiyor, bu yüzden eski soruna farklı bir yaklaşım bulmam gerekecek. Talep olursa ve kanepe sörfü.com'un çok fazla soruna neden olmayacağını varsayarak python API sarmalayıcısını geliştirmeye ve iyileştirmeye devam edeceğim. API'yi çok fazla araştırmadım ve bazı temel güvenlik açıkları için test ettim. Yeterince güvenli görünüyor, ancak web sitesinde bulunmayan verilere erişip erişemeyeceğinizi öğrenmek ilginç olurdu. Her iki durumda da, artık Windows Phone, Pebble veya akıllı kanepeniz için alternatif bir istemci oluşturmak için tersine yazılım mühendisliğimi kullanabilirsiniz.

Bir Soruyla Özetleme

Açmak istediğim bir tartışma var - neden API'nizi yayınlayıp herkese açık hale getirmiyorsunuz? API'yi hacklemeyi başaramasam bile, web sitesini kazımak yine de mümkün olurdu. Bakımı daha yavaş ve daha zor olurdu, ancak tüketicilerin bir web kazıyıcı yerine bir API kullanmasını kesinlikle tercih edeceklerdi. API'lerin kullanılabilirliği, üçüncü taraf geliştiricilerin şirketin ürününü geliştirmesine ve onun çevresinde katma değerli hizmetler oluşturmasına olanak tanır. Özel bir API yerine genel API'yi korumanın daha pahalı olacağı iddia edilebilir; ama yine de, ürününüzün üzerine topluluk oluşturma hizmetlerinizin avantajları, API bakım maliyetlerinden daha ağır basacaktır.

Üçüncü taraf istemciler tarafından özel bir API kullanımını tamamen önlemek mümkün müdür? sanmıyorum. SSL sabitlemenin kullanılması, daha önce açıklandığı gibi basit bir şeffaf proxy tekniği kullanılarak API isteklerinin koklanmasını engeller. Sonunda, ikiliyi gizleseniz bile, bazı kaynaklara ve zamana sahip motive olmuş bir bilgisayar korsanı her zaman uygulama ikili programını tersine mühendislik yapabilir ve özel anahtarı/sertifikayı alabilir. İstemci uç noktasının güvenli olduğu varsayımının doğası gereği yanlış olduğunu düşünüyorum. API istemcisi zayıf bir noktadır.

Bir şirket, bir API'yi gizli tutarak, temel olarak kullanıcılarına bir güvensizlik mesajı iletmektedir. Elbette, özel API'nizi daha da fazla korumayı deneyebilirsiniz. Ancak, kötü niyetli kullanımı önlemek için API için temel bir güvenlik uygulamayı tercih etmez misiniz; ve bunun yerine kaynaklarınızı daha iyi bir kullanıcı deneyimi sağlamak için yazılımı geliştirmeye mi odaklayacaksınız?

Couchsurfing, lütfen, üstte şeker varken API'yi açın.