Tutorial untuk Rekayasa Terbalik API Pribadi Perangkat Lunak Anda: Meretas Sofa Anda

Bepergian adalah hasrat saya, dan saya penggemar berat Couchsurfing. Couchsurfing adalah komunitas pelancong global, di mana Anda dapat menemukan tempat tinggal atau berbagi rumah sendiri dengan pelancong lain. Selain itu, Couchsurfing membantu Anda menikmati pengalaman perjalanan yang sesungguhnya sambil berinteraksi dengan penduduk setempat. Saya telah terlibat dengan komunitas Couchsurfing selama lebih dari 3 tahun. Saya menghadiri pertemuan pada awalnya, dan kemudian saya akhirnya bisa menjadi tuan rumah bagi orang-orang. Sungguh perjalanan yang luar biasa! Saya telah bertemu begitu banyak orang luar biasa dari seluruh dunia dan mendapatkan banyak teman. Seluruh pengalaman ini benar-benar mengubah hidup saya.

Saya sendiri telah menjamu banyak pelancong, jauh lebih banyak daripada yang sebenarnya saya jelajahi. Saat tinggal di salah satu tujuan wisata utama di French Riviera, saya menerima banyak sekali permintaan sofa (hingga 10 per hari selama musim ramai). Sebagai pengembang back-end lepas, saya segera menyadari bahwa masalah dengan situs web couchsurfing.com adalah tidak benar-benar menangani kasus "beban tinggi" seperti itu dengan benar. Tidak ada informasi tentang ketersediaan sofa Anda - ketika Anda menerima permintaan sofa baru, Anda tidak dapat memastikan apakah Anda sudah menerima seseorang pada saat itu. Harus ada representasi visual dari permintaan Anda yang diterima dan menunggu keputusan, sehingga Anda dapat mengelolanya dengan lebih baik. Juga, jika Anda dapat membuat ketersediaan sofa Anda menjadi publik, Anda dapat menghindari permintaan sofa yang tidak perlu. Untuk lebih memahami apa yang saya pikirkan, lihat kalender Airbnb.

Banyak perusahaan terkenal karena tidak mendengarkan penggunanya. Mengetahui sejarah Couchsurfing, saya tidak dapat mengandalkan mereka untuk mengimplementasikan fitur ini dalam waktu dekat. Sejak situs web menjadi perusahaan nirlaba, komunitas memburuk. Untuk lebih memahami apa yang saya bicarakan, saya sarankan membaca dua artikel ini:

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

Saya tahu bahwa banyak anggota komunitas akan senang memiliki fungsi ini. Jadi, saya memutuskan untuk membuat aplikasi untuk mengatasi masalah ini. Ternyata tidak ada Couchsurfing API publik yang tersedia. Berikut adalah tanggapan yang saya terima dari tim dukungan mereka:

“Sayangnya kami harus memberi tahu Anda bahwa API kami sebenarnya tidak bersifat publik dan saat ini tidak ada rencana untuk mempublikasikannya.”

Mendobrak Sofaku

Sudah waktunya untuk menggunakan beberapa teknik rekayasa balik perangkat lunak favorit saya untuk masuk ke Couchsurfing.com. Saya berasumsi bahwa aplikasi seluler mereka harus menggunakan semacam API untuk menanyakan backend. Jadi, saya harus mencegat permintaan HTTP yang datang dari aplikasi seluler ke backend. Untuk tujuan itu saya menyiapkan proxy di jaringan lokal, dan menghubungkan iPhone saya ke sana untuk mencegat permintaan HTTP. Dengan cara ini, saya dapat menemukan titik akses API pribadi mereka dan mengetahui format muatan JSON mereka.

Akhirnya saya membuat situs web yang bertujuan membantu orang mengelola permintaan sofa mereka, dan menunjukkan kepada peselancar kalender ketersediaan sofa. Saya menerbitkan tautannya di forum komunitas (yang menurut saya juga cukup tersegmentasi, dan sulit untuk menemukan informasi di sana). Penerimaan sebagian besar positif, meskipun beberapa orang tidak menyukai gagasan bahwa situs web memerlukan kredensial couchsurfing.com, yang sebenarnya merupakan masalah kepercayaan.

Situs web bekerja seperti ini: Anda masuk ke situs web dengan kredensial couchsurfing.com Anda, dan setelah beberapa klik Anda mendapatkan kode html yang dapat Anda sematkan ke profil couchsurfing.com Anda, dan voila - Anda memiliki kalender yang diperbarui secara otomatis di Profil kamu. Di bawah ini adalah tangkapan layar kalender dan di sini artikel tentang cara saya membuatnya:

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

Saya telah membuat fitur hebat untuk Couchsurfing, dan secara alami saya berasumsi bahwa mereka akan menghargai pekerjaan saya - bahkan mungkin menawarkan saya posisi di tim pengembangan mereka. Saya telah mengirim email ke jobs(at)couchsurfing.com dengan tautan ke situs web, resume saya, dan referensi. Catatan terima kasih yang ditinggalkan oleh salah satu tamu couchsurfing saya:

Beberapa hari kemudian mereka menindaklanjuti upaya rekayasa balik saya. Dalam balasan itu jelas bahwa satu-satunya hal yang mereka khawatirkan adalah keamanan mereka sendiri, jadi mereka meminta saya untuk menghapus posting blog yang saya tulis tentang API, dan akhirnya situs web. Saya segera menghapus postingan, karena niat saya bukan untuk melanggar persyaratan penggunaan dan mencari kredensial pengguna, melainkan untuk membantu komunitas couchsurfing. Saya mendapat kesan bahwa saya diperlakukan sebagai penjahat, dan perusahaan hanya berfokus pada fakta bahwa situs web saya memerlukan kredensial pengguna.

Saya mengusulkan untuk memberi mereka aplikasi saya secara gratis. Mereka dapat meng-host-nya di lingkungan mereka dan menghubungkannya melalui otentikasi Facebook. Bagaimanapun, ini adalah fitur yang hebat, dan komunitas membutuhkannya. Berikut adalah resolusi akhir yang saya terima:

“Kami kembali ke ayunan di sini setelah liburan dan ingin menindaklanjuti.

Kami telah melakukan beberapa diskusi internal tentang aplikasi Anda dan bagaimana kami dapat menghormati kreativitas dan inisiatif yang ditunjukkannya sementara tidak berpotensi membahayakan privasi dan keamanan data pengguna Couchsurfing ketika mereka memasukkan kredensial mereka ke situs pihak ketiga.

Kalender dengan jelas mengisi lubang fitur di situs kami, fitur yang merupakan bagian dari proyek yang lebih besar yang sedang kami kerjakan sekarang.

Tetapi masalah mengumpulkan nama pengguna dan kata sandi tetap ada. Kami tidak dapat menemukan cara mudah untuk menyiapkannya sehingga kami dapat meng-host atau mendukungnya di pihak kami tanpa mengizinkan Anda mengakses data itu atau membuat situs Anda dilihat sebagai produk kerja kami.

API yang saat ini tersedia akan segera diganti dengan versi yang memerlukan otentikasi/otorisasi dari aplikasi yang mengaksesnya.”

Hari ini saat saya menulis tutorial perangkat lunak rekayasa terbalik ini (setahun setelah peristiwa), fitur kalender masih belum diterapkan di Couchsurfing.

Return To Innocence - Meretas Sofa Saya, Lagi

Beberapa minggu yang lalu saya terinspirasi untuk menulis artikel tentang teknik untuk merekayasa balik API pribadi. Secara alami, saya memutuskan untuk meringkas artikel sebelumnya yang saya tulis tentang topik ini, dan menambahkan beberapa detail lagi. Saat saya mulai menulis artikel baru, saya ingin menunjukkan proses rekayasa balik dengan API terbaru dan mengambil rintisan lain ke dalam peretasan API. Berdasarkan pengalaman saya sebelumnya, dan fakta bahwa Couchsurfing baru-baru ini mengumumkan situs web dan aplikasi seluler yang benar-benar baru http://blog.couchsurfing.com/the-future-of-couchsurfing-is-on-the-way/, saya telah memutuskan untuk meretas API mereka lagi.

Mengapa saya melakukan proses reverse engineering ini? Yah, pertama-tama sangat menyenangkan untuk merekayasa balik perangkat lunak secara umum. Apa yang saya sangat suka tentang itu, adalah bahwa itu tidak hanya melibatkan keterampilan teknis Anda, tetapi juga intuisi Anda. Terkadang, cara terbaik untuk mencari tahu adalah dengan membuat tebakan yang cerdas - ini akan menghemat banyak waktu Anda dibandingkan dengan kekerasan. Baru-baru ini saya mendengar cerita dari sebuah perusahaan yang harus bekerja dengan API berpemilik dan sedikit atau tanpa dokumentasi. Mereka telah berjuang untuk mendekripsi muatan respons API dalam format yang tidak diketahui selama berhari-hari, kemudian seseorang memutuskan untuk mencoba ?decode=true di akhir url dan mereka memiliki JSON yang tepat. Terkadang, jika Anda beruntung, yang perlu Anda lakukan hanyalah mempercantik respons JSON.

Alasan lain saya melakukan tutorial ini adalah karena beberapa perusahaan membutuhkan waktu lama untuk mengadopsi fitur tertentu yang diminta oleh penggunanya. Daripada menunggu untuk diimplementasikan, Anda dapat memanfaatkan kekuatan API pribadi mereka dan membangunnya sendiri.

Jadi, dengan API couchsurfing.com baru, saya memulai dengan pendekatan serupa dan saya menginstal aplikasi iOS terbaru mereka.

Pertama, Anda perlu menyiapkan proxy di LAN Anda untuk memalsukan permintaan HTTP yang datang dari aplikasi ke API dengan melakukan serangan man-in-the-middle (MITM).

Untuk koneksi yang tidak terenkripsi, serangannya cukup sederhana - klien terhubung ke proxy dan Anda menyampaikan permintaan masuk ke server tujuan bolak-balik. Anda mungkin dapat memodifikasi payload, jika perlu. Di WLAN publik, cukup mudah untuk melakukan ini dengan menyamar dengan meniru router WiFi.

Untuk koneksi terenkripsi, ada perbedaan kecil: semua permintaan dienkripsi ujung-ke-ujung. penyerang tidak mungkin mendekripsi pesan, kecuali jika dia mendapatkan akses ke kunci pribadi (yang tentu saja tidak dikirim selama interaksi ini). Karena itu, meskipun saluran komunikasi API aman, titik akhir - terutama klien - tidak begitu aman.

Kondisi berikut harus dipenuhi agar SSL berfungsi dengan baik:

• Sertifikat server harus ditandatangani dengan otoritas sertifikat tepercaya (CA)
• Nama umum server, dalam sertifikat, harus cocok dengan nama domain server

Untuk mengatasi enkripsi dalam serangan MITM, Proxy kami perlu bertindak sebagai CA (Certificate Authority) dan menghasilkan sertifikat dengan cepat. Misalnya jika klien mencoba menyambung ke www.google.com, proxy secara dinamis membuat sertifikat untuk www.google.com dan menandatanganinya. Sekarang, klien berpikir bahwa proxy tersebut sebenarnya adalah www.google.com

Untuk mengimplementasikan proxy sniffing yang digunakan untuk merekayasa balik API pribadi, saya akan menggunakan alat yang disebut mitmproxy. Anda dapat menggunakan proxy HTTPS transparan lainnya. Charles adalah contoh lain dengan GUI yang bagus. Untuk membuat ini berfungsi, kita perlu menyiapkan hal-hal berikut:

Konfigurasikan gateway default koneksi WiFi ponsel Anda menjadi proxy (sehingga proxy berada di tengah dan semua paket melewatinya) Instal sertifikat proxy di ponsel (sehingga klien memiliki kunci publik proxy di toko kepercayaannya)

Periksa dokumentasi proxy Anda tentang menginstal sertifikat. Berikut adalah instruksi untuk mitmproxy. Dan ini file PEM sertifikat untuk iOS.

Untuk memantau permintaan HTTP yang dicegat, Anda cukup meluncurkan mitmproxy dan menghubungkannya dari ponsel Anda (port default adalah 8080).

Buka situs web di browser seluler Anda. Pada titik ini Anda harus dapat melihat lalu lintas di mitmproxy.

Setelah Anda memastikan semuanya berjalan sesuai rencana, inilah saatnya untuk mulai menjelajahi API pribadi pilihan Anda. Pada dasarnya, pada titik ini Anda cukup membuka aplikasi, bermain-main dengannya dan mendapatkan ide tentang titik akhir API dan struktur permintaan.

Tidak ada algoritme ketat tentang cara merekayasa balik API perangkat lunak - sebagian besar waktu Anda mengandalkan intuisi dan membuat asumsi.

Pendekatan saya adalah mereplikasi panggilan API dan bermain dengan opsi yang berbeda. Awal yang baik adalah memutar ulang permintaan yang Anda tangkap di mitmproxy, dan lihat apakah itu berhasil (Tekan 'r' untuk memutar ulang permintaan). Langkah pertama adalah mencari tahu header mana yang wajib. Cukup nyaman untuk bermain dengan header dengan mitmproxy: tekan 'e' untuk masuk ke mode pengeditan, lalu 'h' untuk memodifikasi header. Dengan pintasan yang mereka gunakan, pecandu vim akan merasa seperti di rumah sendiri. Anda juga dapat menggunakan ekstensi browser seperti Postman untuk menguji API, tetapi ekstensi tersebut cenderung menambahkan header yang tidak perlu, jadi saya sarankan untuk tetap menggunakan mitmproxy atau curl.

Saya telah membuat skrip yang membaca file dump mitmproxy dan menghasilkan string curl - https://Gist.github.com/nderkach/bdb31b04fb1e69fa5346

Mari kita mulai dengan permintaan yang dikirim saat Anda masuk.

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

Hal pertama yang saya perhatikan adalah bahwa setiap permintaan berisi tajuk wajib X-CS-Url-Signature yang berbeda setiap saat. Saya juga mencoba memutar ulang permintaan setelah beberapa saat untuk memeriksa apakah ada pemeriksaan stempel waktu di server, dan tidak ada. Hal selanjutnya yang harus dilakukan adalah mencari tahu bagaimana tanda tangan ini dihitung.

Pada titik ini saya memutuskan untuk merekayasa balik biner dan mencari tahu algoritmanya. Secara alami, memiliki pengalaman mengembangkan untuk iPhone dan memiliki iPhone yang saya inginkan, saya memutuskan untuk memulai dengan iPhone ipa (aplikasi iPhone yang dapat dikirim). Ternyata untuk mendekripsi, saya membutuhkan telepon yang sudah di-jailbreak. Berhenti! Waktu Palu.

Kemudian, saya ingat bahwa mereka juga memiliki aplikasi Android. Saya agak ragu untuk mencoba pendekatan ini, karena saya tidak tahu apa-apa tentang Android atau Java. Saya kemudian berpikir itu akan menjadi kesempatan yang baik untuk belajar sesuatu yang baru. Ternyata lebih mudah untuk mendapatkan kode sumber kuasi yang dapat dibaca manusia dengan mendekompilasi bytecode java daripada kode mesin iphone yang sangat dioptimalkan.

Apk (pengiriman aplikasi Android) pada dasarnya adalah file zip. Anda dapat menggunakan ekstraktor zip apa pun untuk membongkar isinya. Anda akan menemukan file bernama class.dex, yang merupakan bytecode Dalvik. Dalvik adalah mesin virtual yang digunakan untuk menjalankan bytecode Java yang diterjemahkan di Android.

Untuk mendekompilasi file .dex menjadi kode sumber .java saya menggunakan alat yang disebut dex2jar. Output dari alat ini adalah file jar, yang dapat Anda dekompilasi dengan berbagai alat. Anda bahkan dapat membuka toples di Eclipse atau IntelliJ IDEA dan itu akan melakukan semua pekerjaan untuk Anda. Sebagian besar alat ini menghasilkan hasil yang serupa. Kami tidak terlalu peduli jika kami dapat mengkompilasinya kembali untuk menjalankannya, kami hanya menggunakannya untuk menganalisis kode sumber.

Berikut adalah daftar alat yang saya coba:

• FernFlower (sekarang bagian dari IntelliJ IDEA)
• CFR
• JD-GUI
• Krakatau
• Procyon

CFR dan FernFlower bekerja paling baik untuk saya. JD-GUI tidak dapat mendekompilasi beberapa bagian penting dari kode dan tidak berguna, sementara yang lain memiliki kualitas yang hampir sama. Untungnya, tampaknya kode kode Java belum dikaburkan, tetapi ada alat seperti ProGuard http://developer.android.com/tools/help/proguard.html untuk membantu Anda menghilangkan penyamaran kode.

Dekompilasi Java sebenarnya bukan cakupan tutorial rekayasa balik ini - ada banyak hal yang ditulis tentang topik ini, jadi anggap saja Anda berhasil mendekompilasi dan mendeobfuscate kode Java Anda.

Saya telah menggabungkan semua kode yang relevan yang digunakan untuk menghitung X-CS-Url-Signature di Intisari berikut: https://Gist.github.com/nderkach/d11540e9af322f1c1c74

Pertama, saya telah mencari penyebutan X-CS-Url-Signature , yang saya temukan di RetrofitHttpClient . Satu panggilan tertentu tampak menarik - ke modul EncUtils . Menggali ke dalamnya, saya menyadari bahwa mereka menggunakan HMAC SHA1. HMAC adalah kode otentikasi pesan yang menggunakan fungsi kriptografi (dalam hal ini SHA1) untuk menghitung hash pesan. Ini digunakan untuk memastikan integritas (yaitu untuk mencegah seorang pria di tengah memodifikasi permintaan) dan otentikasi.

Kami membutuhkan dua hal untuk menghitung X-CS-Url-Signature : kunci pribadi dan pesan yang disandikan (mungkin beberapa variasi dari muatan permintaan HTTP dan 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));

Dalam kode a adalah pesan dan s adalah kunci yang digunakan untuk menghitung header a2 (panggilan ganda ke EncUtils hanya menghitung intisari hex HMAC SHA1).

Menemukan kunci bukanlah masalah - itu disimpan dalam teks biasa di ApiModule , dan digunakan untuk menginisialisasi parameter kedua RetrofitHttpClient.

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

Jika kita melihat panggilan ke EncUtils , kita dapat melihat bahwa string literal di atas digunakan kata demi kata sebagai kunci untuk menghitung HMAC, kecuali dalam kasus ketika this.b didefinisikan. Dalam kasus terakhir, this.b ditambahkan dengan titik padanya.

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

Sekarang, hanya dengan melihat kode itu tidak jelas bagi saya di mana dan bagaimana this.b diinisialisasi (satu-satunya hal yang dapat saya temukan adalah bahwa itu disebut dalam metode dengan tanda tangan this.a(String b) , tetapi saya tidak dapat menemukan panggilan untuk itu di mana pun dalam kode).

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

Saya mendorong Anda untuk mendekompilasi dan mencari tahu sendiri :)

Mencari tahu pesan itu cukup mudah - dalam kode Anda dapat melihat bahwa itu adalah rangkaian dari jalur url, yaitu /api/v2/sessions dan string dengan muatan JSON (jika ada).

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

Hanya dengan melihat kodenya, sulit untuk mengetahui algoritma yang tepat untuk perhitungan HMAC. Jadi, saya memutuskan untuk membangun kembali aplikasi dengan simbol debug untuk mengetahui dengan tepat cara kerja aplikasi. Saya telah menggunakan alat bernama apktool https://code.google.com/p/android-apktool/ untuk membongkar bytecode Dalvik menggunakan smali https://code.google.com/p/smali/. Saya mengikuti panduan di https://code.google.com/p/android-apktool/wiki/SmaliDebugging

Setelah Anda membangun apk, Anda perlu menandatangani dan menginstalnya di perangkat Anda. Karena saya tidak memiliki perangkat Android, saya menggunakan emulator yang disertakan dengan Android SDK. Dengan beberapa sendok makan, inilah cara Anda melakukannya:

 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>

Saya menggunakan emulator Android bawaan yang hadir dengan SDK dan gambar virtual Atom x86 dengan HAXM diaktifkan untuk memastikannya berjalan dengan lancar.

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

Berikut adalah panduan yang bagus tentang cara mengatur gambar virtual: http://jolicode.com/blog/speed-up-your-android-emulator

Pastikan Anda melihat baris HAX berfungsi dan emulator berjalan dalam mode virt cepat pada startup emulator untuk memastikan Anda telah mengaktifkan HAXM.

Kemudian, saya menginstal apk ke emulator dan menjalankan aplikasi. Mengikuti panduan apktool, saya memanfaatkan debugger jarak jauh IntelliJ IDEA untuk terhubung ke emulator dan mengatur beberapa breakpoint baris:

Bermain-main dengan aplikasi sebentar, saya dapat mengetahui bahwa kunci pribadi yang digunakan untuk menginisialisasi RetrofitHttpClient digunakan untuk menghitung HMAC dari tanda tangan permintaan masuk. Sebagai tanggapan terhadap POST login, Anda menerima ID pengguna dan accessToken ( X-Access-Token ). Token akses digunakan untuk mengotorisasi semua permintaan berikut. HMAC untuk semua permintaan login posting dibuat dengan cara yang sama seperti permintaan login, kecuali bahwa kuncinya dibuat dengan menambahkan .<user_id> ke kunci pribadi asli.

Setelah Anda diotorisasi, aplikasi mengirimkan permintaan berikut:

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

Karena saya dapat mengurangi secara empiris, permintaan ini opsional untuk otentikasi. Poin bonus jika Anda mengetahui kegunaannya!

Setelah diautentikasi, Anda dapat mengirim permintaan untuk mengambil profil pengguna Anda (atau siapa pun), seperti ini:

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

Saya tidak membahas banyak detail, tetapi saya perhatikan bahwa profil diperbarui dengan permintaan PUT. Hanya untuk bersenang-senang, saya mencoba memperbarui profil lain dengan permintaan yang sama - itu tidak diotorisasi, jadi tampaknya dasar-dasar keamanan diterapkan.

Saya menulis skrip Python sederhana untuk masuk menggunakan kredensial couchsurfing.com Anda dan mendapatkan profil pengguna Anda: https://Gist.github.com/nderkach/899281d7e6dd0d497533. Berikut adalah pembungkus Python untuk API: https://github.com/nderkach/couchsurfing-python dengan paket yang tersedia di repositori pypi (pip install couchsurfing).

Langkah selanjutnya

Saya tidak yakin apa yang sebenarnya akan saya lakukan dengan API kali ini. Kode HTML di profil pengguna tidak lagi diizinkan, jadi saya harus membuat pendekatan berbeda untuk masalah lama. Saya akan terus mengembangkan dan meningkatkan pembungkus python API, jika ada permintaan untuk itu, dan dengan asumsi bahwa couchsurfing.com tidak akan menyebabkan terlalu banyak masalah. Saya tidak menjelajahi API terlalu banyak, dan saya hanya mengujinya untuk beberapa kerentanan dasar. Tampaknya cukup aman, tetapi akan menarik untuk mengetahui apakah Anda bisa mendapatkan akses ke data yang tidak tersedia melalui situs web. Either way, sekarang Anda dapat menggunakan rekayasa perangkat lunak terbalik saya untuk membangun klien alternatif untuk Windows Phone, Pebble, atau sofa pintar Anda.

Penutup Dengan Sebuah Pertanyaan

Ada diskusi yang ingin saya buka - mengapa tidak memublikasikan API Anda dan menjadikannya publik? Bahkan jika saya tidak berhasil meretas API, masih mungkin untuk mengikis situs web. Ini akan lebih lambat dan lebih sulit untuk dipelihara, tetapi tentunya mereka lebih memilih konsumen untuk menggunakan API daripada scraper web. Ketersediaan API akan memungkinkan pengembang pihak ketiga untuk meningkatkan produk perusahaan, dan membangun layanan bernilai tambah di sekitarnya. Seseorang dapat berargumen bahwa akan lebih mahal untuk memelihara API publik daripada API pribadi; tetapi sekali lagi, keuntungan dari layanan pembangunan komunitas Anda selain produk Anda akan lebih besar daripada biaya pemeliharaan API.

Apakah mungkin untuk sepenuhnya mencegah penggunaan API pribadi oleh klien pihak ketiga? Saya tidak berpikir begitu. Menggunakan penyematan SSL akan mencegah sniffing ke permintaan API menggunakan teknik proxy transparan sederhana seperti yang dijelaskan sebelumnya. Pada akhirnya, bahkan jika Anda mengaburkan biner, peretas yang termotivasi dengan beberapa sumber daya dan waktu akan selalu dapat merekayasa balik biner aplikasi dan mendapatkan kunci/sertifikat pribadi. Saya pikir asumsi bahwa titik akhir klien aman pada dasarnya salah. Klien API adalah titik lemah.

Dengan menjaga kerahasiaan API, perusahaan pada dasarnya menyampaikan pesan ketidakpercayaan kepada penggunanya. Tentunya, Anda dapat mencoba melindungi API pribadi Anda lebih jauh. Namun, tidakkah Anda lebih suka menerapkan keamanan dasar untuk API guna mencegah penggunaan yang berbahaya; dan alih-alih memfokuskan sumber daya Anda pada peningkatan perangkat lunak untuk memberikan pengalaman pengguna yang lebih baik?

Couchsurfing, tolong, dengan gula di atasnya, buka API.