Serangan SQL Injection menimbulkan risiko yang luar biasa terhadap aplikasi web yang bergantung pada backend pangkalan data untuk menghasilkan kandungan dinamik. Dalam jenis serangan ini, penggodam memanipulasi aplikasi web dalam usaha untuk menyuntik arahan SQL sendiri ke dalam yang dikeluarkan oleh pangkalan data. Sebagai contoh, lihat artikel Serangan Suntikan SQL pada Pangkalan Data. Dalam artikel ini, kita melihat beberapa cara anda boleh menguji aplikasi web anda untuk menentukan sama ada mereka terdedah kepada serangan SQL Injection.
Pengimbasan Suntikan SQL Automatik
Satu kemungkinan menggunakan pengimbas kelemahan aplikasi web automatik, seperti WebInspect HP, AppScan IBM atau Hailstorm Cenzic. Alat ini semua menawarkan cara yang mudah dan automatik untuk menganalisis aplikasi web anda untuk kelemahan SQL Suntingan yang berpotensi. Walau bagaimanapun, mereka agak mahal, berjalan sehingga $ 25,000 setiap kerusi.
Ujian Suntikan SQL Manual
Apakah pemaju aplikasi miskin yang perlu dilakukan? Anda sebenarnya boleh menjalankan beberapa ujian asas untuk menilai aplikasi web anda untuk kelemahan SQL Injection menggunakan tidak lebih daripada pelayar web. Pertama, satu kata yang berhati-hati: ujian yang saya huraikan hanya mencari kelemahan SQL Injection asas. Mereka tidak akan mengesan teknik lanjutan dan agak membosankan untuk digunakan. Sekiranya anda mampu, pergi dengan pengimbas automatik. Walau bagaimanapun, jika anda tidak dapat mengendalikan tag harga itu, ujian manual adalah langkah pertama yang hebat.
Cara paling mudah untuk menilai sama ada aplikasi terdedah adalah untuk mencuba dengan serangan suntikan tidak berbahaya yang tidak akan benar-benar merosakkan pangkalan data anda jika berjaya tetapi akan memberikan anda bukti yang anda perlukan untuk membetulkan masalah. Contohnya, katakan anda mempunyai aplikasi web mudah yang mencari individu dalam pangkalan data dan memberikan maklumat hubungan sebagai hasilnya. Halaman tersebut mungkin menggunakan format URL berikut:
Kita boleh mengandaikan bahawa laman ini melakukan carian pangkalan data, menggunakan pertanyaan yang serupa dengan yang berikut:
PILIH telefon FROM directory WHERE lastname = 'chapple' dan firstname = 'mike'Mari bereksperimen dengan ini sedikit. Dengan anggapan kami di atas, kami boleh membuat perubahan mudah ke URL yang menguji serangan suntikan SQL:
http://myfakewebsite.com/directory.asp?lastname=chapple&firstname=mike'+AND+(select+count(*)+from+fake)+%3e0+OR+'1'%3d'1Jika aplikasi web tidak dilindungi dengan betul daripada suntikan SQL, ia hanya memasukkan nama pertama palsu ini ke dalam pernyataan SQL yang dijalankan terhadap pangkalan data, yang mengakibatkan:
PILIH telefon FROM directory WHERE lastname = 'chapple' dan firstname = 'mike' AND (pilih count (*) from fake)> 0 OR '1' = '1'Anda akan perhatikan bahawa sintaks di atas adalah sedikit berbeza daripada itu di URL asal. Saya mengambil kebebasan untuk menukar pembolehubah yang dikodkan URL untuk kesetaraan ASCII untuk memudahkan untuk mengikuti contoh. Sebagai contoh,% 3d adalah pengekodan URL untuk watak '='. Saya juga menambah beberapa rehat garis untuk tujuan yang sama.
Menilai Keputusan
Ujian ini datang apabila anda cuba memuat halaman web dengan URL yang disenaraikan di atas. Jika aplikasi web berkelakuan baik, ia akan mengeluarkan petikan tunggal dari input sebelum menghantar pertanyaan ke pangkalan data. Ini hanya akan menghasilkan carian aneh bagi seseorang yang mempunyai nama pertama yang termasuk sekumpulan SQL! Anda akan melihat mesej ralat dari aplikasi yang serupa dengan yang berikut:
Ralat: Tiada pengguna yang dijumpai dengan nama mike + AND + (pilih + mengira (*) + dari + palsu) +% 3e0 + OR + 1% 3d1 Chapple!Sebaliknya, jika aplikasi terdedah kepada suntikan SQL, ia akan lulus kenyataan terus ke pangkalan data, yang menghasilkan satu daripada dua kemungkinan. Pertama, jika pelayan anda mempunyai mesej ralat terperinci yang telah diaktifkan (yang tidak seharusnya!), Anda akan melihat sesuatu seperti ini:
Pembekal OLE DB Microsoft untuk ralat Pemandu ODBC '80040e37' [Microsoft] [Pemandu ODBC SQL Server] [SQL Server] Nama objek tidak sah 'palsu'. /directory.asp, baris 13Sebaliknya, jika pelayan web anda tidak memaparkan mesej ralat terperinci, anda akan mendapat ralat yang lebih umum, seperti:
Ralat Pelayan Dalaman Pelayan menghadapi ralat dalaman atau konfigurasi salah dan tidak dapat menyelesaikan permintaan anda. Sila hubungi pentadbir pelayan untuk memaklumkan masa ralat berlaku dan apa-apa yang anda mungkin lakukan yang mungkin menyebabkan ralat. Maklumat lanjut mengenai ralat ini boleh didapati dalam log kesalahan pelayan.Jika anda menerima salah satu daripada dua kesilapan di atas, aplikasi anda terdedah kepada serangan suntikan SQL! Beberapa langkah yang boleh anda ambil untuk melindungi aplikasi anda daripada serangan SQL Injection termasuk:
- Melaksanakan pemeriksaan parameter pada semua aplikasi. Contohnya, jika anda meminta seseorang memasukkan nombor pelanggan, pastikan inputnya berangka sebelum melaksanakan pertanyaan .
- Hadkan keizinan akaun yang menjalankan pertanyaan SQL . Peraturan keistimewaan sekurang-kurangnya berlaku. Jika akaun yang digunakan untuk melaksanakan pertanyaan tidak mempunyai kebenaran untuk melaksanakannya, ia tidak akan berhasil!
- Gunakan prosedur tersimpan (atau teknik yang serupa) untuk menghalang pengguna daripada berinteraksi secara langsung dengan kod SQL.