Mengapa perlu menguji aplikasi untuk kondisi balapan

Jika aplikasi atau layanan Anda beroperasi dengan mata uang internal, Anda harus mengujinya untuk mengetahui kerentanan kondisi balapan ("kondisi balapan" atau, lebih tepatnya, "ketidakpastian konkurensi"). Kondisi balapan merupakan "bug mengambang" yang dapat dimanfaatkan oleh penyerang. Intinya adalah, berkat eksekusi kode paralel, Anda dapat mengakses mata uang internal aplikasi, memanipulasinya, dan, jika diinginkan, menyebabkan kerugian finansial yang nyata bagi pemilik layanan. Kami baru-baru ini menemukan masalah ini dengan salah satu klien kami dan membantu mengatasinya.







Apa itu kondisi balapan



Karena pengembang sering lupa bahwa kode dapat dieksekusi oleh beberapa utas secara bersamaan, mereka tidak menguji produk untuk kondisi balapan, meskipun kesalahan ini cukup umum.



Dari sudut pandang backend, terlihat seperti ini: beberapa utas mengakses sumber daya bersama yang sama secara bersamaan: variabel atau file yang tidak ada pemblokiran atau sinkronisasi. Hal ini menyebabkan keluaran data yang tidak konsisten.



Berikut adalah contoh konkret dari kerentanan tersebut. Katakanlah kami memiliki aplikasi yang memungkinkan Anda mentransfer bonus antar dompet pembayaran. Penyerang memiliki dua dompet - A dan B, dan masing-masing memiliki 1000 bonus. Diagram menunjukkan bagaimana dengan memanipulasi waktu pengiriman permintaan transaksi, penyerang dapat meningkatkan jumlah transfer ke akunnya dan mendapatkan 10 bonus dari 20.







Ada alat otomatis untuk mencari kerentanan tersebut. Misalnya, RacePWN, yang dalam waktu minimum mengirimkan banyak permintaan HTTP ke server dan menerima konfigurasi json sebagai input, memfasilitasi proses penyerangan bagi penjahat dunia maya. Ini dilakukan secara manual dengan mengirimkan permintaan POST.



Kondisi balapan yang mematikan



Di Amerika Serikat, dari Juni 1985 hingga Januari 1987, kesalahan kondisi balapan dalam mesin terapi radiasi Therac-25 yang dibuat oleh organisasi negara Kanada Atomic Energy of Canada Limited (AECL) menyebabkan enam kali overdosis radiasi . Para korban menerima dosis kegembiraan puluhan ribu. Level 1000 dianggap mematikan. Setelah luka bakar yang diakibatkan, korban meninggal dalam beberapa minggu. Hanya satu pasien yang berhasil selamat.



Model Therac sebelumnya memiliki mekanisme perlindungan perangkat keras: sirkuit pemblokiran independen yang mengontrol berkas elektron; penghambat mekanis; pemutus sirkuit perangkat keras; melepaskan sekring. Perlindungan perangkat keras telah dihapus di Therac-25. Perangkat lunak bertanggung jawab atas keamanan. Perangkat memiliki beberapa mode operasi, dan karena kesalahan kondisi balapan, dokter terkadang tidak mengerti dalam mode mana perangkat benar-benar berfungsi. Dalam proses persidangan, ternyata software Therac-25 dikembangkan oleh satu programmer, namun AECL tidak memiliki informasi tentang siapa sebenarnya.



Sebagai hasil dari proses tersebut, pemerintah AS telah secara serius memperketat persyaratan untuk desain dan pengoperasian sistem yang keselamatannya sangat penting bagi manusia.



Bagaimana melindungi diri sendiri



Cara termudah dan termurah untuk mengatasi masalah kondisi balapan adalah dengan merancang arsitektur aplikasi dengan benar. Inilah yang harus diramalkan untuk ini.



  • Mengunci catatan penting dalam database. Ada berbagai cara untuk memastikan bahwa Anda bekerja dengan merekam satu aliran pada titik waktu tertentu. Hal utama adalah jangan memblokir apa pun yang tidak perlu.
  • Isolasi transaksi dalam database , yang memastikan bahwa transaksi dilakukan secara berurutan. Hal terpenting di sini adalah menjaga keseimbangan antara keamanan dan kecepatan.
  • . . , , , . , , , .




Klien kami adalah toko pengiriman bahan makanan online yang mendukung fungsi pemberian diskon menggunakan kupon. Selama pengujian, kami menemukan kerentanan - saat mengirim permintaan POST dengan nilai kupon. Dengan mengirimkan permintaan dengan penundaan waktu yang berbeda, dimungkinkan untuk mendapatkan diskon dua kali. Rupanya, pengembang membuat kesalahan besar terkait akses bersama ke objek yang diidentifikasi dengan pembelian tersebut.



Kemungkinan besar ada pseudocode tanpa mekanisme sinkronisasi:

…

1 Jika promo_flag tidak disetel:

2 Price = get_price ()

3 Price - = price * promo_percent;

4 set_price (harga)

5 set_promo_flag ()

...

Di sini, menerapkan kode promo dan menyetel bendera yang sesuai bukanlah operasi atomik. Kemungkinan besar, saat penerapan kedua kode promosi dimulai, yang pertama berhenti pada baris ke-5 (artinya, belum dijalankan). Saat ini, fungsi get_price () di baris kedua mengembalikan nilai harga baru, sudah dengan diskon.



Keputusan



Masalahnya diselesaikan dengan sederhana:

…

1 acqure_mutex ()

2 Jika promo_flag tidak disetel:

3 Price = get_price ()

4 Price - = price * promo_percent;

5 set_price (price)

6 set_promo_flag ()

7 release_mutex ()

...

Sekarang, penerapan kode promo akan dilakukan secara lengkap dan lengkap satu kali. Bahkan ketika muncul situasi di mana utas kedua mencoba menerapkan kode promo sementara proses pertama sudah sibuk dengan pemrosesan, itu tidak akan dapat melakukannya. Mutex akan memblokir akses ke "bagian kritis", dan proses kedua harus menunggu sampai yang pertama selesai.



Kondisi balapan tidak boleh dianggap remeh. Lebih baik menghabiskan waktu dan sumber daya untuk mencari kerentanan untuk menghindari konsekuensi yang tidak terduga, termasuk untuk anggaran perusahaan.






Blog ITGLOBAL.COM - Managed IT, private cloud, IaaS, layanan keamanan informasi untuk bisnis:






All Articles