A03:2021 – Injeksi

Faktor-Faktor

CWE Dipetakan	Tingkat Kejadian Maksimum	Rata-rata Tingkat Kejadian	Rata-rata Exploitasi Terbobot	Rata-rata Dampak Terbobot	Cakupan Maksimum	Rata-rata Cakupan	Total Kejadian	Total CVE
33	19,09%	3,37%	7,25	7,15	94,04%	47,90%	274.228	32.078

Ringkasan

Injeksi meluncur turun ke posisi tiga. 94% dari aplikasi-aplikasi yang dites oleh beberapa bentuk dari injeksi dengan tingkat kejadian maksimum 19%, rata-rata tingkat kejadian 3%, dan total kejadian 274 ribu. CWE yang menonjol meliputi: CWE-79: Cross-site Scripting, CWE-89: SQL Injection, dan CWE-73: External Control of File Name or Path.

Deskripsi

Sebuah aplikasi rentan untuk diserang ketika:

Pengguna memasukkan data yang tidak divalidasi, disaring, atau disanitasi oleh aplikasi.
Kueri secara dinamis atau pemanggilan yang tidak diparameterkan tanpa escape peka konteks dipakai secara langsung pada interpreter.
Data jahat digunakan di dalam parameter pencarian object-relational mapping (ORM) untuk mengekstraksi rekaman sensitif tambahan.
Data jahat langsung digunakan atau digabungkan. SQL atau perintah mengandung struktur dan data jahat dalam kueri dinamis, perintah, atau stored procedure.

Beberapa injeksi yang biasa terjadi adalah SQL, NoSQL, perintah OS, pemetaan relasi objek (ORM), LDAP, dan bahasa ekspresi (EL), atau injeksi Object Graph Navigation Library (OGNL). Konsepnya identik di antara semua interpreter. Peninjauan kode sumber adalah metode terbaik dalam mendeteksi apakah aplikasi tersebut rentan injeksi. Testing otomatis terhadap semua parameter, header, URL, cookies, JSON, SOAP, and masukan data XML sangat disarankan. Organisasi dapat menyertakan alat uji keamanan aplikasi statik (SAST), dinamis (DAST), dan interaktif (IAST) ke dalam CI/CD pipeline untuk mengidentifikasi cacat injeksi yang ditambahkan sebelum penggelaran produksi.

Bagaimana Cara Mencegah

Pencegahan injeksi membutuhkan pemisahan data dari perintah dan kueri:

Pilihan yang disukai adalah menggunakan API yang aman, yang mencegah penggunaan interpreter secara keseluruhan, menyediakan sebuah antar muka terparameterisasi, atau migrasi ke Object Relational Mapping Tools (ORMs).
Catatan: Bahkan ketika diparameterkan, stored procedure masih dapat memperkenalkan injeksi SQL jika PL/SQL atau T-SQL menggabungkan kueri dan data atau mengeksekusi data jahat dengan EXECUTE IMMEDIATE atau exec().
Menggunakan validasi masukan positif di sisi server. Ini bukan pertahanan komplit karena banyak aplikasi membutuhkan karakter spesial, seperti area teks atau API untuk aplikasi mobile.
Untuk sisa apapun dari kueri dinamis, escape-kan karakter khusus menggunakan sintaks escape spesifik untuk interpreter tersebut.
Catatan: Struktur SQL seperti nama tabel, nama kolom, dan lain sebagainya tidak bisa di-escape, sehingga nama struktur yang diberikan pengguna itu berbahaya. Ini adalah masalah umum dalam perangkat lunak penyusun laporan.
Gunakan LIMIT dan kontrol SQL lainnya di dalam kueri untuk mencegah penyingkapan rekaman data secara masal dalam kasus injeksi SQL.

Contoh Skenario Serangan

Skenario #1: Sebuah aplikasi menggunakan data yang tidak terpercaya dalam konstruksi dari panggilan SQL yang rawan berikut ini:

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

Skenario #2: Serupa itu, sebuah aplikasi dengan kepercayaan buta ke framework akan menghasilkan kueri yang masih rawan, (contoh, Hibernate Query Language (HQL)):

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

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

http://example.com/app/accountView?id=' or '1'='1

Ini akan mengubah arti dari kedua kueri untuk mengembalikan semua rekaman data dari akun tabel. Serangan yang lebih berbahaya dapat mengubah atau menghapus data atau bahkan memanggil stored procedure.