A03:2021 – Injeksi

Faktor-Faktor

Klasifikasi CWE	Tingkat Kejadian Maksimum	Rata-rata Tingkat Kejadian	Cakupan Maksimum	Rata-rata Cakupan	Rata-rata Bobot Exploitasi	Rata-rata Bobot Dampak	Total Kejadian	Total CVEs
33	19.09%	3.37%	94.04%	47.90%	7.25	7.15	274,228	32,078

Sudut pandang

Injeksi meluncur turun ke posisi tiga. 94% dari aplikasi-aplikasi yang dites oleh beberapa bentuk dari injeksi. Yang dapat dicatat dari CWEs meliputi : CWE-79: Pengkodean lintas situs, CWE-89: injeksi SQL, and CWE-73: Kontrol eksternal dari nama file atau bagian.

Gambaran

Sebuah aplikasi rentan untuk diserang ketika:

Pengguna memasukkan data yang tidak divalidasi, disaring atau dibersihkan oleh aplikasi.
Kueri secara dinamis atau permintaan yang tidak diberikan parameter tanpa konteks-peringatan pengalihan biasanya langsung pada mesin penerjemah.
Data berlawanan digunakan di antara parameter pencari pemetaan relasi object (ORM) untuk mengekstraksi tambahan, rekaman sensitif.
Data berlawanan biasanya langsung digunakan atau digabungkan. SQL atau perintah mengandung struktur dan data malfungsi dalam perintah kueri dinamis, perintah-perintah, atau prosedur tersimpan.

Beberapa injeksi yang biasa terjadi adalah SQL, NoSQL, perintah OS, pemetaan relasi objek(ORM), LDAP, dan bahasa ekspresi(EL) atau injeksi perpustakaan navigasi grafik objek. Konsepnya adalah identik di antara semua mesin penerjemah. Penelaahan kode sumber adalah metode terbaik dalam mendeteksi apakah aplikasi tersebut beresiko untuk diinjeksi. Testing otomatis terhadap semua parameter-parameter, headers, URL, cookies, JSON, SOAP, and input data XML sangat disarankan. Organisasi dapat menyertakan sumber statik (SAST) dan perangkat tes aplikasi dinamis (DAST) ke dalam CI/CD pipeline untuk mengidentifikasi pengenalan serpihan-serpihan injeksi sebelum di sebarkan ke produksi.

Bagaimana cara mencegah

Pencegahan injeksi membutuhkan penyimpanan data terpisah dari perintah dan kueri.
Pilihan yang disukai adalah menggunakan API yang aman, dimana mencegah penggunaan mesin penerjemah secara keseluruhan, menyediakan sebuah tatap muka berparameter, atau migrasi ke perangkat pemetaan relasi objek.
Catatan : Bahkan ketika diparameterkan, prosedur tersimpan masih memperkenalkan injeksi SQL jika PL/SQL atau T-SQL menggabungkan kueri dan data atau mengeksekusi data yang berlawanan dengan EXECUTE IMMEDIATE or exec().
Menggunakan positif atau "daftar putih" pada validasi masukan di sisi server. Ini bukan pertahanan komplit seperti banyak aplikasi membutuhkan karakter spesial, seperti area teks atau APIs untuk aplikasi portabel.
Untuk sisa apapun dari kueri dinamis, melewatkan karakter spesial menggunakan sintaks peralihan spesifik untuk mesin penerjemah.
Catatan: struktur SQL seperti nama tabel, nama kolom, dan lain sebagainya tidak bisa dilewatkan, dan nama struktur yang diberikan pengguna adalah berbahaya. Ini adalah masalah yang sering terjadi dalam pelaporan penulisan perangkat lunak.
Menggunakan LIMIT dan kontrol SQL lainnya di antara kueri untuk mencegah penyingkapan rekaman data secara massal dalam kasus injeksi SQL.

Contoh skenario serangan

Skenario #1: sebuah aplikasi menggunakan data yang tidak terpercaya pada kontruksi dari panggilan SQL yang rawan berikut ini:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Skenario #2: serupa dengan sebuah aplikasi dengan kepercayaan buta dalam frameworks akan menghasilkan kueri yang masih rawan, (contoh, bahasa kueri hibernate(HQL)):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

pada kedua kasus tersebut, penyerang akan memodifikasi nilai parameter ‘id’ pada peramban web untuk mengirim :‘ or ‘1’=’1. Sebagai contoh:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

Ini akan merubah arti dari kedua kueri untuk mengembalikan semua rekaman data dari akun tabel. Serangan lebih berbahaya dapat merubah atau menghapus data atau bahkan prosedur tersimpan.