Memahami kunci keamanan Java - sandbox dan otentikasi

Anda mungkin pernah mendengar tentang kelemahan terbaru dalam keamanan JDK 1.1 dan HotJava 1.0 yang baru-baru ini ditemukan oleh tim Secure Internet Programming di Universitas Princeton (dipimpin oleh salah satu penulis). Jika Anda menginginkan keseluruhan cerita, baca terus. Tetapi keamanan Java lebih dari sekadar rincian tentang celah keamanan terbaru ini. Mari kita lihat beberapa perspektif.

Keamanan Jawa dan persepsi publik

Semua orang tahu bahwa keamanan adalah masalah besar untuk Java. Setiap kali lubang keamanan ditemukan, berita tersebut akan segera menjadi berita komputer (dan terkadang berita bisnis) dengan sangat cepat. Anda mungkin tidak terkejut mengetahui bahwa pemantau pers populer terdiri dari risiko dan newsgroup terkait keamanan lainnya. Mereka memilih cerita keamanan untuk disorot secara acak, meskipun karena Java sangat panas akhir-akhir ini mereka hampir selalu mencetak cerita keamanan Java.

Masalahnya adalah bahwa kebanyakan berita tidak menjelaskan lubang tersebut dengan baik sama sekali. Hal ini dapat menyebabkan masalah klasik "serigala menangis" di mana orang menjadi terbiasa melihat "kisah keamanan minggu ini" dan tidak mendidik diri mereka sendiri tentang risiko yang sangat nyata dari konten yang dapat dijalankan. Selain itu, vendor cenderung mengecilkan masalah keamanan mereka, sehingga semakin membingungkan masalah utama.

Kabar baiknya adalah tim keamanan JavaSoft serius dalam membuat Java aman. Kabar buruknya adalah bahwa mayoritas pengembang dan pengguna Java mungkin percaya hype yang berasal dari acara seperti JavaOne di mana masalah keamanan tidak banyak diputar. Seperti yang kami katakan dalam buku kami, Java Security: Hostile Applet, Holes, & Antidotes, Sun Microsystems memiliki banyak keuntungan jika itu membuat Anda yakin Java sepenuhnya aman. Memang benar bahwa vendor telah berusaha keras untuk membuat implementasi Java mereka seaman mungkin, tetapi pengembang tidak menginginkan usaha; mereka menginginkan hasil.

Karena browser Web yang mendukung Java memungkinkan kode Java untuk disematkan di halaman Web, diunduh melalui internet, dan dijalankan pada mesin lokal, keamanan menjadi perhatian penting. Pengguna dapat mengunduh applet Java dengan sangat mudah - terkadang bahkan tanpa menyadarinya. Hal ini membuat pengguna Java menghadapi sejumlah besar risiko.

Desainer Java sangat menyadari banyak risiko yang terkait dengan konten yang dapat dieksekusi. Untuk mengatasi risiko ini, mereka merancang Java secara khusus dengan mempertimbangkan masalah keamanan. Tujuan utamanya adalah untuk mengatasi masalah keamanan secara langsung sehingga pengguna yang naif (katakanlah, mayoritas dari jutaan penjelajah Web) tidak perlu menjadi ahli keamanan hanya untuk membaca dengan teliti Web dengan aman. Ini adalah tujuan yang mengagumkan.

Tiga bagian dari kotak pasir Java

Java adalah bahasa pengembangan yang sangat kuat. Applet yang tidak dipercaya seharusnya tidak diizinkan untuk mengakses semua kekuatan ini. Kotak pasir Java membatasi applet untuk melakukan banyak aktivitas. Makalah teknis terbaik tentang pembatasan applet adalah "Keamanan Tingkat Rendah di Java" oleh Frank Yellin.

Keamanan Java bergantung pada tiga cabang pertahanan: Pemverifikasi Kode Byte, Pemuat Kelas, dan Manajer Keamanan. Bersama-sama, ketiga cabang ini melakukan pemeriksaan pemuatan dan waktu proses untuk membatasi sistem file dan akses jaringan, serta akses ke internal browser. Masing-masing cabang ini bergantung pada yang lain. Agar model keamanan berfungsi dengan baik, setiap bagian harus melakukan tugasnya dengan benar.

Pemverifikasi kode byte :

The Byte Code Verifier adalah cabang pertama dari model keamanan Java. Ketika program sumber Java dikompilasi, program tersebut dikompilasi menjadi kode byte Java yang tidak bergantung platform. Kode byte Java "diverifikasi" sebelum dapat dijalankan. Skema verifikasi ini dimaksudkan untuk memastikan bahwa kode byte, yang mungkin atau mungkin tidak dibuat oleh kompiler Java, bermain sesuai aturan. Lagi pula, kode byte bisa saja dibuat oleh "kompiler bermusuhan" yang mengumpulkan kode byte yang dirancang untuk merusak mesin virtual Java. Memverifikasi kode byte applet adalah salah satu cara di mana Java secara otomatis memeriksa kode luar yang tidak tepercaya sebelum diizinkan untuk dijalankan.Verifier memeriksa kode byte pada sejumlah level yang berbeda. Pengujian paling sederhana memastikan bahwa format fragmen kode byte sudah benar. Pada tingkat yang kurang dasar, prover teorema built-in diterapkan ke setiap fragmen kode. Prover teorema membantu untuk memastikan bahwa kode byte tidak memalsukan petunjuk, melanggar batasan akses, atau mengakses objek menggunakan informasi jenis yang salah. Proses verifikasi, bersama dengan fitur keamanan yang dibangun ke dalam bahasa melalui compiler, membantu untuk menetapkan dasar jaminan keamanan.

Pemuat kelas applet :

Cabang kedua dari pertahanan keamanan adalah Java Applet Class Loader. Semua objek Java termasuk dalam kelas. Applet Class Loader menentukan kapan dan bagaimana applet dapat menambahkan kelas ke lingkungan Java yang sedang berjalan. Bagian dari tugasnya adalah memastikan bahwa bagian penting dari lingkungan run-time Java tidak diganti dengan kode yang coba dipasang oleh applet. Secara umum, lingkungan Java yang sedang berjalan dapat memiliki banyak Pemuat Kelas yang aktif, masing-masing menentukan "ruang nama" -nya sendiri. Spasi nama memungkinkan kelas Java dipisahkan menjadi "jenis" yang berbeda sesuai dengan asalnya. Pemuat Kelas Applet, yang biasanya disediakan oleh vendor browser, memuat semua applet dan kelas yang mereka referensikan. Ketika applet dimuat di seluruh jaringan, Applet Class Loader menerima data biner dan membuat instance sebagai kelas baru.

Manajer keamanan :

Cabang ketiga dari model keamanan Java adalah Java Security Manager. Bagian dari model keamanan ini membatasi cara applet menggunakan antarmuka yang terlihat. Dengan demikian, Manajer Keamanan mengimplementasikan sebagian besar dari keseluruhan model keamanan. Manajer Keamanan adalah modul tunggal yang dapat melakukan pemeriksaan waktu proses pada metode "berbahaya". Kode di perpustakaan Java berkonsultasi dengan Manajer Keamanan setiap kali operasi berbahaya akan dicoba. Manajer Keamanan diberi kesempatan untuk memveto operasi tersebut dengan membuat Pengecualian Keamanan (kutukan bagi pengembang Java di mana-mana). Keputusan yang dibuat oleh Manajer Keamanan memperhitungkan Class Loader mana yang memuat kelas yang meminta. Kelas built-in diberikan lebih banyak hak daripada kelas yang telah dimuat melalui internet.

Tidak dipercaya dan dibuang ke kotak pasir

Bersama-sama, tiga bagian dari model keamanan Java membentuk kotak pasir. Idenya adalah untuk membatasi apa yang dapat dilakukan applet dan memastikannya bermain sesuai aturan. Ide kotak pasir menarik karena dimaksudkan untuk memungkinkan Anda menjalankan kode tidak tepercaya di komputer Anda tanpa mengkhawatirkannya. Dengan cara itu Anda dapat menjelajahi web tanpa hukuman, menjalankan setiap applet Java yang pernah Anda temui tanpa masalah keamanan. Nah, selama sandbox Java tidak memiliki lubang pengaman.

Alternatif untuk kotak pasir:

Otentikasi melalui penandatanganan kode

ActiveX adalah bentuk profil tinggi dari konten yang dapat dieksekusi. Dipromosikan oleh Microsoft, ActiveX telah dikritik oleh para profesional keamanan komputer yang menganggap pendekatan keamanannya kurang. Berbeda dengan situasi keamanan Java, di mana applet dibatasi oleh kontrol perangkat lunak dalam hal-hal yang dapat dilakukannya, kontrol ActiveX tidak memiliki batasan pada perilakunya setelah dipanggil. Hasilnya adalah bahwa pengguna ActiveX harus sangat berhati-hati untuk menjalankan hanya kode tepercaya sepenuhnya. Pengguna Java, sebaliknya, memiliki kemewahan menjalankan kode tidak tepercaya dengan cukup aman.

Pendekatan ActiveX bergantung pada tanda tangan digital, sejenis teknologi enkripsi di mana file biner arbitrer dapat "ditandatangani" oleh pengembang atau distributor. Karena tanda tangan digital memiliki sifat matematika khusus, tanda tangan itu tidak dapat dibatalkan dan tidak dapat dipalsukan. Artinya, program seperti browser Anda dapat memverifikasi tanda tangan, sehingga Anda dapat memastikan siapa yang menjamin kode tersebut. (Setidaknya, itulah teorinya. Hal-hal yang sedikit lebih ambigu dalam kehidupan nyata.) Lebih baik lagi, Anda dapat menginstruksikan browser Anda untuk selalu menerima kode yang ditandatangani oleh beberapa pihak yang Anda percayai, atau selalu menolak kode yang ditandatangani oleh beberapa pihak yang Anda jangan percaya.

Tanda tangan digital menyimpan banyak informasi. Misalnya, ini dapat memberi tahu Anda bahwa meskipun beberapa kode sedang didistribusikan ulang oleh situs yang tidak Anda percayai, kode ini aslinya ditulis oleh seseorang yang Anda percayai. Atau dapat memberi tahu Anda bahwa meskipun kode tersebut ditulis dan didistribusikan oleh seseorang yang tidak Anda kenal, teman Anda telah menandatangani kode tersebut, yang membuktikan bahwa kode tersebut aman. Atau mungkin hanya memberitahu Anda yang mana dari ribuan pengguna di aol.com yang menulis kode tersebut.

(Lihat bilah sisi untuk detail lebih lanjut tentang tanda tangan digital, termasuk lima properti utama.)

Masa depan konten yang dapat dieksekusi: Meninggalkan kotak pasir

Apakah tanda tangan digital membuat ActiveX lebih menarik dari segi keamanan daripada Java? Kami percaya tidak, terutama mengingat fakta bahwa kemampuan tanda tangan digital sekarang tersedia di JDK 1.1.1 Java (bersama dengan peningkatan keamanan lainnya). Itu berarti di Java, Anda mendapatkan semua yang dilakukan ActiveX untuk keamanan ditambah kemampuan untuk menjalankan kode tidak tepercaya dengan cukup aman. Keamanan Java akan ditingkatkan lebih jauh lagi di masa mendatang dengan kontrol akses yang fleksibel dan halus, yang menurut Li Gong, arsitek keamanan Java JavaSoft, direncanakan untuk dirilis di JDK 1.2. Kontrol akses yang lebih baik juga akan masuk ke putaran browser berikutnya, termasuk Netscape Communicator dan MicroSoft Internet Explorer 4.0.

Bersamaan dengan kontrol akses, penandatanganan kode akan memungkinkan applet untuk keluar dari sandbox keamanan secara bertahap. Misalnya, applet yang dirancang untuk digunakan dalam pengaturan Intranet dapat diizinkan untuk membaca dan menulis ke database perusahaan tertentu selama itu ditandatangani oleh administrator sistem. Relaksasi model keamanan seperti itu penting bagi pengembang yang mengunyah sedikit agar applet mereka dapat berbuat lebih banyak. Menulis kode yang bekerja dalam batasan ketat kotak pasir sangat merepotkan. Kotak pasir asli sangat ketat.

Akhirnya, applet akan mendapatkan tingkat kepercayaan yang berbeda. Karena ini memerlukan kontrol akses, nuansa kepercayaan saat ini tidak tersedia meskipun penandatanganan kode tersedia. Seperti yang saat ini berdiri di JDK 1.1.1, applet Java benar-benar tepercaya atau sama sekali tidak tepercaya. Applet bertanda tangan yang ditandai sebagai tepercaya diizinkan keluar dari kotak pasir sepenuhnya. Applet semacam itu dapat melakukan apa saja dan tidak memiliki batasan keamanan.

Masalah utama dengan pendekatan keamanan Java adalah rumit. Sistem yang rumit cenderung memiliki lebih banyak kekurangan daripada sistem sederhana. Peneliti keamanan, terutama tim Secure Internet Programming dari Princeton, telah menemukan beberapa kelemahan keamanan yang serius pada sandbox versi awal. Banyak dari kekurangan ini adalah kesalahan implementasi, tetapi beberapa kesalahan spesifikasi. Untungnya, JavaSoft, Netscape, dan Microsoft dengan sangat cepat memperbaiki masalah seperti itu ketika ditemukan. (Penjelasan yang jelas dan lengkap tentang lubang keamanan Java dapat ditemukan di Bab 3 buku kami.)

Baru-baru ini, para pemasar Sun (terkadang disebut penginjil) dengan cepat menunjukkan bahwa tidak ada kekurangan baru yang ditemukan dalam beberapa waktu. Mereka menganggap ini sebagai bukti bahwa Jawa tidak akan pernah lagi mengalami masalah keamanan. Mereka melompat dari pistol.

Lubang penandatanganan kode: Java mengupas lututnya

Penandatanganan kode itu rumit. Seperti pada model kotak pasir asli, ada banyak ruang untuk kesalahan dalam merancang dan mengimplementasikan sistem penandatanganan kode. Lubang baru-baru ini adalah masalah yang cukup jelas dalam implementasi Classkelas Java , seperti yang dijelaskan di situs Princeton dan situs keamanan JavaSoft. Secara khusus, metode ini Class.getsigners()mengembalikan larik yang bisa berubah dari semua penanda tangan yang dikenal oleh sistem. Ada kemungkinan applet menyalahgunakan informasi ini. Perbaikannya sesederhana mengembalikan hanya salinan larik, dan bukan larik itu sendiri.

Pertimbangkan situasi di mana pengembang, Alice, tidak diberikan hak keamanan pada sistem pengguna Web. Faktanya, bertentangan dengan pernyataan JavaSoft asli tentang bug yang diklaim, Alice bisa jadi sama sekali tidak dikenal oleh sistem. Dengan kata lain, kode yang ditandatangani oleh Alice tidak dipercayai seperti applet biasa di jalan. Jika pengguna Web (menggunakan browser HotJava - saat ini satu-satunya produk komersial yang mendukung JDK 1.1.1) memuat applet yang ditandatangani oleh Alice, applet tersebut masih dapat keluar dari kotak pasir dengan mengeksploitasi lubang.

Fakta bahwa sistem tidak perlu memiliki kunci publik Alice dalam basis datanya adalah penting. Ini berarti bahwa Alice dapat menjadi penyerang sewenang-wenang yang tahu cara menandatangani applet dengan identitas yang benar-benar acak. Membuat identitas seperti itu mudah, seperti menandatangani applet dengan identitas itu. Ini memang membuat lubang itu sangat serius.

Lubang tersebut memungkinkan applet serangan Alice untuk mengubah ide sistem tentang siapa yang menandatanganinya. Ini sangat buruk jika Alice tidak diberikan hak istimewa untuk berjalan di luar kotak pasir, tetapi Bob diberikan. Applet Alice dapat menggunakan getsigners()panggilan tersebut untuk mengubah tingkat izinnya untuk menyertakan semua hak istimewa Bob. Applet Alice dapat memperoleh jumlah maksimum hak istimewa yang tersedia yang dibagikan kepada penanda tangan mana pun yang dikenal oleh sistem.

Jika Anda menyamakan identitas tanda tangan / hak istimewa dengan mantel di lemari, applet serangan Alice dapat mencoba setiap mantel dan mencoba berbagai hal yang tidak diizinkan sampai menemukan mantel mana yang "ajaib" dan memungkinkannya untuk mendapatkan hak istimewa. Jika mantel ajaib ditemukan, applet Alice dapat keluar dari kotak pasir dan melakukan hal-hal yang tidak boleh dilakukan. Mencoba mantel itu semudah mencoba menelepon yang tidak diizinkan dan melihat apa yang terjadi.