| Artikel atau sebagian dari artikel ini mungkin diterjemahkan dari SQL injection di en.wikipedia.org. Isinya masih belum akurat, karena bagian yang diterjemahkan masih perlu diperhalus dan disempurnakan. Jika Anda menguasai bahasa aslinya, harap pertimbangkan untuk menelusuri referensinya dan menyempurnakan terjemahan ini. Anda juga dapat ikut bergotong royong pada ProyekWiki Perbaikan Terjemahan.
(Pesan ini dapat dihapus jika terjemahan dirasa sudah cukup tepat. Lihat pula: panduan penerjemahan artikel) |
Injeksi SQL (Bahaasa Inggris: SQL Injection)adalah sebuah teknik yang menyalahgunakan sebuah celah keamanan yang terjadi dalam lapisan basis data sebuah aplikasi. Celah ini terjadi ketika masukan pengguna tidak disaring secara benar dari karakter-karakter pelolos bentukan string yang diimbuhkan dalam pernyataan SQL atau masukan pengguna tidak bertipe kuat dan karenanya dijalankan tidak sesuai harapan. Ini sebenarnya adalah sebuah contoh dari sebuah kategori celah keamanan yang lebih umum yang dapat terjadi setiap kali sebuah bahasa pemrograman atau skrip diimbuhkan di dalam bahasa yang lain.
Bentuk-bentuk celah keamanan injeksi SQL
Karakter-karakter pelolos yang tidak disaring secara benar
Bentuk injeksi SQL ini terjadi ketika masukan pengguna tidak disaring dari karakter-karakter pelolos dan kemudian diteruskan ke dalam sebuah pernyataan SQL. Ini menimbulkan potensi untuk memanipulasi pernyataan-pernyataan yang dilakukan pada basis data oleh pengguna akhir aplikasi.
Baris kode berikut menggambarkan celah keamanan ini:
pernyataan:= "SELECT * FROM pengguna WHERE nama = '" + namaPengguna + "';"
Jika variabel "namaPengguna" dirangkai sedemikian rupa oleh pengguna yang bermaksud buruk, pernyataan SQL tersebut bisa melakukan lebih daripada yang pengarangnya maksudkan. Sebagai contoh, mengeset variabel "namaPengguna" sebagai
a' or 't'='t
menjadikan pernyataan SQL ini oleh bahasa yang memuatnya:
SELECT * FROM pengguna WHERE nama = 'a' or 't'='t';
Jika kode ini akan digunakan dalam sebuah prosedur untuk melakukan otentikasi, maka contoh ini dapat dipakai untuk memaksakan pemilihan sebuah nama pengguna yang sah karena evaluasi 't'='t' akan selalu bernilai benar.
Secara teori, perintah SQL sah apapun bisa diinjeksi melalui metode ini, termasuk menjalankan banyak pernyataan. Nilai "namaPengguna" berikut ini pada pernyataan di atas akan menyebabkan dihapusnya tabel "pengguna" dan juga pengambilan semua data dari tabel "data":
a';DROP TABLE pengguna; SELECT * FROM data WHERE nama LIKE '%
Masukan ini menjadikan pernyataan akhir SQL sebagai berikut:
SELECT * FROM pengguna WHERE nama = 'a';DROP TABLE pengguna; SELECT * FROM data WHERE nama LIKE '%';
Penanganan tipe yang tidak benar
Bentuk injeksi SQL ini terjadi ketika sebuah unsur masukan pengguna tidak bertipe kuat atau tidak diperiksa batasan-batasan tipenya. Ini dapat terjadi ketika sebuah unsur numerik akan digunakan dalam sebuah pernyataan SQL, tetapi pemrogram tidak melakukan pemeriksaan untuk memastikan bahwa masukan pengguna adalah numerik. Sebagai contoh:
pernyataan:= "SELECT * FROM data WHERE id = " + variabel_a + ";"
Terlihat jelas dari pernyataan ini pengarang memaksudkan variabel_a menjadi sebuah nomor yang berhubungan dengan unsur "id". Namun begitu, jika pada kenyataannya itu adalah sebuah string, maka pengguna akhir dapat memanipulasi pernyataan tersebut sesukanya, dan karena itu mengabaikan kebutuhan akan karakter-karakter pelolos. Sebagai contoh, mengeset variabel_a sebagai
1;DROP TABLE pengguna
akan menghapus tabel "pengguna" dari basis data karena hasil akhir SQL-nya akan menjadi sebagai berikut:
SELECT * FROM data WHERE id = 1;DROP TABLE pengguna;
Celah keamanan dalam server basis data
Terkadang celah-celah keamanan dapat berada dalam perangkat lunak server basis data itu sendiri, seperti yang terjadi pada fungsi-fungsi real_escape_chars() di server MySQL.[butuh rujukan]
Mengamankan aplikasi terhadap injeksi SQL
Perbaikan aplikasi
Injeksi SQL dapat dengan mudah diatasi dalam kebanyakan bahasa pemrograman yang menargetkan aplikasi web atau menawarkan fungsi. Dalam DBI di Perl, metode DBI::quote meloloskan karakter-karakter khusus (anggaplah variabel $sql menyimpan referensi ke sebuah objek DBI):
$kueri = $sql->prepare
(
"select * from pengguna where nama = "
.
$sql->quote($nama_pengguna)
);
Namun begitu, secara umum ini bukan jalan yang terbaik dalam menghadapi masalah tersebut. DBI mengizinkan penggunaan placeholder, yang memperbolehkan Anda untuk mengikat data ke sebuah pernyataan secara terpisah dari pendefinisian pernyataan SQL tersebut. Untuk sistem basis data yang tidak secara asli mendukung placeholder, DBI menirukannya dengan menggunakan fungsi DBI::quote secara otomatis pada nilai-nilai. Banyak sistem basis data yang mendukung pengikatan nilai secara terpisah melalui API mereka; DBI akan menggunakan dukungan placeholder asli tersebut dalam hal ini. Sebagai contoh:
$kueri = $sql->prepare("select * from pengguna where nama = ?");
$kueri->execute($nama_pengguna);
Keuntungannya adalah Anda tidak perlu mengingat untuk menggunakan DBI::quote kepada setiap nilai. Nilai-nilai akan diikat secara terpisah, atau dikutip secara benar, tergantung pada dukungan yang ditawarkan oleh SMBD tertentu yang Anda gunakan. Anda kemudian terhindari dari masalah dasar injeksi SQL di mana nilai-nilai diinterpretasi sebagai SQL.
Bagi sistem basis data yang mendukung placeholder secara asli, sering kali ada keuntungan kinerja yang nyata untuk menggunakan placeholder, karena basis data dapat menyimpan cache dari sebuah perwakilan pernyataan yang terkompilasi dan menggunakannya secara berulang di antara pelaksanaan-pelaksanaan dengan nilai-nilai ikatan yang berbeda. Placeholder kadang-kadang juga disebut sebagai "variabel pengikat".
Dalam PHP, terdapat beberapa fungsi bawaan yang berbeda untuk digunakan pada SMBD-SMBD yang berbeda untuk meloloskan nilai-nilai yang cocok untuk diimbuhkan dalam pernyataan-pernyataan SQL harafiah. Untuk MySQL, yang serupa dengan ini adalah fungsi bawaan mysql_real_escape_string:
$hasil_kueri = mysql_query
(
"select * from pengguna where nama = '"
.
mysql_real_escape_string($nama_pengguna)
.
"'"
);
Antarmuka asli untuk sebuah SMBD tertentu dapat juga menawarkan sebuah metode untuk melakukan pengikatan placeholder secara terpisah, misalnya mysql_stmt_bind_param Diarsipkan 2007-04-21 di Wayback Machine. atau oci_bind_by_name. Selain itu, sebuah pustaka abstraksi basis data dapat digunakan untuk menirukan placeholder dalam cara yang mirip dengan DBI dari Perl. Sebuah contoh dari beberapa pustaka yang ada ialah ADOdb.
Dalam bahasa pemrograman Java, yang serupa adalah kelas PreparedStatement.
Daripada
Connection con = (peroleh koneksi)
Statement stmt = con.createStatement();
ResultSet rset = stmt.executeQuery("SELECT * FROM pengguna WHERE nama = '" + userName + "';");
gunakan yang berikut
Connection con = (peroleh koneksi)
PreparedStatement pstmt = con.prepareStatement("SELECT * FROM pengguna WHERE nama = ?");
pstmt.setString(1, namaPengguna);
ResultSet rset = pstmt.executeQuery();
Dalam bahasa pemrograman "C#" .NET atau Mono, yang serupa adalah objek-objek ADO.NET SqlCommand (untuk Microsoft SQL Server) atau OracleCommand (untuk server basis data Oracle). Contoh di bawah ini memperlihatkan bagaimana mencegah serangan injeksi menggunakan objek SqlCommand. Kode untuk penyedia ADO.NET lainnya sangat mirip, tetapi dapat sedikit berbeda tergantung pada implementasi khusus yang dibuat oleh vendor penyedia tersebut.
Daripada
using( SqlConnection con = (peroleh koneksi) ) {
con.Open();
using( SqlCommand cmd = new SqlCommand("SELECT * FROM pengguna WHERE nama = '" + namaPengguna + "'", con) ) {
using( SqlDataReader rdr = cmd.ExecuteReader() ) {
...
}
}
}
gunakan yang berikut
using( SqlConnection con = (peroleh koneksi) ) {
con.Open();
using( SqlCommand cmd = new SqlCommand("SELECT * FROM users WHERE name = @namaPengguna", con) ) {
cmd.Parameters.AddWithValue("@namaPengguna", namaPengguna);
using( SqlDataReader rdr = cmd.ExecuteReader() ) {
...
}
}
}
Perbaikan basis data
Mengatur hak-hak keamanan pada basis data ke kebutuhan yang paling minim adalah sebuah perbaikan yang sederhana. Tidak banyak aplikasi yang memerlukan pengguna untuk memiliki hak menghapus sebuah tabel atau basis data.
Kebanyakan basis data juga menawaran kemampuan untuk menyiapkan pernyataan-pernyataan SQL pada lapisan basis data melalui stored procedure. Daripada menggunakan sebuah lapisan aplikasi untuk merangkai SQL secara dinamis, stored procedure membungkus prosedur-prosedur basis data pakai-ulang yang dipanggil dengan parameter-parameter bertipe. Ini menyediakan beberapa keuntungan keamanan dengan membuat masukan-masukan menjadi parameter dan mewajibkan tipe pada mereka, masukan pengguna secara efektif tersaring. Sebagai tambahan, kebanyakan basis data mengizinkan stored procedure untuk berjalan di bawah hak-hak keamanan yang berbeda daripada pengguna basis data. Misalnya, sebuah aplikasi akan memiliki akses untuk menjalankan sebuah stored procedure, tetapi tidak memiliki akses ke tabel-tabel dasarnya. Ini membatasi kemampuan aplikasi untuk melakukan sesuatu yang di luar aksi-aksi yang dituliskan di dalam stored procedure.
Yang juga penting untuk dicatat adalah metode kueri standar dari pustaka client C MySQL tidak akan mengizinkan lebih daripada sebuah kueri dalam sebuah masukan, mencegah serangan banyak-pernyataan yang dipaparkan di atas. Namun begitu, masukan pengguna baik-baik yang mengandung karakter-karakter pelolos (misalnya tanda kutip tunggal) tetap dapat menyebabkan aplikasi tidak berjalan karena sintaks SQL yang buruk. Bahkan beberapa serangan juga mungkin terjadi, sebagai contoh misalkan sebuah situs web yang memperlihatkan sebuah daftar barang untuk sebuah nama pengguna yang dikenal. Kueri yang dijalankan adalah:
SELECT * from barang where namapengguna='$namapengguna';
Seorang penyerang dapat memakai nama pengguna yang dirangkai secara khusus untuk mengetahui semua barang milik semua pengguna:
$namapengguna = "' or namapengguna is not null or namapengguna='";
menghasilkan pernyataan SQL sebagai berikut:
SELECT * from barang where namapengguna='' or namapengguna is not null or namapengguna='';
Ingatlah, walaupun begitu, bahwa meloloskan atau menghapus tanda kutip tidak melenyapkan risiko injeksi SQL sepenuhnya. Misalkan kueri Anda tampak seperti ini:
SELECT * from barang where idpengguna=$idpengguna;
Dengan anggapan bahwa $idpengguna merupakan nilai numerik tetapi dibiarkan lolos tanpa diperiksa, idpengguna yang dirangkai khusus ini akan, sekali lagi, memperlihatkan semua barang milik semua pengguna:
$idpengguna = "33 or idpengguna is not null or userid=44";
Yang seperti dapat Anda lihat, tidak mengandung tanda kutip sama sekali dan akan menghasilkan kueri ini:
SELECT * from barang where idpengguna=33 or idpengguna is not null or idpengguna=44;
Pertahanan yang terbaik, daripada membuat daftar hitam masukan buruk yang diketahui, adalah hanya mengizinkan masukan baik yang diketahui, atau, dengan kata lain, membuat daftar putih. Misalnya, jika Anda ingin bertahan terhadap serangan ini, Anda dapat memeriksa variabel idpengguna untuk memastikan bahwa isinya numerik seperti berikut:
if(!ctype_digit($idpengguna)){ die("Karakter-karakter yang tidak sah dalam idpengguna."); }
Lihat pula
Pranala luar
