Panduan Keamanan

Panduan berikut mencakup beberapa praktik terbaik keamanan yang harus Anda pertimbangkan ketika mengembangkan aplikasi Cordova. Perlu diketahui bahwa keamanan adalah topik yang sangat rumit dan oleh karena itu panduan ini tidak lengkap. Jika Anda yakin dapat berkontribusi pada panduan ini, silakan mengajukan masalah dalam pelacak bug Cordova di bawah "Dokumentasi" . Panduan ini dirancang untuk dapat diterapkan pada pengembangan Cordova umum (semua platform) tetapi pertimbangan khusus platform khusus akan dicatat.

Panduan ini membahas topik-topik berikut:

Daftar putih
Iframe dan Mekanisme Callback Id
Penyertaan Sertifikat
Sertifikat yang ditandatangani sendiri
Penyimpanan terenkripsi
Tips Umum
Artikel yang Direkomendasikan dan Sumber Daya Lain

Daftar putih

Baca dan pahami Panduan Daftar Putih
Daftar putih domain tidak berfungsi di Android API 10 dan di bawah, dan WP8 untuk iframe dan XMLHttpRequest. Ini berarti penyerang dapat memuat domain apa pun dalam iframe dan skrip apa pun pada halaman itu dalam iframe dapat langsung mengakses objek JavaScript Cordova dan objek Java asli yang sesuai. Anda harus mempertimbangkan ini saat membuat aplikasi untuk platform ini. Dalam praktiknya ini berarti memastikan Anda menargetkan API Android lebih tinggi dari 10, dan bahwa jika memungkinkan Anda tidak menggunakan iframe untuk memuat konten eksternal - gunakan plugin inAppBrowser atau plugin pihak ketiga lainnya.

Iframe dan Mekanisme Callback Id

Jika konten disajikan dalam iframe dari domain yang masuk daftar putih, domain itu akan memiliki akses ke jembatan Cordova asli. Ini berarti bahwa jika Anda memasukkan daftar putih jaringan iklan pihak ketiga dan menayangkan iklan tersebut melalui iframe, ada kemungkinan bahwa iklan jahat dapat keluar dari iframe dan melakukan tindakan jahat. Karena itu, Anda biasanya tidak boleh menggunakan iframe kecuali Anda mengontrol server yang meng-host konten iframe. Perhatikan juga bahwa ada plugin pihak ketiga yang tersedia untuk mendukung jaringan iklan. Perhatikan bahwa pernyataan ini tidak benar untuk iOS, yang mencegat semuanya termasuk koneksi iframe.

Penyertaan Sertifikat

Cordova tidak mendukung pinning sertifikat yang sebenarnya. Hambatan utama untuk ini adalah kurangnya API asli di Android untuk mencegat koneksi SSL untuk melakukan pemeriksaan sertifikat server. (Meskipun dimungkinkan untuk melakukan pinning sertifikat pada Android di Java menggunakan JSSE, tampilan web di Android ditulis dalam C ++, dan koneksi server ditangani untuk Anda oleh tampilan web, sehingga tidak mungkin untuk menggunakan Java dan JSSE di sana.) Karena Apache Cordova dimaksudkan untuk menawarkan API yang konsisten di berbagai platform, tidak memiliki kemampuan dalam platform utama yang merusak konsistensi.

Ada beberapa cara untuk memperkirakan pinning sertifikat, seperti memeriksa kunci publik server (sidik jari) adalah nilai yang diharapkan ketika aplikasi Anda mulai atau pada berbagai waktu lainnya selama masa hidup aplikasi Anda. Ada plugin pihak ketiga yang tersedia untuk Cordova yang dapat melakukannya. Namun, ini tidak sama dengan pinning sertifikat sebenarnya yang secara otomatis memverifikasi nilai yang diharapkan pada setiap koneksi ke server.

Ada juga plugin yang dapat melakukan pinning sertifikat sebenarnya untuk beberapa platform, dengan asumsi aplikasi Anda dapat melakukan semua permintaan jaringan menggunakan plugin (yaitu: tidak ada permintaan XHR / AJAX tradisional, dll).

Sertifikat yang ditandatangani sendiri

Tidak disarankan menggunakan sertifikat yang ditandatangani sendiri di server Anda. Jika Anda menginginkan SSL, maka sangat disarankan server Anda memiliki sertifikat yang telah ditandatangani dengan benar oleh CA (otoritas sertifikat) yang terkenal. Ketidakmampuan untuk melakukan pinning sertifikat yang benar membuat ini penting.

Alasannya adalah bahwa menerima sertifikat yang ditandatangani sendiri akan memintas validasi rantai sertifikat, yang memungkinkan sertifikat server apa pun dianggap sah oleh perangkat. Ini membuka komunikasi untuk serangan man-in-the-middle. Menjadi sangat mudah bagi seorang hacker untuk tidak hanya mencegat dan membaca semua komunikasi antara perangkat dan server, tetapi juga untuk memodifikasi komunikasi. Perangkat tidak akan pernah tahu ini sedang terjadi karena tidak memverifikasi bahwa sertifikat server ditandatangani oleh CA yang tepercaya. Perangkat tidak memiliki bukti bahwa server adalah yang diharapkannya. Karena kemudahan melakukan man-in-the-middle attack, menerima sertifikat yang ditandatangani sendiri hanya sedikit lebih baik daripada hanya menjalankan http daripada https pada jaringan yang tidak terpercaya. Ya, lalu lintas akan dienkripsi, tetapi bisa dienkripsi dengan kunci dari man-in-the-middle, sehingga man-in-the-middle dapat mengakses segalanya, jadi enkripsi tidak berguna kecuali untuk pengamat pasif. Pengguna percaya SSL aman, dan ini sengaja membuatnya tidak aman, sehingga penggunaan SSL menjadi menyesatkan. Jika ini akan digunakan pada jaringan tepercaya (yaitu, Anda sepenuhnya berada di dalam perusahaan yang dikendalikan), maka sertifikat yang ditandatangani sendiri masih tidak disarankan. Dua rekomendasi dalam jaringan tepercaya hanya menggunakan http karena jaringan itu sendiri tepercaya, atau untuk mendapatkan sertifikat yang ditandatangani oleh CA tepercaya (bukan yang ditandatangani sendiri). Entah jaringan itu tepercaya atau tidak. sehingga penggunaan SSL menjadi menyesatkan. Jika ini akan digunakan pada jaringan tepercaya (yaitu, Anda sepenuhnya berada di dalam perusahaan yang dikendalikan), maka sertifikat yang ditandatangani sendiri masih tidak disarankan. Dua rekomendasi dalam jaringan tepercaya hanya menggunakan http karena jaringan itu sendiri tepercaya, atau untuk mendapatkan sertifikat yang ditandatangani oleh CA tepercaya (bukan yang ditandatangani sendiri). Entah jaringan itu tepercaya atau tidak. sehingga penggunaan SSL menjadi menyesatkan. Jika ini akan digunakan pada jaringan tepercaya (yaitu, Anda sepenuhnya berada di dalam perusahaan yang dikendalikan), maka sertifikat yang ditandatangani sendiri masih tidak disarankan. Dua rekomendasi dalam jaringan tepercaya hanya menggunakan http karena jaringan itu sendiri tepercaya, atau untuk mendapatkan sertifikat yang ditandatangani oleh CA tepercaya (bukan yang ditandatangani sendiri). Entah jaringan itu tepercaya atau tidak.

Prinsip-prinsip yang dijelaskan di sini tidak spesifik untuk Apache Cordova, mereka berlaku untuk semua komunikasi client-server.

Saat menjalankan Cordova di Android, menggunakan android:debuggable="true"manifes aplikasi akan mengizinkan kesalahan SSL seperti kesalahan validasi rantai sertifikat pada sertifikat yang ditandatangani sendiri. Jadi Anda dapat menggunakan sertifikat yang ditandatangani sendiri dalam konfigurasi ini, tetapi ini bukan konfigurasi yang harus digunakan ketika aplikasi Anda sedang dalam produksi. Ini dimaksudkan untuk digunakan hanya selama pengembangan aplikasi.

Penyimpanan terenkripsi

(TBD)

Tips Umum

Jangan gunakan Android Gingerbread!

Tetapkan tingkat min-target-sdk Anda lebih tinggi dari 10. API 10 adalah Gingerbread, dan Gingerbread tidak lagi didukung oleh Google atau produsen perangkat, dan karenanya tidak direkomendasikan oleh tim Cordova.
Gingerbread telah terbukti tidak aman dan salah satu OS seluler yang paling ditargetkan http://www.mobilemag.com/2012/11/06/andriod-2-3-gingerbread-security/ .
Daftar Putih pada Android tidak berfungsi dengan Gingerbread atau lebih rendah. Ini berarti penyerang dapat memuat kode berbahaya dalam iframe yang kemudian akan memiliki akses ke semua Cordova API dan dapat menggunakan akses itu untuk mencuri data pribadi, mengirim pesan SMS ke nomor tingkat premium, dan melakukan tindakan jahat lainnya.

Gunakan InAppBrowser untuk tautan luar

Gunakan InAppBrowser saat membuka tautan ke situs web luar mana pun. Ini jauh lebih aman daripada memasukkan nama domain ke daftar putih dan memasukkan konten secara langsung di aplikasi Anda karena InAppBrowser akan menggunakan fitur keamanan browser asli dan tidak akan memberikan akses situs web ke lingkungan Cordova Anda. Sekalipun Anda mempercayai situs web pihak ketiga dan memasukkannya langsung ke dalam aplikasi Anda, situs web pihak ketiga itu dapat ditautkan ke konten web berbahaya.

Validasi semua input pengguna

Selalu memvalidasi setiap dan semua input yang diterima aplikasi Anda. Ini termasuk nama pengguna, kata sandi, tanggal, media yang diunggah, dll. Karena penyerang dapat memanipulasi aset HTML dan JS Anda (baik dengan mendekompilasi aplikasi Anda atau menggunakan alat debugging seperti chrome: // inspect), validasi ini juga harus dilakukan pada server Anda , khususnya sebelum menyerahkan data ke layanan backend.
Sumber lain tempat data harus divalidasi: dokumen pengguna, kontak, pemberitahuan push

Jangan tembolok data sensitif

Jika nama pengguna, kata sandi, informasi geolokasi, dan data sensitif lainnya di-cache, maka itu berpotensi diambil nanti oleh pengguna atau aplikasi yang tidak sah.

Jangan gunakan eval () kecuali Anda tahu apa yang Anda lakukan

Fungsi JavaScript eval () memiliki sejarah panjang disalahgunakan. Menggunakannya secara tidak benar dapat membuka kode Anda untuk serangan injeksi, kesulitan debugging, dan eksekusi kode yang lebih lambat.

Jangan berasumsi bahwa kode sumber Anda aman

Karena aplikasi Cordova dibangun dari aset HTML dan JavaScript yang dikemas dalam wadah asli, Anda tidak boleh menganggap kode Anda aman. Dimungkinkan untuk merekayasa balik aplikasi Cordova.

Tutorial Cordova Indonesia

Cari Blog Ini