0

Apa itu SQL Injection Attactk : Cara Kerja Contoh Dan Pencegahannya

Senin, 05 Agustus 2024 Mufa1st
Share this Article on :



Apa itu Serangan Injeksi SQL ( SQLi )?

Serangan SQL Injection (atau SQLi) mengubah kueri SQL, menyuntikkan kode berbahaya dengan mengeksploitasi kerentanan aplikasi. 

Serangan SQLi yang berhasil memungkinkan penyerang mengubah informasi basis data, mengakses data sensitif, menjalankan tugas admin pada basis data, dan memulihkan file dari sistem. Dalam beberapa kasus, penyerang dapat mengeluarkan perintah ke sistem operasi database yang mendasarinya.

Dampak parah dari serangan ini membuat pengembang harus mengadopsi praktik yang mencegah injeksi SQL, seperti kueri berparameter, prosedur tersimpan, dan validasi input yang ketat.

Ini adalah bagian dari serangkaian panduan ekstensif tentang keamanan data .

Apa Itu Kueri SQL?

SQL, yang merupakan singkatan dari Structured Query Language, adalah bahasa yang digunakan untuk berkomunikasi dan memanipulasi database. Ini adalah bahasa standar untuk sistem manajemen basis data relasional dan digunakan untuk melakukan tugas-tugas seperti memperbarui data pada basis data, atau mengambil data dari basis data.

Kueri SQL adalah perintah yang digunakan untuk berkomunikasi dengan database. Mereka memungkinkan tugas-tugas seperti mencari, memperbarui, atau mengambil data yang disimpan dalam database. Misalnya, aplikasi web eCommerce mungkin menggunakan kueri SQL untuk mengambil informasi tentang produk tertentu dari database produk.

Namun, jika aplikasi tidak dirancang dengan aman, aplikasi mungkin mengizinkan pengguna untuk memasukkan kueri SQL secara langsung. Dalam hal ini, pengguna jahat dapat memasukkan kueri SQL yang dibuat khusus yang dapat menyebabkan akses tidak sah, kebocoran data, atau bahkan penghapusan data. Ini dikenal sebagai serangan injeksi SQL.

Dampak Serangan Injeksi SQL yang Berhasil

Konsekuensi dari serangan injeksi SQL yang berhasil dapat mencakup:

  • Kredensial yang dicuri —penyerang dapat memperoleh kredensial melalui SQLi dan kemudian menyamar sebagai pengguna dan menggunakan hak istimewa mereka.
  • Akses tidak sah ke database —penyerang dapat memperoleh akses ke data sensitif di server database.
  • Perubahan data —penyerang dapat mengubah atau menambahkan data baru ke database yang diakses. 
  • Penghapusan data —penyerang dapat menghapus catatan database atau menghapus seluruh tabel. 

Pergerakan lateral —penyerang dapat mengakses server database dengan hak istimewa sistem operasi, dan menggunakan izin ini untuk mengakses sistem sensitif lainnya.

Bagaimana Cara Kerja Serangan Injeksi SQL?

Serangan SQL Injection melibatkan penyisipan atau “injeksi” query SQL melalui input data dari klien ke aplikasi. Serangan yang berhasil memungkinkan penyerang memanipulasi kueri SQL yang dibuat aplikasi ke database-nya. Biasanya melibatkan langkah-langkah berikut:

  1. Identifikasi masukan yang rentan: Penyerang pertama-tama mengidentifikasi masukan dalam aplikasi web yang rentan terhadap injeksi SQL. Masukan ini dapat berupa kolom teks dalam formulir, parameter URL, atau mekanisme masukan lainnya.
  2. Membuat kueri SQL berbahaya: Setelah masukan yang rentan teridentifikasi, penyerang membuat pernyataan SQL yang dimaksudkan untuk dimasukkan ke dalam kueri yang dijalankan oleh aplikasi. Pernyataan ini dirancang untuk mengubah kueri SQL asli untuk melakukan tindakan yang tidak diinginkan oleh pengembang aplikasi.
  3. Melewati langkah-langkah keamanan aplikasi: Penyerang sering kali harus melewati langkah-langkah keamanan seperti validasi input atau keluar dari karakter khusus. Mereka mencapai hal ini melalui teknik seperti penggabungan string atau memanfaatkan sintaksis SQL untuk mengomentari bagian dari kueri asli.
  4. Mengeksekusi kueri berbahaya: Saat aplikasi menjalankan kueri SQL, aplikasi tersebut menyertakan masukan berbahaya dari penyerang. Kueri yang dimodifikasi ini dapat melakukan tindakan seperti melihat data tanpa izin, menghapus data, atau bahkan mengubah skema database.
  5. Mengekstraksi atau memanipulasi data: Tergantung pada serangannya, hasilnya mungkin berupa ekstraksi informasi sensitif (seperti kredensial pengguna), mengubah data yang ada, menambahkan data baru, atau bahkan menghapus sebagian besar database.
  6. Memanfaatkan kerentanan server database: Injeksi SQL tingkat lanjut dapat mengeksploitasi kerentanan di server database, sehingga memperluas serangan di luar database hingga ke tingkat server. Hal ini dapat mencakup menjalankan perintah pada sistem operasi atau mengakses bagian lain dari sistem file server.

Proses ini memanfaatkan eksekusi dinamis SQL dalam aplikasi di mana input pengguna disertakan secara langsung dalam pernyataan SQL tanpa validasi atau pelolosan yang tepat. Ini mengeksploitasi cara query SQL dibuat, seringkali dengan cara yang tidak diantisipasi oleh pengembang.

Contoh Serangan Injeksi SQL di Kehidupan Nyata

Selama 20 tahun terakhir, banyak serangan injeksi SQL menargetkan situs web besar, platform bisnis, dan media sosial. Beberapa dari serangan ini menyebabkan pelanggaran data yang serius. Beberapa contoh penting tercantum di bawah ini.

Pelanggaran Diaktifkan oleh SQL Injection

  • Serangan GhostShell —peretas dari grup APT Tim GhostShell menargetkan 53 universitas menggunakan injeksi SQL, mencuri dan menerbitkan 36.000 catatan pribadi milik mahasiswa, dosen, dan staf.
  • Pemerintah Turki —kelompok APT lainnya, kolektif RedHack, menggunakan injeksi SQL untuk membobol situs web pemerintah Turki dan menghapus utang kepada lembaga pemerintah.
  • Pelanggaran 7-Eleven —tim penyerang menggunakan injeksi SQL untuk menembus sistem perusahaan di beberapa perusahaan, terutama jaringan ritel 7-Eleven, mencuri 130 juta nomor kartu kredit.
  • Pelanggaran HBGary —peretas yang terkait dengan kelompok aktivis Anonymous menggunakan SQL Injection untuk menghapus situs web perusahaan keamanan TI. Serangan itu merupakan tanggapan terhadap publikasi CEO HBGary bahwa dia mengetahui nama-nama anggota organisasi Anonymous.

Kerentanan Injeksi SQL yang Penting

  • Kerentanan Tesla —pada tahun 2014, peneliti keamanan mempublikasikan bahwa mereka dapat menembus situs web Tesla menggunakan injeksi SQL, mendapatkan hak administratif, dan mencuri data pengguna.
  • Kerentanan Cisco —pada tahun 2018, kerentanan injeksi SQL ditemukan di Cisco Prime License Manager. Kerentanan ini memungkinkan penyerang mendapatkan akses shell ke sistem tempat manajer lisensi dikerahkan. Cisco telah menambal kerentanannya.
  • Kerentanan Fortnite —Fortnite adalah game online dengan lebih dari 350 juta pengguna. Pada tahun 2019, ditemukan kerentanan injeksi SQL yang memungkinkan penyerang mengakses akun pengguna. Kerentanan telah ditambal.

Jenis Serangan Injeksi SQL

Ada beberapa jenis injeksi SQL:

  • Injeksi SQL berbasis serikat – Injeksi SQL berbasis serikat mewakili jenis injeksi SQL yang paling populer dan menggunakan pernyataan UNION. Pernyataan UNION mewakili kombinasi dua pernyataan pilihan untuk mengambil data dari database.
  • Injeksi SQL Berbasis Kesalahan – metode ini hanya dapat dijalankan pada Server MS-SQL. Dalam serangan ini, pengguna jahat menyebabkan aplikasi menampilkan kesalahan. Biasanya, Anda mengajukan pertanyaan ke database dan database mengembalikan pesan kesalahan yang juga berisi data yang mereka minta.
  • Blind SQL Injection – dalam serangan ini, tidak ada pesan kesalahan yang diterima dari database; Kami mengekstrak data dengan mengirimkan pertanyaan ke database. Injeksi SQL buta dapat dibagi menjadi Injeksi SQL berbasis boolean dan Injeksi SQL berbasis waktu. 

Serangan SQLi juga dapat diklasifikasikan berdasarkan metode yang mereka gunakan untuk memasukkan data:

  • Injeksi SQL berdasarkan masukan pengguna – aplikasi web menerima masukan melalui formulir, yang meneruskan masukan pengguna ke database untuk diproses. Jika aplikasi web menerima masukan ini tanpa membersihkannya, penyerang dapat memasukkan pernyataan SQL yang berbahaya.
  • Injeksi SQL berdasarkan cookie – pendekatan lain untuk injeksi SQL adalah memodifikasi cookie untuk “meracuni” kueri basis data. Aplikasi web sering kali memuat cookie dan menggunakan datanya sebagai bagian dari operasi database. Pengguna jahat, atau malware yang disebarkan pada perangkat pengguna, dapat memodifikasi cookie, untuk menyuntikkan SQL dengan cara yang tidak terduga.
  • Injeksi SQL berdasarkan header HTTP – variabel server seperti header HTTP juga dapat digunakan untuk injeksi SQL. Jika aplikasi web menerima masukan dari header HTTP, header palsu yang berisi SQL arbitrer dapat memasukkan kode ke dalam database.
  • Injeksi SQL orde kedua – ini mungkin merupakan serangan injeksi SQL yang paling kompleks, karena serangan ini mungkin tidak aktif dalam jangka waktu yang lama. Serangan injeksi SQL tingkat kedua mengirimkan data beracun, yang mungkin dianggap tidak berbahaya dalam satu konteks, namun berbahaya dalam konteks lain. Bahkan jika pengembang membersihkan semua masukan aplikasi, mereka masih rentan terhadap jenis serangan ini.

Contoh Kode Injeksi SQL

Mari kita lihat dua contoh umum serangan injeksi SQL. 

Contoh 1: Menggunakan SQLi untuk Mengautentikasi sebagai Administrator

Contoh ini menunjukkan bagaimana penyerang dapat menggunakan injeksi SQL untuk menghindari otentikasi aplikasi dan mendapatkan hak administrator. 

Pertimbangkan sistem otentikasi sederhana menggunakan tabel database dengan nama pengguna dan kata sandi. Permintaan POST pengguna akan menyediakan variabel userdan pass, dan ini dimasukkan ke dalam pernyataan SQL:

sql = "SELECT id FROM users WHERE username='" + user + "' AND password='" + pass + "'"

Masalahnya di sini adalah pernyataan SQL menggunakan penggabungan untuk menggabungkan data. Penyerang dapat memberikan string seperti ini sebagai ganti passvariabel:

password' OR 5=5

Kueri SQL yang dihasilkan akan dijalankan terhadap database:

SELECT id FROM users WHERE username='user' AND password='pass' OR 5=5'

Karena 5=5merupakan kondisi yang selalu bernilai benar, seluruh WHEREpernyataan akan benar, terlepas dari nama pengguna atau kata sandi yang diberikan. 

Pernyataan tersebut WHEREakan mengembalikan ID pertama dari tabel pengguna, yang biasanya merupakan administrator. Ini berarti penyerang dapat mengakses aplikasi tanpa otentikasi, dan juga memiliki hak administrator. 

Bentuk lebih lanjut dari serangan ini adalah penyerang menambahkan simbol komentar kode di akhir pernyataan SQL, yang memungkinkan mereka memanipulasi kueri SQL lebih lanjut. Berikut ini akan berfungsi di sebagian besar database termasuk MySQL, PostgreSQL, dan Oracle:

' OR '5'='5' /*

Pelajari lebih lanjut di panduan terperinci kami untuk pengujian injeksi sql .

Contoh 2: Menggunakan SQLi untuk Mengakses Data Sensitif

Dalam contoh ini, kode berikut memperoleh nama pengguna saat ini, dan mencari item yang cocok dengan nama item tertentu, dengan pemiliknya adalah pengguna saat ini.

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = "'"
                + userName + "' AND itemname = '"
                + ItemName.Text + "'";
...

Kode ini memiliki kelemahan yang sama seperti pada contoh sebelumnya – penggunaan penggabungan. Setelah menggabungkan nama pengguna dan nama item, kode tersebut membuat kueri berikut:

SELECT * FROM items 
WHERE owner =
AND itemname = ;

Jika penyerang memberikan string berikut untuk itemname:

Widget' OR 5=5

Pernyataan SQL menjadi:

SELECT * FROM items
WHERE owner = 'John'
AND itemname = 'Widget' OR 5=5';

Yang sama dengan: SELECT * FROM items;

Ini berarti kueri akan mengembalikan data seluruh tabel, memberikan penyerang akses tidak sah ke data sensitif.

Contoh 3: Memasukkan Pernyataan Berbahaya ke dalam Bidang Formulir


Ini adalah serangan injeksi SQL sederhana berdasarkan masukan pengguna. Penyerang menggunakan formulir yang memerlukan nama depan dan nama belakang sebagai masukan. Penyerang memasukkan:

  • Nama depan:malicious'ex
  • Nama keluarga:Smith

Variabel nama depan penyerang berisi ekspresi jahat, yang kami nyatakan sebagai 'ex. Pernyataan SQL yang memproses input formulir terlihat seperti ini:

SELECT id, firstname, lastname FROM authors

Setelah penyerang memasukkan ekspresi jahat ke dalam nama depan, pernyataannya akan terlihat seperti ini:

SELECT id, firstname, lastname FROM authors WHERE firstname = 'malicious'ex' and lastname ='newman'

Basis data mengidentifikasi sintaks yang salah karena tanda kutip tunggal, dan mencoba menjalankan pernyataan berbahaya.

Lembar Cheat Pencegahan Injeksi SQL

Ini adalah versi ringkasan dari lembar contekan pencegahan injeksi OWASP SQL yang luar biasa .

Opsi Pertahanan 1: Pernyataan yang Disiapkan (dengan Kueri yang Diparameterisasi)

Pernyataan yang disiapkan mudah dipelajari dan digunakan, serta menghilangkan masalah injeksi SQL. Mereka memaksa Anda untuk mendefinisikan kode SQL, dan meneruskan setiap parameter ke kueri nanti, membuat perbedaan yang kuat antara kode dan data. 

Jika penyerang memberikan string berbahaya seperti pada contoh di atas, misalnya memberikan John' or 1=1nama pengguna, pernyataan yang disiapkan akan mengevaluasinya sebagai string literal. Ini akan mencari pengguna bernama John' or 1=1(dan gagal, karena tidak ada pengguna tersebut) alih-alih mengevaluasi pernyataan ini sebagai kode.

Pernyataan yang disiapkan tersedia dalam semua bahasa pemrograman. Berikut adalah contoh di Jawa. Agar aman, OWASP merekomendasikan untuk memvalidasi parameter input untuk berjaga-jaga.

// Separate definition of input variable
String custname = request.getParameter("customerName");
// Separate definition of SQL statement
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
// PreparedStatement command securely combines inputs and SQL syntax
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );

Opsi Pertahanan 2: Prosedur Tersimpan

Prosedur tersimpan mirip dengan pernyataan yang disiapkan, hanya kode SQL untuk prosedur tersimpan yang ditentukan dan disimpan dalam database, bukan dalam kode pengguna. Dalam kebanyakan kasus, prosedur tersimpan bisa seaman pernyataan yang telah disiapkan, sehingga Anda dapat memutuskan mana yang lebih sesuai dengan proses pengembangan Anda.

Ada dua kasus di mana prosedur tersimpan tidak aman:

  • Prosedur tersimpan mencakup pembuatan SQL dinamis – hal ini biasanya tidak dilakukan dalam prosedur tersimpan, namun dapat dilakukan, jadi Anda harus menghindarinya saat membuat prosedur tersimpan. Jika tidak, pastikan Anda memvalidasi semua input.
  • Hak istimewa pemilik basis data – dalam beberapa pengaturan basis data, administrator memberikan izin kepada pemilik basis data untuk mengaktifkan prosedur tersimpan agar dapat dijalankan. Artinya jika penyerang membobol server, mereka mempunyai hak penuh atas database. Hindari hal ini dengan membuat peran khusus yang mengizinkan prosedur penyimpanan hanya pada tingkat akses yang diperlukan.

Berikut adalah contoh prosedur tersimpan di Java (Java menyebutnya a CallableStatement). Kami berasumsi bahwa sp_getAccountBalancerprosedur tersimpan mengimplementasikan logika yang sama seperti pernyataan yang disiapkan pada opsi 1 di atas.

// Separate definition of user inputs
String custname = request.getParameter("customerName");
// Executing the stored procedure sp_getAccountBalancer
try {
  CallableStatement cs = connection.prepareCall("{call
sp_getAccountBalance(?)}");
  cs.setString(1, custname);
  ResultSet results = cs.executeQuery();
  // result set handling
} catch (SQLException se) {
  // logging and error handling
}

Opsi Pertahanan 3: Validasi Masukan Daftar yang Diizinkan

Ini adalah tindakan kuat lainnya yang dapat bertahan melawan injeksi SQL. Ide validasi daftar yang diizinkan adalah bahwa masukan pengguna divalidasi berdasarkan daftar tertutup dari nilai hukum yang diketahui.

Misalnya, jika input pengguna digunakan untuk memilih tabel database, Anda bisa menggunakan kode seperti ini untuk memastikan bahwa input tersebut hanya bisa cocok dengan salah satu dari beberapa nama tabel yang diketahui:

String tableName;
switch(PARAM):
  case "Value1": tableName = "fooTable";
                 break;
  case "Value2": tableName = "barTable";
                 break;
  ...
  default      : throw new InputValidationException("unexpected value 
                 Provided" + " for table name");

Cara aman lainnya untuk menangani masukan pengguna adalah dengan mengonversinya ke bentuk non-string. Misalnya, jika masukan pengguna menentukan apakah kueri harus diurutkan dalam urutan menaik atau menurun, masukan dapat dikonversi ke boolean. Dan kemudian nilai boolean ini digunakan untuk menentukan urutan pengurutan:

public String someMethod(boolean sortOrder) {
 String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" :
"DESC");`
...

Opsi Pertahanan 4: Menghindari Semua Masukan yang Disediakan Pengguna

Melarikan diri berarti menambahkan karakter escape yang memerintahkan kode untuk mengabaikan karakter kontrol tertentu, mengevaluasinya sebagai teks dan bukan sebagai kode. 

Opsi ini adalah opsi yang paling tidak aman dari keempatnya, dan sebaiknya hanya digunakan sebagai upaya terakhir. Hal ini karena melarikan diri dari masukan pengguna hanya efektif jika kode lolos dari semua kemungkinan karakter kontrol, dan penyerang menemukan berbagai cara kreatif untuk menyuntikkannya. Oleh karena itu, OWASP tidak merekomendasikan metode ini dan menyarankan penggunaan opsi 1 atau 2 di atas.

Misalnya, di MySQL ada dua mode pelolosan – ANSI_QUOTES SQLmode dan MySQLmode:

  • dalam mode ANSI_QUOTES, untuk keluar dari karakter kontrol, enkode semua karakter ' (satu centang) dengan ” (dua centang)
  • Dalam mode MySQL, keluarkan karakter berikut:
    • \0 [angka nol, bukan huruf O]
    • \B
    • \T
    • \N
    • \R
    • \Z
    • \”
    • \%
    • \'
    • \\ [menghilangkan satu karakter garis miring]
    • \_
    • Ganti semua karakter non-alfanumerik lainnya dengan nilai ASCII
    • Ganti angka yang kurang dari 256 dengan \c dimana 'c' adalah angka aslinya

OWASP menyediakan API Keamanan Perusahaan (ESAPI) sumber terbuka dan gratis , yang dapat membantu Anda menerapkan pelolosan dalam kode database lama. Ini menyediakan codec untuk database populer, yang telah lolos untuk semua pola kontrol yang tidak aman. 

ESAPI saat ini mendukung Oracle dan MySQL, dan akan segera mendukung encoder untuk SQL Server dan PostgreSQL.



Artikel Terkait:

Posted di 23.54

0 komentar:

Posting Komentar

Langganan: Posting Komentar (Atom)