Aplikasi server iPhone aman ↔ komunikasi


14

Apa yang akan menjadi pendekatan terbaik untuk mencapai komunikasi pribadi antara aplikasi iOS saya dan komponen servernya? Apakah memiliki satu "kunci rahasia" yang tidak berubah dimasukkan ke sumber aplikasi cukup, atau apakah saya perlu mengatur generasi kunci "jabat tangan" seperti itu secara dinamis?

Server dengan sendirinya tidak memiliki akses ke data sensitif apa pun, jadi bahkan jika pengguna menyentuh beberapa titik akhir pribadi, itu tidak akan membawa mereka ke mana pun, tetapi saya hanya ingin mereka disembunyikan dari publik. Pada dasarnya, saya ingin mengabaikan semua permintaan yang mengenai rute tertentu, kecuali mereka datang dari aplikasi iOS saya.

Komponen server berjalan pada RoR, jika itu penting.

Jawaban:


8

Anda tidak dapat menolak koneksi secara efektif kecuali jika Anda memberikan kunci pribadi yang dapat dicabut secara individual oleh setiap pelanggan. Tapi ini mungkin berlebihan. Anda tidak memerlukan solusi antipeluru jika kebanyakan orang tidak mau repot menembakkan peluru.

Ini pertanyaan keamanan, jadi mari kita gambarkan model ancaman dan strategi mitigasi.

Misalkan Anda memiliki URL yang menekan yang dapat menimbulkan biaya nyata bagi Anda (mis. Biaya pemrosesan), dan Anda ingin melindunginya dari serangan DoS sederhana dan dari aplikasi peniru.

Gunakan SSL untuk menyembunyikan koneksi agar tidak mudah dianalisis. Gunakan nomor port non-obviuos, urutan redirect, pertukaran cookie untuk menyulitkan koneksi sebelum Anda melakukan bagian mahal dari permintaan. Gunakan beberapa kode rahasia yang dipanggang ke dalam aplikasi Anda untuk memberi tahu server bahwa ia harus menerima koneksi.

Sekarang seseorang tidak dapat mempelajari URL mahal untuk hit hanya dengan menjalankan sniffer paket, atau dengan melihat string seperti URL dalam kode Anda. Seorang penyerang potensial harus mendekompilasi aplikasi Anda.

Anda tidak dapat benar-benar melindungi kode Anda dari dekompilasi dan / atau dijalankan di bawah debugger. Penyerang akhirnya mempelajari kunci rahasia dan urutan koneksi.

Anda melihat bahwa Anda mulai menerima permintaan pemalsuan dengan URL Anda yang mahal: baik dalam bentuk serangan, atau dalam bentuk aplikasi peniru yang harus mengakses layanan Anda agar dapat dijalankan, atau mungkin kode eksploit diposting secara publik. Anda tidak bisa memberi tahu permintaan jahat dari permintaan yang sah.

Buat pembaruan kecil gratis untuk aplikasi Anda, dengan kunci rahasia yang berbeda. Itu harus mengenai URL mahal berbeda yang menyajikan data yang sama dengan URL mahal dikompromikan. Untuk beberapa waktu, buat kedua URL dapat diakses.

Tonton basis pengguna Anda beralih ke versi yang diperbarui. Perlambat URL mahal yang dikompromikan dan akhirnya 404. Anda baru saja memitigasi pelanggaran keamanan, semoga tanpa kehilangan terlalu banyak. Kembali ke titik awal.

Penafian: Saya bukan ahli keamanan.


Jika pengguna memiliki aplikasi, mereka dapat menemukan URL yang mahal bahkan jika lebih dari SSL (klien memiliki kontrol penuh atas sertifikat, dll). Hal ini membuat sisa argumen diperdebatkan belum lagi ini adalah contoh klasik terhadap keamanan melalui ketidakjelasan.
aleemb

@aleemb: Tentunya, Anda tidak bisa merahasiakan URL yang mahal. Seorang penyerang yang gigih akan menemukannya. Intinya adalah untuk membuat penemuan ini juga mahal, sehingga "script kiddie" akan mengalami kesulitan (er) dan dengan demikian kurang insentif untuk menggali dan mengeksploitasi, dan memungkinkan mitigasi. Jika biaya mitigasi Anda cukup rendah, dan biaya penemuan untuk penyerang tinggi dibandingkan dengan keuntungan apa pun yang dapat diambil penyerang dari menggunakan URL yang mahal, serangan menjadi sia-sia. Sekali lagi, ini bukan keamanan yang ketat .
9000

5

Anda memiliki masalah klasik yang benar-benar tidak dapat diselesaikan.

Untuk memastikan privasi sederhana (yaitu memastikan data Anda tidak dapat diintip atau diubah saat transit) Anda dapat melakukan segalanya melalui SSL dan memberikan server Anda sertifikat yang dikeluarkan dengan benar oleh CA yang dikenali iPhone.

Namun, untuk otorisasi, tidak ada solusi yang baik yang akan 100% menjamin bahwa tidak ada orang lain selain aplikasi Anda yang dapat mengakses API. Solusi yang Anda usulkan akan berhasil, kecuali:

  • siapa pun yang mengunduh aplikasi Anda tentu memiliki kunci pribadi
  • jika mereka entah bagaimana berhasil meng-un-package aplikasi Anda, dan de-kompilasi, mereka akan memiliki kunci pribadi dalam teks biasa
  • begitu mereka memiliki kunci pribadi dalam teks biasa, mereka dapat menggunakannya untuk menandatangani permintaan jahat mereka sendiri.

Tidak ada jalan lain untuk ini. Bukan untuk mengatakan Anda tidak bisa mengadopsi pendekatan itu, tetapi pahamilah bahwa itu tidak mudah. Masalah inilah yang membuat DRM benar-benar tidak efektif .


0

Ini adalah untuk apa TLS dan SSL . Salah satu dapat membuat koneksi yang aman tanpa perlu kunci rahasia tetap. Baca bagian Deskripsi pada halaman yang ditautkan untuk mempelajari bagaimana mereka melakukan ini.

Cara efektif untuk mendapatkan manfaat TLS / SSL tanpa harus melakukan banyak pekerjaan (apa pun) adalah dengan meminta server Anda mengimplementasikan layanan web yang diakses klien menggunakan protokol HTTPS. HTTPS hanyalah HTTP melalui koneksi yang aman, dan sistem pemuatan URL di iOS mengimplementasikannya untuk Anda.


Sementara HTTPS memang menyembunyikan komunikasi dari penyadapan, itu tidak mencegah klien acak dari menghubungkan ke titik akhir, kecuali sertifikat klien diperlukan oleh server. Ini bisa 'dimasukkan ke dalam' aplikasi dan membutuhkan beberapa pengetahuan untuk mengekstrak.
9000
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.