it-swarm-id.com

Mengamankan API untuk akses seluler

Saya telah membangun API Nice REST/JSON yang digunakan oleh perusahaan lain (klien kami) sebagai layanan B2B. Setiap klien kami memiliki pasangan nama pengguna/kata sandi, dan kami juga melakukan HTTPS dan memvalidasi IP sumber permintaan untuk layanan. Penggunaan layanan membutuhkan biaya, dan klien ditagih setiap bulan untuk penggunaan layanannya.

Sekarang, beberapa klien sedang membangun aplikasi mobile yang mereka bagikan kepada pengguna mereka (pengguna akhir B2C). Tidak semua pengguna akhir dari layanan kami memiliki server dan mereka ingin menggunakan layanan langsung dari smartphone (yang secara teknis bukan masalah besar adalah JSON/REST).

Masalahnya adalah saya tidak yakin bagaimana melindungi layanan terhadap penipuan. Apa yang akan mencegah pengembang pihak ketiga membongkar salah satu aplikasi seluler klien dan menyalin nama pengguna/kata sandi mereka/kredensial keamanan apa pun dan menggunakannya di dalam aplikasinya? Itu akan memungkinkan dia untuk mengkonsumsi layanan dan membebankan biaya penggunaan ke salah satu klien kami yang sah!

Saya cukup yakin tidak ada solusi kripto yang sempurna untuk masalah ini kecuali pengguna akhir dimandatkan untuk mengotentikasi ke beberapa server. Namun itu tidak selalu terjadi.

Sebagai upaya terakhir saya kira saya dapat mendistribusikan perpustakaan yang dikaburkan untuk Android/IPhone, yang setidaknya akan memberikan ilusi keamanan ...

EDIT (klarifikasi):

Biarkan saya mencoba menyederhanakan skenario.

  1. Saya memiliki server web yang tidak bisa diretas yang melayani JSON REST API.
  2. Klien seluler mengakses API saya secara langsung. IP mereka tidak dapat divalidasi. Mereka menjalankan OS standar (Android/iOS).
  3. Tidak ada server lain yang terlibat.
  4. Saya tidak dapat mengakses IMEI ponsel (dianggap pribadi), juga tidak akan membantu saya karena saya tidak tahu pengguna akhir.
  5. Ada beberapa aplikasi seluler yang legal, yang dikembangkan oleh berbagai perusahaan yang mengakses API kami.
  6. Keamanan saat ini (nama pengguna/kata sandi) mudah diretas oleh perusahaan jahat. Perusahaan jahat itu membongkar aplikasi seluler yang sah dan menyalin nama pengguna/kata sandi ke aplikasi ilegal mereka. Mereka mendistribusikan aplikasi dan keuntungan ini (penggunaan API dibebankan ke perusahaan tempat mereka mencuri kredensial).

Bisakah ini dihentikan?

16
Tal Weiss

Pertanyaan Anda adalah "Bisakah ini dihentikan?", Tetapi saya merasa bahwa sesuatu yang signifikan tentang sistem tidak dapat/tidak akan benar-benar diubah.

Jika saya mengerti dengan benar, Anda bertanya (disederhanakan):

Saya memiliki banyak klien yang berbagi nama pengguna dan kata sandi yang sama. Bisakah saya menghentikan penyalahgunaan?

Jawabannya adalah tidak. Anda harus memutuskan apakah Anda mampu mengabaikan masalah, atau menerapkan solusi yang benar.

Jika Anda benar-benar ingin melakukan ini dengan benar, lihat menerapkan sesuatu seperti OAuth, sehingga Anda dapat mendistribusikan token autentikasi yang terpisah untuk pengguna akhir, menautkannya ke klien Anda untuk penagihan, pencabutan akses, dll.

-

Paling tidak yang harus Anda lakukan adalah mengizinkan klien Anda (perusahaan) untuk memilih menggunakan skema auth yang lebih baik. Jadi, misalnya, Anda membuat API untuk mereka meminta (dan mencabut) token akses terpisah untuk pengguna akhir mereka.

  • Perusahaan A meminta token dari server mereka (ini dimulai oleh aplikasi mereka yang memberi tahu mereka "beri saya token")
  • Anda mengembalikan token N, mencatat perusahaan apa yang dilampirkan
  • Jika aplikasi Perusahaan A-s terhubung ke layanan Anda, ia mengirimkan token N, dan bukan nama pengguna/kata sandi
  • Perusahaan A dapat memberi tahu layanan Anda "mencabut token N", dan permintaan lebih lanjut dengan token itu tidak akan dilayani oleh layanan Anda. Tetapi, jika token dicabut, itu tidak akan membuat semua aplikasi klien tidak dapat digunakan.

Jika perusahaan tidak ingin melakukan ini, mereka masih dapat terus terhubung menggunakan nama pengguna/kata sandi mereka, tetapi mereka akan sepenuhnya bertanggung jawab atas semua penggunaan yang dihasilkan.

Intinya adalah bahwa Anda tidak dapat benar-benar meminta klien Anda untuk membocorkan kredensial (sesuatu yang tidak mungkin dilakukan dalam skenario aplikasi seluler) jika mereka tidak memiliki cara lain untuk menggunakan layanan ini.

7
Joel L

Jadi saya harap ini benar. Anda ingin cara aman mengonfirmasi identitas klien menggunakan kunci API yang valid? Saya pikir menyimpan kunci API dengan aman sebagian besar bertanggung jawab pada perusahaan yang mengembangkan aplikasi dan bukan perusahaan Anda.

Anda perlu mengenkripsi dan mengaburkan kunci untuk melindunginya dari peretas biasa, tetapi saya rasa Anda tidak akan pernah bisa mencegah peretas yang gigih. Anda bisa melakukan sedikit peretasan untuk membuat biner lebih sulit untuk di-debug yang dapat mengurangi kemungkinan aplikasi Anda mengambang di internet. Namun, ini bukan keamanan mutlak dan kecuali perusahaan Anda mengembangkan aplikasi di dalam perusahaan, bagaimana Anda bisa menegakkan tindakan tersebut?

Jadi sebagai jawaban untuk skenario Anda, tidak, saya tidak berpikir itu bisa dihentikan secara efektif tanpa mengganggu pengalaman pengguna. Anda dapat mendidik perusahaan menggunakan API Anda - menyatukan sedikit buku pegangan untuk mereka dan memastikan bahwa itu jelas mereka tanggung jawab untuk menjaga mereka kunci api aman.

Pada akhirnya, Anda juga dapat menerapkan beberapa fitur mitigasi. Sebagai contoh:

  1. Izinkan perusahaan untuk menentukan batas keras mereka sendiri. Katakan perusahaan A tahu bahwa bulan lalu mereka memiliki unduhan aplikasi N dan karenanya ingin membatasi akses mereka ke API Anda ke permintaan X per hari atau jam.
  2. Pantau setiap lonjakan permintaan per perusahaan per periode waktu.
  3. Tetapkan langkah prosedur yang akan terjadi pada aktivitas penipuan potensial.
  4. Re-key, re-key, dan re-key.

Tujuan kegagalan (ini terjadi dengan yang terbaik) adalah untuk meminimalkan kerusakan.

Semoga berhasil.

6
Kurt

Anda berhak skeptis tentang klien Anda yang memasukkan nama pengguna/kata sandi mereka di aplikasi seluler yang mereka bagikan kepada semua pengguna mereka. Seperti yang telah Anda identifikasi dengan benar, akan mudah bagi penyerang untuk membongkar aplikasi seluler itu, mengeluarkan nama pengguna/kata sandi dari aplikasi seluler, dan menggunakannya di aplikasi mereka sendiri. Sayangnya, klien Anda adalah orang yang memutuskan untuk melakukan itu, tetapi biayanya dibebankan pada Anda. Jadi, ini adalah eksternalitas, dan Anda akan memerlukan beberapa cara untuk membuat biaya dan risiko serta insentif lebih selaras. Saya punya beberapa saran di bawah ini tentang cara melakukannya.

Secara umum, saya melihat dua solusi yang masuk akal untuk ini:

  • Transfer risiko. Untuk setiap klien, berikan batasan pada berapa banyak permintaan yang akan Anda terima dari klien itu. Beri tahu klien bahwa itu adalah tanggung jawab mereka untuk mengamankan nama pengguna/kata sandi mereka, bahwa semua permintaan yang datang menggunakan nama pengguna/kata sandi ini akan dihitung berdasarkan batas mereka, dan jika terlalu banyak permintaan datang, akun mereka mungkin dinonaktifkan. Beri tahu mereka bahwa jika mereka menyematkan nama pengguna/kata sandi mereka di aplikasi seluler, bahwa ada risiko seseorang jahat mencuri nama pengguna/kata sandi dan menggunakannya untuk membuat banyak permintaan, menyebabkan akun mereka dinonaktifkan dan aplikasi seluler mereka berhenti bekerja . Biarkan mereka memutuskan apakah mereka mau mengambil risiko atau tidak.

  • Persyaratan kontrak. Beri tahu klien Anda bahwa mereka dilarang membagikan nama pengguna/kata sandi mereka dengan orang lain, dan tidak diperbolehkan bagi mereka untuk menyematkan nama pengguna/kata sandi mereka di aplikasi yang dapat diunduh oleh orang lain. Beri tahu mereka bahwa jika Anda mendeteksi adanya pelanggaran terhadap kebijakan ini, akun mereka mungkin dinonaktifkan dan mereka mungkin dikenai biaya apa pun yang dibebankan pada server Anda.

    Jika klien Anda ingin membuat aplikasi seluler, beri tahu klien Anda bahwa, alih-alih menyematkan nama pengguna/kata sandi mereka di aplikasi seluler, mereka harus mem-proxy permintaan tersebut ke server mereka sendiri. Dengan kata lain, klien harus menyiapkan server yang mengetahui nama pengguna/kata sandi klien, tetapi nama pengguna/kata sandi ini tidak boleh tertanam dalam aplikasi seluler. Aplikasi seluler klien harus mengautentikasi ke server klien, mengirim permintaan ke server, dan kemudian server harus meneruskan permintaan kepada Anda dan meneruskan tanggapan kembali ke aplikasi seluler. Server mereka harus mengautentikasi pengguna akhir (mis., Mengharuskan setiap pengguna akhir aplikasi seluler untuk membuat akun di server mereka, dengan nama pengguna/kata sandi mereka sendiri). Server mereka harus memberlakukan batas bandwidth berdasarkan per pengguna, dan menonaktifkan akun pengguna akhir yang melebihi batas itu.

Anda juga dapat mengizinkan klien untuk memilih di antara dua opsi ini: misalnya, antara akun bandwidth terbatas (dengan transfer risiko), atau akun bandwidth tidak terbatas (dengan persyaratan untuk tidak menyematkan nama pengguna/kata sandi dalam aplikasi yang dapat diakses orang lain ).

Saya harap ini masuk akal. Ini mungkin agak membingungkan, karena ada tiga pihak - Anda, klien Anda, dan pengguna akhir klien Anda - masing-masing dengan minat dan keprihatinan. Saya harap saya cukup membedakan antara ketiganya.

3
D.W.

Mengamankan data Anda dalam transmisi dengan SSL sudah mencakup serangan man-in-middle. Kata sandi yang dikodekan dengan keras dalam kode sumber bagaimanapun bukan praktik yang aman. Anda seharusnya tidak peduli dengan alamat IP pengguna atau IMEI. Jangan bicara tentang pelacakan dan coba perbaiki hal-hal di tempat pertama.

Seperti yang Anda katakan, Anda menggunakan REST. Hanya sedikit hal yang bisa membantu Anda, saya harap.

  1. Otentikasi pengguna dari sisi server. Pertahankan manajemen sesi yang ketat sehingga tidak bisa dipalsukan. Lihat OWASP untuk ini.
  2. Lakukan tes fuzz untuk API Anda. ReST dikenal dengan beberapa kerentanan. Silakan jelajahi di Internet dan kenali sebagian besar bug yang dikenal di ReST. Menambal masalah tersebut untuk API Anda.
  3. Hal SSL Anda bagus karena melindungi data Anda di tengah.

Jangan khawatir tentang kode sumber Anda. Itu bisa saja dicabut tetapi tidak apa-apa. Fungsi utama Anda akan berjalan di server dan hanya memberikan tanggapan kepada klien. Simpan semua hal baik di sisi server.

1
mojo

Salah satu masalah yang saya pikir akan Anda hadapi di depan ponsel adalah validasi alamat IP. Biasanya alamat IP seluler yang ditetapkan oleh perusahaan telekomunikasi akan dijaring. IP yang terjaring akan membuat mekanisme validasi IP yang diadopsi di sisi server tidak digunakan.

Untuk mengimplementasikan solusi pada Android dan Iphone; saya pikir pendekatannya harus:

  1. Biarkan otentikasi server klien dalam mode SSL diperluas ke validasi sertifikat klien juga. Maksud saya, biarkan klien dan server menggunakan sertifikat untuk membuat sesi SSL aman.
  2. Kirimkan PFX/P12 yang berisi sertifikat klien (seluler) sedemikian rupa sehingga memerlukan PIN dan kombinasi nomor IMEI dan IMSI. Dengan cara ini akan menjadi sulit bagi penyerang untuk menolak sesi yang sama.
  3. Mintalah beberapa AI diterapkan di server yang mendeteksi dua atau lebih sesi bersamaan yang dimulai menggunakan sertifikat klien yang sama yang akan memberi tahu Anda bahwa beberapa kompromi telah terjadi dan server dapat segera daftar hitam atau mencabut sertifikat untuk penggunaan lebih lanjut.

Saya percaya meskipun kami sedang mendiskusikan untuk lingkungan seluler; selain validasi IP, risikonya juga ada di lingkungan PC. Di masa depan Anda dapat mengadopsi atau bermigrasi ke implementasi berbasis tanda tangan dan sertifikat klien pada lingkungan PC juga jika Anda mendapatkan beberapa masalah penagihan yang salah yang diajukan oleh klien.

1
Mohit Sethi

Penipuan adalah vauge dan tidak bisa diatasi hanya dengan implementasi teknis, tetapi jika Anda telah menerapkan validasi dan penguncian IP yang meningkat, maka tidak ada yang perlu dikhawatirkan. Anda juga tidak boleh memberikan kredensial aktual kepada klien Anda (B2B). Biarkan saya jelaskan mengapa dan bagaimana.

Dari pemahaman saya tentang apa yang Anda tulis, konsep dan implementasi keamanan dasar hingga rata-rata telah diterapkan mengenai sisi B2B (PERUSAHAAN ANDA - PERUSAHAAN ANDA). Itu bagus. Validasi IP, SSL/TLS, Pengguna/Lulus dll. Sekarang, Anda khawatir bahwa kredensial API yang digunakan oleh klien Anda untuk mengirimkan aplikasi seluler kepada pengguna akhir dapat cacat dengan cara yang membuat pengguna akhir pihak ketiga dapat memanfaatkan kredensial ini jika aplikasi seluler klien Anda telah dieksploitasi dengan cara tertentu.

Pada dasarnya bermuara pada serangkaian lapisan keamanan. Pertanyaannya adalah bagaimana perusahaan Anda telah merancang dan mengimplementasikan lapisan-lapisan ini?

  1. SERVER API JSON/REST Anda harus berisi kredensial Anda yang sebenarnya. Jika Anda memberikan layanan dan memerlukan koneksi ke penyedia jaringan/operator maka kredensial tersebut dapat ditemukan di sini juga. Kamu tahu apa maksudku.

  2. Jangan memberikan akses langsung YOURCLIENT ke SERVER API JSON/REST. Sebagai gantinya, Anda memerlukan Host melompat yang akan berfungsi sebagai Host untuk lingkungan tepercaya, server API tempat aplikasi JSON/REST Anda berada harus HANYA mengautentikasi dengan server ini menggunakan validasi/penguncian Alamat IP. Otentikasi server ke server menggunakan IP atau pasangan kunci publik/pribadi. Ini kebijaksanaan Anda apa yang harus digunakan.

Server ini juga harus bertindak sebagai layanan web yang berisi sekumpulan nama pengguna/kata sandi yang kemudian memetakan dirinya sendiri ke file konfigurasi dan meneruskan permintaan ke JSON/REST API SERVER. Sekarang, YOURCLIENTS harus memiliki akses ke server ini berdasarkan validasi IP/penguncian juga dan dilindungi menggunakan HTTPS. Konsepnya adalah bahwa tidak ada kredensial pengguna/pass aktual dapat ditemukan di sini kecuali untuk kunci/rahasia yang memetakan ke SERVER API.

  1. YOURCLIENT dapat memiliki implementasi keamanan dari dalam pihak mereka kepada pengguna akhir. Itu bisa dalam bentuk pasangan kunci publik/pribadi PKI untuk pengembang atau 2FA untuk pengguna biasa. YOURCLIENT harus menerapkan langkah-langkah ini, bukan perusahaan Anda.

Sekarang misalnya, pengembang pihak ke-3 (pengguna akhir) telah mengeksploitasi kelemahan pada aplikasi seluler yang dibuat oleh salah satu YOURCLIENT dan mendapatkan kredensial mereka:

  1. Tak berguna. Mengenai bahwa untuk menggunakan kredensial, IP Anda akan divalidasi.
  2. Tidak valid Mengenai bahwa Anda harus diautentikasi melalui pasangan kunci publik/pribadi.
  3. Teknik eskalasi Privilege akan mengharuskannya untuk mengeksploitasi server yang sebenarnya agar dapat dipercaya.
  4. Mengeksploitasi server yang sebenarnya membutuhkan teknik yang dibuat yang akan memperlambat motivasi penyerang.
  5. Tidak ada serangan yang berhasil yang motivasi telah berakhir.

Kebingungan itu baik dan memperlambat serangan tetapi itu adalah bentuk keamanan paling tidak. Anda harus lebih bergantung pada crypto yang menggunakan kunci.

Ingat, tidak ada solusi keamanan mutlak selain dari upaya terus menerus Anda untuk memerangi penipuan dari dalam perspektif keamanan teknis dan operasional.

1
John Santos