Samouczek dotyczący inżynierii wstecznej prywatnego interfejsu API oprogramowania: włamywanie się na kanapę

Podróżowanie to moja pasja i jestem wielkim fanem Couchsurfingu. Couchsurfing to globalna społeczność podróżników, w której możesz znaleźć miejsce na nocleg lub dzielić swój dom z innymi podróżnikami. Ponadto Couchsurfing pozwala cieszyć się prawdziwym doświadczeniem podróżowania podczas interakcji z mieszkańcami. Ze społecznością Couchsurfing jestem związany od ponad 3 lat. Na początku brałem udział w spotkaniach, a potem w końcu mogłem gościć ludzi. Cóż to była za niesamowita podróż! Poznałem wielu niesamowitych ludzi z całego świata i poznałem wielu przyjaciół. Całe to doświadczenie naprawdę zmieniło moje życie.

Sam gościłem wielu podróżników, znacznie więcej niż dotychczas surfowałem. Mieszkając w jednym z głównych ośrodków turystycznych na Riwierze Francuskiej, otrzymałem ogromną liczbę próśb o kanapę (do 10 dziennie w sezonie). Jako niezależny back-end developer, od razu zauważyłem, że problem ze stroną couchsurfing.com polega na tym, że tak naprawdę nie radzi sobie właściwie z takimi „dużymi” przypadkami. Brak informacji o dostępności Twojej kanapy - gdy otrzymasz nową prośbę o kanapę, nie możesz być pewien, czy już kogoś gościsz w tym czasie. Powinna istnieć wizualna reprezentacja zaakceptowanych i oczekujących próśb, abyś mógł lepiej nimi zarządzać. Ponadto, jeśli możesz upublicznić dostępność swojej kanapy, możesz uniknąć niepotrzebnych próśb o kanapę. Aby lepiej zrozumieć, co mam na myśli, spójrz na kalendarz Airbnb.

Wiele firm jest znanych z tego, że nie słucha swoich użytkowników. Znając historię Couchsurfingu, nie mogłem liczyć na to, że w najbliższym czasie wdrożą tę funkcję. Odkąd strona stała się firmą nastawioną na zysk, społeczność podupadła. Aby lepiej zrozumieć, o czym mówię, proponuję przeczytać te dwa artykuły:

• 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/

Wiedziałem, że wielu członków społeczności ucieszy się z tej funkcjonalności. Postanowiłem więc stworzyć aplikację, która rozwiąże ten problem. Okazuje się, że nie ma publicznego interfejsu Couchsurfing API. Oto odpowiedź, którą otrzymałem od ich zespołu wsparcia:

„Niestety musimy Cię poinformować, że nasze API nie jest w rzeczywistości publiczne i nie planujemy w tej chwili upublicznić go.”

Włamanie się na moją kanapę

Nadszedł czas, aby użyć moich ulubionych technik inżynierii wstecznej oprogramowania, aby włamać się do Couchsurfing.com. Założyłem, że ich aplikacje mobilne muszą używać jakiegoś API do wysyłania zapytań do backendu. Musiałem więc przechwycić żądania HTTP przychodzące z aplikacji mobilnej do zaplecza. W tym celu ustawiłem proxy w sieci lokalnej i podłączyłem do niego mojego iPhone'a, aby przechwytywać żądania HTTP. W ten sposób udało mi się znaleźć punkty dostępu ich prywatnego API i ustalić ich format ładunku JSON.

W końcu stworzyłem stronę internetową, która ma na celu pomóc ludziom zarządzać ich prośbami o kanapę i pokazać internautom kalendarz dostępności kanapy. Link do niego opublikowałem na forach społecznościowych (które również są moim zdaniem dość podzielone i trudno tam znaleźć informacje). Odbiór był w większości pozytywny, choć niektórym nie podobał się pomysł, że strona wymaga poświadczeń couchsurfing.com, co było kwestią zaufania.

Strona działała w ten sposób: logujesz się do serwisu za pomocą swoich danych logowania do couchsurfing.com, a po kilku kliknięciach otrzymujesz kod html, który możesz osadzić w swoim profilu couchsurfing.com i voila - masz automatycznie aktualizowany kalendarz w Twój profil. Poniżej zrzut ekranu kalendarza, a tutaj artykuły o tym, jak to zrobiłem:

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

Stworzyłem świetną funkcję dla Couchsurfing i naturalnie założyłem, że docenią moją pracę - może nawet zaoferują mi stanowisko w swoim zespole programistycznym. Wysłałem e-mail na adres jobs(at)couchsurfing.com z linkiem do strony, moim CV i referencją. Podziękowanie pozostawione przez jednego z moich gości na couchsurfingu:

Kilka dni później kontynuowali moje wysiłki w zakresie inżynierii wstecznej. W odpowiedzi było jasne, że jedyną rzeczą, o którą się martwili, było ich własne bezpieczeństwo, więc poprosili mnie o usunięcie wpisów na blogu, które napisałem na temat API, a ostatecznie strony internetowej. Natychmiast usunąłem posty, ponieważ moim zamiarem nie było naruszanie warunków użytkowania i szukanie danych uwierzytelniających użytkownika, ale raczej pomoc społeczności couchsurfingowej. Odniosłem wrażenie, że zostałem potraktowany jak przestępca, a firma skupiła się wyłącznie na tym, że moja strona wymaga danych uwierzytelniających użytkownika.

Zaproponowałem, że udostępnię im moją aplikację za darmo. Mogliby go hostować w swoim środowisku i połączyć za pomocą uwierzytelniania na Facebooku. W końcu jest to świetna funkcja i społeczność jej potrzebowała. Oto ostateczna rezolucja, którą otrzymałem:

„Po wakacjach wracamy do huśtawki i chcieliśmy kontynuować.

Odbyliśmy wewnętrzną dyskusję na temat Twojej aplikacji i sposobu, w jaki możemy zarówno uhonorować jej kreatywność, jak i inicjatywę, nie narażając jednocześnie prywatności i bezpieczeństwa danych użytkowników Couchsurfing, gdy wprowadzają oni swoje dane uwierzytelniające na stronie innej firmy.

Kalendarz wyraźnie wypełnia lukę w naszej witrynie, funkcję, która jest częścią większego projektu, nad którym teraz pracujemy.

Ale kwestia zbierania nazw użytkowników i haseł pozostaje. Nie mogliśmy wymyślić łatwego sposobu na skonfigurowanie go, abyśmy mogli hostować lub wspierać to po naszej stronie, bez umożliwiania dostępu do tych danych lub postrzegania witryny jako naszego produktu pracy.

Obecnie dostępny interfejs API zostanie wkrótce zastąpiony wersją, która będzie wymagać uwierzytelnienia/autoryzacji aplikacji, które mają do niego dostęp”.

Dzisiaj, kiedy piszę ten samouczek dotyczący inżynierii wstecznej (rok po wydarzeniach), funkcja kalendarza wciąż nie jest zaimplementowana w Couchsurfingu.

Powrót do niewinności – znowu hakowanie mojej kanapy

Kilka tygodni temu zainspirowało mnie napisanie artykułu o technikach inżynierii wstecznej prywatnych API. Oczywiście postanowiłem podsumować poprzednie artykuły, które napisałem na ten temat i dodać kilka dodatkowych szczegółów. Kiedy zacząłem pisać nowy artykuł, chciałem pokazać proces inżynierii wstecznej z aktualnym API i wziąć kolejny skrót do hackowania API. Opierając się na moich wcześniejszych doświadczeniach oraz na fakcie, że Couchsurfing ogłosił niedawno zupełnie nową aplikację internetową i mobilną http://blog.couchsurfing.com/the-future-of-couchsurfing-is-on-the-way/, postanowił ponownie zhakować ich API.

Dlaczego przeprowadzam ten proces inżynierii odwrotnej? Cóż, po pierwsze, ogólnie rzecz biorąc, inżynieria wsteczna oprogramowania jest świetną zabawą. Szczególnie podoba mi się w nim to, że dotyczy nie tylko umiejętności technicznych, ale także intuicji. Czasami najlepszym sposobem, aby to rozgryźć, jest zgadywanie na podstawie wiedzy — zaoszczędzi to dużo czasu w porównaniu z brutalną siłą. Ostatnio usłyszałem historię od firmy, która musiała pracować z zastrzeżonymi API i niewielką lub żadną dokumentacją. Od kilku dni zmagali się z odszyfrowaniem ładunku odpowiedzi API w nieznanym formacie, a potem ktoś zdecydował się wypróbować ?decode=true na końcu adresu URL i mieli poprawny JSON. Czasami, jeśli masz szczęście, wszystko, co musisz zrobić, to upiększyć odpowiedź JSON.

Innym powodem, dla którego robię ten samouczek, jest to, że niektóre firmy potrzebują wieków, aby zaadaptować konkretną funkcję, o którą prosili ich użytkownicy. Zamiast czekać na wdrożenie, możesz wykorzystać moc ich prywatnego API i zbudować go samodzielnie.

Dzięki nowemu interfejsowi API couchsurfing.com zacząłem od podobnego podejścia i zainstalowałem ich najnowszą aplikację na iOS.

Najpierw musisz skonfigurować serwer proxy w swojej sieci LAN, aby fałszować żądania HTTP przychodzące z aplikacji do interfejsu API, wykonując atak typu „man-in-the-middle” (MITM).

W przypadku połączeń nieszyfrowanych atak jest dość prosty — klient łączy się z serwerem proxy, a ty przekazujesz przychodzące żądania do serwera docelowego tam iz powrotem. W razie potrzeby możesz ewentualnie zmodyfikować ładunek. W publicznej sieci WLAN dość łatwo jest to zrobić pod przykrywką, podszywając się pod router WiFi.

W przypadku połączeń szyfrowanych istnieje niewielka różnica: wszystkie żądania są szyfrowane od końca do końca. atakujący nie może odszyfrować wiadomości, chyba że w jakiś sposób uzyska dostęp do klucza prywatnego (który oczywiście nie jest wysyłany podczas tych interakcji). Powiedziawszy to, mimo że kanał komunikacji API jest bezpieczny, punkty końcowe - zwłaszcza klient - nie są tak bezpieczne.

Aby SSL działał poprawnie, muszą być spełnione następujące warunki:

• Certyfikat serwera musi być podpisany przez zaufany urząd certyfikacji (CA)
• Nazwa zwyczajowa serwera w certyfikacie musi być zgodna z nazwą domeny serwera

Aby przezwyciężyć szyfrowanie w ataku MITM, nasz Proxy musi działać jako CA (Certificate Authority) i generować certyfikaty w locie. Na przykład, jeśli klient próbuje połączyć się z www.google.com, proxy dynamicznie tworzy certyfikat dla www.google.com i podpisuje go. Teraz klient myśli, że serwer proxy to w rzeczywistości www.google.com

Aby zaimplementować sniffing proxy używane do inżynierii wstecznej prywatnego API, użyję narzędzia o nazwie mitmproxy. Możesz użyć dowolnego innego przezroczystego proxy HTTPS. Charles to kolejny przykład z ładnym GUI. Aby to zadziałało, musimy skonfigurować następujące rzeczy:

Skonfiguruj domyślną bramę połączenia Wi-Fi telefonu jako proxy (aby proxy znajdowało się w środku i wszystkie pakiety przechodziły) Zainstaluj certyfikat proxy w telefonie (aby klient miał klucz publiczny proxy w swoim magazynie zaufania)

Sprawdź dokumentację serwera proxy dotyczącą instalowania certyfikatu. Oto instrukcje dotyczące mitmproxy. A oto plik certyfikatu PEM dla iOS.

Aby monitorować przechwycone żądania HTTP, wystarczy uruchomić mitmproxy i połączyć się z nim z telefonu komórkowego (domyślny port to 8080).

Otwórz stronę internetową w przeglądarce mobilnej. W tym momencie powinieneś być w stanie zobaczyć ruch w mitmproxy.

Gdy upewnisz się, że wszystko działa zgodnie z planem, nadszedł czas, aby rozpocząć odkrywanie wybranego prywatnego interfejsu API. Zasadniczo w tym momencie możesz po prostu otworzyć aplikację, pobawić się nią i zorientować się w punktach końcowych API i strukturze żądań.

Nie ma ścisłego algorytmu, w jaki sposób odtworzyć oprogramowanie API — w większości przypadków polegasz na swojej intuicji i robisz założenia.

Moje podejście polega na replikowaniu wywołań API i zabawie różnymi opcjami. Dobrym początkiem jest powtórzenie żądania złapanego w mitmproxy i sprawdzenie, czy działa (naciśnij „r”, aby odtworzyć żądanie). Pierwszym krokiem jest ustalenie, które nagłówki są obowiązkowe. Zabawa z nagłówkami za pomocą mitmproxy jest całkiem wygodna: naciśnij 'e', ​​aby przejść do trybu edycji, a następnie 'h', aby zmodyfikować nagłówki. Dzięki skrótom, których używają, uzależnieni od vimów poczują się jak w domu. Możesz także użyć rozszerzeń przeglądarki, takich jak Postman, aby przetestować API, ale mają tendencję do dodawania niepotrzebnych nagłówków, więc sugeruję trzymać się mitmproxy lub curl.

Zrobiłem skrypt, który odczytuje plik zrzutu mitmproxy i generuje ciąg curl - https://gist.github.com/nderkach/bdb31b04fb1e69fa5346

Zacznijmy od prośby wysłanej podczas logowania.

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

Pierwszą rzeczą, jaką zauważyłem, jest to, że każde żądanie zawiera obowiązkowy nagłówek X-CS-Url-Signature , który za każdym razem jest inny. Próbowałem też odtworzyć żądanie po pewnym czasie, aby sprawdzić, czy na serwerze jest sprawdzanie znacznika czasu, a nie ma. Następną rzeczą do zrobienia jest ustalenie, jak obliczany jest ten podpis.

W tym momencie postanowiłem dokonać inżynierii wstecznej kodu binarnego i opracować algorytm. Oczywiście, mając doświadczenie w programowaniu na iPhone'a i mając do dyspozycji iPhone'a, postanowiłem zacząć od iPhone'a ipa (dostarczalna aplikacja na iPhone'a). Okazuje się, że odszyfruję jeden, potrzebuję zepsutego telefonu. Zatrzymać! Czas młota.

Potem przypomniałem sobie, że mają też aplikację na Androida. Byłem trochę niezdecydowany, aby spróbować tego podejścia, ponieważ nie wiem nic o Androidzie ani Javie. Pomyślałem wtedy, że to dobra okazja, aby nauczyć się czegoś nowego. Okazało się, że łatwiej jest uzyskać czytelny dla człowieka quasi kod źródłowy przez dekompilację kodu bajtowego java niż mocno zoptymalizowany kod maszynowy iPhone'a.

Apk (dostarczana aplikacja na Androida) to w zasadzie plik zip. Do rozpakowania jego zawartości możesz użyć dowolnego wyciągacza zamka. Znajdziesz plik o nazwie class.dex, który jest kodem bajtowym Dalvik. Dalvik to maszyna wirtualna używana do uruchamiania przetłumaczonego kodu bajtowego Java na Androidzie.

Do dekompilacji pliku .dex do kodu źródłowego .java użyłem narzędzia o nazwie dex2jar. Wynikiem tego narzędzia jest plik jar, który można zdekompilować za pomocą różnych narzędzi. Możesz nawet otworzyć słoik w Eclipse lub IntelliJ IDEA i zrobi to za Ciebie. Większość z tych narzędzi daje podobny rezultat. Nie obchodzi nas, czy możemy go z powrotem skompilować, aby go uruchomić, używamy go jedynie do analizy kodu źródłowego.

Oto lista narzędzi, które wypróbowałem:

• FernFlower (obecnie część IntelliJ IDEA)
• CFR
• JD-GUI
• Krakatau
• Procjon

CFR i FernFlower działały dla mnie najlepiej. JD-GUI nie był w stanie zdekompilować niektórych krytycznych części kodu i był bezużyteczny, podczas gdy inne były mniej więcej tej samej jakości. Na szczęście wygląda na to, że kod Java nie został zaciemniony, ale istnieją narzędzia, takie jak ProGuard http://developer.android.com/tools/help/proguard.html, które pomogą Ci odciemnić kod.

Dekompilacja Javy tak naprawdę nie jest tematem tego samouczka dotyczącego inżynierii wstecznej - na ten temat napisano wiele, więc załóżmy, że pomyślnie zdekompilowałeś i odszyfrowałeś kod Javy.

Połączyłem cały odpowiedni kod używany do obliczenia X-CS-Url-Signature w następującym skrócie: https://gist.github.com/nderkach/d11540e9af322f1c1c74

Najpierw szukałem wzmianek o X-CS-Url-Signature , które znalazłem w RetrofitHttpClient . Jedna konkretna rozmowa wydawała się interesująca - do modułu EncUtils . Zagłębiając się w to, zdałem sobie sprawę, że używają HMAC SHA1. HMAC to kod uwierzytelniania wiadomości, który wykorzystuje funkcję kryptograficzną (w tym przypadku SHA1) do obliczenia skrótu wiadomości. Służy do zapewnienia integralności (tj. uniemożliwienia pośrednikowi modyfikacji żądania) i uwierzytelnienia.

Do obliczenia X-CS-Url-Signature potrzebujemy dwóch rzeczy: klucza prywatnego i zaszyfrowanej wiadomości (prawdopodobnie jakaś odmiana ładunku żądania HTTP i adresu URL).

 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));

W kodzie a jest wiadomością, a s jest kluczem używanym do obliczenia nagłówka a2 (podwójne wywołanie EncUtils po prostu oblicza skrót szesnastkowy HMAC SHA1).

Znalezienie klucza nie stanowiło problemu - był przechowywany w postaci zwykłego tekstu w ApiModule i służył do inicjalizacji drugiego parametru RetrofitHttpClient.

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

Jeśli spojrzymy na wywołanie EncUtils , zobaczymy, że powyższy literał ciągu jest używany dosłownie jako klucz do obliczenia HMAC, z wyjątkiem przypadku, gdy zdefiniowano this.b W tym drugim przypadku do this.b jest kropka.

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

Teraz, patrząc na kod, nie było dla mnie jasne, gdzie i jak this.b jest inicjowany (jedyne, co udało mi się odkryć, to to, że jest on wywoływany w metodzie z sygnaturą this.a(String b) , ale nie mogłem znaleźć wywołania do niego nigdzie w kodzie).

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

Zachęcam do dekompilacji i przekonaj się sam :)

Ustalenie wiadomości było dość proste - w kodzie widać, że jest to połączenie ścieżki url, tj. /api/v2/sessions i łańcucha z ładunkiem JSON (jeśli istnieje).

 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; }

Tylko patrząc na kod, trudno było ustalić dokładny algorytm obliczeń HMAC. Postanowiłem więc przebudować aplikację za pomocą symboli debugowania, aby dokładnie dowiedzieć się, jak działa aplikacja. Użyłem narzędzia o nazwie apktool https://code.google.com/p/android-apktool/ do rozłożenia kodu bajtowego Dalvik za pomocą smali https://code.google.com/p/smali/. Postępowałem zgodnie z przewodnikiem na https://code.google.com/p/android-apktool/wiki/SmaliDebugging

Po zbudowaniu apk musisz podpisać i zainstalować go na swoim urządzeniu. Ponieważ nie miałem urządzenia z Androidem, użyłem emulatora, który jest dostarczany z Android SDK. Przy odrobinie karmienia łyżeczką, oto jak to zrobić:

 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>

Użyłem wbudowanego emulatora Androida, który jest dostarczany z sdk i wirtualnym obrazem Atom x86 z włączonym HAXM, aby zapewnić płynne działanie.

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

Oto dobry przewodnik, jak skonfigurować wirtualny obraz: http://jolicode.com/blog/speed-up-your-android-emulator

Upewnij się, że widzisz wiersz HAX działa, a emulator działa w trybie szybkiego wirtualizacji podczas uruchamiania emulatora, aby upewnić się, że masz włączoną HAXM.

Następnie zainstalowałem apk w emulatorze i uruchomiłem aplikację. Postępując zgodnie z przewodnikiem apktool, wykorzystałem zdalny debugger IntelliJ IDEA, aby połączyć się z emulatorem i ustawić kilka punktów przerwania linii:

Bawiąc się trochę z aplikacją, udało mi się dowiedzieć, że klucz prywatny używany do inicjalizacji RetrofitHttpClient służy do obliczania HMAC sygnatury żądania logowania. W odpowiedzi na POST logowania otrzymasz identyfikator użytkownika i accessToken ( X-Access-Token ). Token dostępu służy do autoryzacji wszystkich następujących żądań. HMAC dla wszystkich żądań po zalogowaniu jest skonstruowany w taki sam sposób jak żądanie logowania, z wyjątkiem tego, że klucz składa się z dodania .<user_id> do oryginalnego klucza prywatnego.

Po uzyskaniu autoryzacji aplikacja wysyła następujące żądanie:

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

Jak udało mi się empirycznie wywnioskować, to żądanie jest opcjonalne dla uwierzytelnienia. Dodatkowe punkty, jeśli dowiesz się, do czego służy!

Po uwierzytelnieniu możesz wysłać prośbę o pobranie swojego (lub innego profilu użytkownika), w następujący sposób:

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

Nie zagłębiałem się zbytnio w szczegóły, ale zauważyłem, że profil jest aktualizowany żądaniem PUT. Dla zabawy spróbowałem zaktualizować inny profil tym samym żądaniem - nie był autoryzowany, więc najwyraźniej zaimplementowano podstawy bezpieczeństwa.

Napisałem prosty skrypt w Pythonie, aby zalogować się przy użyciu swoich danych logowania do couchsurfing.com i uzyskać swój profil użytkownika: https://gist.github.com/nderkach/899281d7e6dd0d497533. Oto wrapper Pythona dla API: https://github.com/nderkach/couchsurfing-python z pakietem dostępnym w repozytorium pypi (pip install couchsurfing).

Następne kroki

Nie jestem pewien, co konkretnie zamierzam tym razem zrobić z API. Kod HTML w profilach użytkowników nie jest już dozwolony, więc będę musiał wymyślić inne podejście do starego problemu. Będę dalej rozwijał i ulepszał wrapper API Pythona, jeśli będzie na to zapotrzebowanie i zakładając, że couchsurfing.com nie spowoduje zbyt wielu problemów. Nie eksplorowałem interfejsu API zbyt wiele, a po prostu przetestowałem go pod kątem kilku podstawowych luk. Wydaje się, że jest wystarczająco bezpieczny, ale ciekawie byłoby dowiedzieć się, czy możesz uzyskać dostęp do danych, które nie są dostępne za pośrednictwem strony internetowej. Tak czy inaczej, teraz możesz wykorzystać moją inżynierię oprogramowania wstecznego do zbudowania alternatywnego klienta dla Windows Phone, Pebble lub inteligentnej kanapy.

Podsumowanie z pytaniem

Jest dyskusja, którą chciałbym rozpocząć - dlaczego nie opublikować swojego API i upublicznić? Nawet gdybym nie zdołał zhakować API, to i tak byłoby możliwe zeskrobać stronę. Byłby wolniejszy i trudniejszy w utrzymaniu, ale z pewnością woleliby, aby konsumenci korzystali z API zamiast z web scrapera. Dostępność interfejsów API pozwoliłaby zewnętrznym deweloperom ulepszać produkt firmy i budować wokół niego usługę o wartości dodanej. Można argumentować, że utrzymanie publicznego API byłoby droższe niż prywatnego; ale z drugiej strony zalety usług budowania społeczności w dodatku do produktu przewyższają koszty utrzymania interfejsu API.

Czy można całkowicie uniemożliwić korzystanie z prywatnego API przez klientów zewnętrznych? Nie sądzę. Używanie przypinania SSL zapobiegłoby sniffowaniu żądań API przy użyciu prostej, przezroczystej techniki proxy, jak opisano wcześniej. W końcu, nawet jeśli zaciemnisz plik binarny, zmotywowany haker z pewnymi zasobami i czasem zawsze będzie w stanie odtworzyć plik binarny aplikacji i uzyskać klucz prywatny/certyfikat. Myślę, że założenie, że punkt końcowy klienta jest bezpieczny, jest z natury błędne. Klient API to słaby punkt.

Utrzymując prywatność API, firma zasadniczo przekazuje swoim użytkownikom komunikat o nieufności. Z pewnością możesz spróbować jeszcze bardziej chronić swój prywatny interfejs API. Jednak czy nie wolałbyś zaimplementować podstawowych zabezpieczeń dla API, aby zapobiec złośliwemu użyciu; i zamiast tego skoncentruj swoje zasoby na ulepszaniu oprogramowania, aby zapewnić lepsze wrażenia użytkownika?

Couchsurfing, proszę bardzo, z cukrem na wierzchu, otwórz API.