Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Ruby

Penugasan Massal, Rails, dan Anda

by
Read Time:7 minsLanguages:

Indonesian (Bahasa Indonesia) translation by Rossie (you can also view the original English article)

Pada awal 2012, seorang developer, bernama Egor Homakov, mengambil keuntungan dari lubang keamanan di Github (aplikasi Rails) untuk mendapatkan akses komit ke proyek Rails.

Maksudnya adalah sebagian besar untuk menunjukkan masalah keamanan umum dengan banyak aplikasi Rails yang dihasilkan dari fitur, yang dikenal sebagai penugasan massal (dan melakukannya dengan agak keras). Dalam artikel ini, kita akan meninjau apa tugas massal itu, bagaimana itu bisa menjadi masalah, dan apa yang dapat Anda lakukan tentang hal itu dalam aplikasi Anda sendiri.


Apa itu Penugasan Massal?

Untuk memulai, pertama mari kita lihat apa arti penugasan massal, dan mengapa itu ada. Sebagai contoh, bayangkan kita memiliki kelas User berikut dalam aplikasi kita:

Tugas massal memungkinkan kita untuk mengatur banyak atribut sekaligus:

Tanpa kemudahan penugasan massal, kita harus menulis pernyataan penugasan untuk setiap atribut untuk mencapai hasil yang sama. Ini sebuah contoh:

Jelas, ini bisa membosankan dan menyakitkan; jadi kita tunduk pada kaki kemalasan dan berkata, ya, tugas massal adalah hal yang baik.


Masalah (Potensial) Dengan Penugasan Massal

Salah satu masalah dengan sharp tools adalah Anda dapat memotongnya sendiri.

Tapi tunggu! Salah satu masalah dengan sharp tools adalah Anda dapat memotongnya sendiri. Tugas massal tidak terkecuali dalam aturan ini.

Anggaplah sekarang bahwa aplikasi imajiner kecil kita telah memperoleh kemampuan untuk menembakkan rudal. Karena tidak ingin dunia berubah menjadi abu, kita menambahkan bidang izin boolean ke model User untuk memutuskan siapa yang dapat menembakkan rudal.

Mari kita juga berasumsi bahwa kita memiliki cara bagi pengguna untuk mengedit informasi kontak mereka: ini mungkin suatu bentuk di suatu tempat yang dapat diakses oleh pengguna dengan bidang teks untuk nama depan, nama belakang, dan alamat email pengguna.

Teman kita John Doe memutuskan untuk mengubah namanya dan memperbarui akun emailnya. Saat dia mengirimkan formulir, browser akan mengeluarkan permintaan yang mirip dengan yang berikut:

Tindakan update dalam UsersController mungkin terlihat seperti:

Diberikan permintaan contoh, hash params akan terlihat mirip dengan:

Sekarang katakanlah NewJohn sedikit licik. Anda tidak perlu peramban untuk mengeluarkan permintaan HTTP, jadi dia menulis skrip yang mengeluarkan permintaan berikut:

Bidang, seperti :admin, :pemilik, dan :public_key, cukup mudah ditebak.

Ketika permintaan ini mengenai tindakan update kita, panggilan update_attributes akan melihat {:can_fire_missiles => true}, dan memberi NewJohn kemampuan untuk menembakkan rudal! Celakalah kita.

Inilah tepatnya bagaimana Egor Homakov memberi dirinya memberikan akses ke proyek Rails. Karena Rails sangat padat dengan konvensi, bidang-bidang seperti :admin, :owner, dan :public_key cukup mudah ditebak. Lebih lanjut, jika tidak ada perlindungan di tempat, Anda bisa mendapatkan akses ke hal-hal yang seharusnya tidak bisa Anda sentuh.


Cara Menangani Penugasan Massal

Jadi bagaimana kita melindungi diri dari penugasan massal yang ceroboh? Bagaimana kita mencegah NewJohns dunia menembakkan misil kita dengan sembrono?

Untungnya, Rails menyediakan beberapa tool untuk mengelola masalah ini: attr_protected dan attr_accessible.

attr_protected: BlackList

Dengan menggunakan attr_protected, Anda dapat menentukan bidang mana yang mungkin tidak pernah ditetapkan secara mass-ly:

Sekarang, setiap upaya untuk menetapkan secara massal atribut can_fire_missiles akan gagal.

attr_accessible: WhiteList

Masalah dengan attr_protected adalah terlalu mudah untuk lupa menambahkan bidang yang baru diterapkan ke daftar.

Di sinilah attr_accessible masuk. Seperti yang Anda duga, ini kebalikan dari attr_protected: hanya daftarkan atribut yang ingin Anda tetapkan secara massal.

Dengan demikian, kita dapat mengalihkan kelas User ke pendekatan ini:

Di sini, kita secara eksplisit mencantumkan apa yang dapat ditetapkan secara massal. Segala sesuatu yang lain akan dianulir. Keuntungan di sini adalah bahwa jika kita, katakanlah, menambahkan bendera admin ke model User, itu akan secara otomatis aman dari penugasan massal.

Sebagai aturan umum, Anda harus memilih attr_accessible daripada attr_protected, karena membantu Anda berbuat salah di sisi kehati-hatian.

Peran Penugasan Massal

Rails 3.1 memperkenalkan konsep "peran" penugasan massal. Idenya adalah Anda dapat menentukan daftar attr_protected dan attr_accessible yang berbeda untuk situasi yang berbeda.

Konfigurasi Seluruh Aplikasi

Anda dapat mengontrol perilaku penugasan massal dalam aplikasi Anda dengan mengedit pengaturan config.active_record.whitelist_attributes dalam file config/application.rb.

Jika disetel ke false, proteksi penugasan massal hanya akan diaktifkan untuk model tempat Anda menentukan attr_protected atau attr_accessible list.

Jika disetel ke true, penugasan massal tidak akan mungkin untuk semua model kecuali mereka menentukan daftar attr_protected atau attr_accessible. Harap dicatat bahwa opsi ini diaktifkan secara default dari Rails 3.2.3 ke depan.

Kekerasan

Dimulai dengan Rails 3.2, ada juga opsi konfigurasi untuk mengontrol kerasnya perlindungan penetapan massa: config.active_record.mass_assignment_sanitizer.

Jika disetel ke :strict, ini akan memunculkan ActiveModel::MassAssignmentSecurity::Error kapan saja ketika aplikasi Anda mencoba untuk menetapkan secara massal sesuatu yang tidak seharusnya. Anda harus menangani kesalahan ini secara eksplisit. Pada v3.2, opsi ini ditetapkan untuk Anda di lingkungan pengembangan dan pengujian (tetapi bukan produksi), mungkin untuk membantu Anda melacak di mana masalah penugasan massal mungkin.

Jika tidak disetel, ia akan menangani perlindungan penugasan massal secara diam-diam - artinya hanya akan menetapkan atribut yang seharusnya, tetapi tidak akan menimbulkan kesalahan.


Rails 4 Parameter Kuat: Pendekatan Yang Berbeda

Keamanan penugasan massal benar-benar tentang penanganan input yang tidak dipercaya.

Insiden Homakov mengawali percakapan seputar perlindungan penugasan massal di komunitas Rails (dan selanjutnya ke bahasa lain, juga); sebuah pertanyaan menarik muncul: apakah keamanan penugasan massal termasuk dalam layer model?

Beberapa aplikasi memiliki persyaratan otorisasi yang kompleks. Mencoba untuk menangani semua kasus khusus di lapisan model dapat mulai terasa kikuk dan terlalu rumit, terutama jika Anda menemukan diri Anda plester roler di semua tempat.

Wawasan utama di sini adalah bahwa keamanan penugasan massal benar-benar menangani input yang tidak dipercaya. Sebagai aplikasi Rails menerima input pengguna di controller layer, developers mulai bertanya-tanya apakah mungkin lebih baik untuk menangani masalah di sana daripada model ActiveRecord.

Hasil diskusi ini adalah permata Parameter Kuat, tersedia untuk digunakan dengan Rails 3, dan default dalam rilis Rails 4 mendatang.

Dengan asumsi bahwa aplikasi missile kita dibangun di Rails 3, berikut cara memperbaruinya untuk digunakan dengan permata parameter kuat:

Tambahkan gem

Tambahkan baris berikut ke Gemfile:

Matikan perlindungan penugasan massal berbasis model

Dalam config/application.rb:

Beri tahu model tentang hal itu

Perbarui controllers

Sekarang, jika Anda mencoba sesuatu seperti user.update_attributes(params), Anda akan mendapatkan kesalahan dalam aplikasi Anda. Anda harus terlebih dahulu memanggil permit pada hasrat params dengan kunci yang diizinkan untuk tindakan tertentu.

Keuntungan dari pendekatan ini adalah Anda harus secara eksplisit tentang input mana yang Anda terima pada saat Anda berurusan dengan input tersebut.

Catatan: Jika ini adalah aplikasi Rails 4, hanya diperlukan kode pengontrol; fungsi parameter yang kuat akan dipanggang secara default. Akibatnya, Anda tidak perlu menyertakannya dalam model atau permata terpisah di Gemfile.


Penutupan

Penugasan massal dapat menjadi fitur yang sangat berguna saat menulis kode Rails. Bahkan, hampir tidak mungkin untuk menulis kode Rails yang masuk akal tanpa itu. Sayangnya, penugasan massa yang tidak ada artinya juga penuh dengan bahaya.

Semoga, Anda sekarang dilengkapi dengan tool yang diperlukan untuk bernavigasi dengan aman di perairan penugasan massal. Ini untuk rudal yang lebih sedikit!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.