A03:2021 – Injection

Faktörler

CWEs Eşleştirildi	Maks Görülme Oranı	Ort. Görülme Oranı	Ort. Ağırlıklı Exploit	Ort. Ağırlıklı Impact	Maks Coverage	Ort. Coverage	Toplam Olay	Toplam CVE
33	19.09%	3.37%	7.25	7.15	94.04%	47.90%	274,228	32,078

Genel Bakış

Injection üçüncü sıraya geriledi. Uygulamaların %94’ü bir tür injection için test edildi; maksimum görülme oranı %19, ortalama görülme oranı %3 ve 274k olay kaydedildi. Dikkate değer Common Weakness Enumeration (CWE) örnekleri arasında CWE-79: Cross-site Scripting, CWE-89: SQL Injection ve CWE-73: External Control of File Name or Path bulunur.

Açıklama

Bir uygulama şu durumlarda saldırıya açık hale gelir:

Kullanıcıdan gelen veri uygulama tarafından validate, filter veya sanitize edilmiyorsa.
Dynamic query’ler veya context-aware escaping olmadan non-parameterized çağrılar doğrudan interpreter’da kullanılıyorsa.
Hostile data, ek hassas kayıtları çıkarmak için object-relational mapping (ORM) search parametrelerinde kullanılıyorsa.
Hostile data doğrudan kullanılıyor veya concat ediliyorsa. SQL ya da komut, dynamic query, command veya stored procedure’lerde hem yapı hem de malicious data’yı içeriyorsa.

En yaygın injection türleri arasında SQL, NoSQL, OS command, ORM, LDAP ve Expression Language (EL) ya da Object Graph Navigation Library (OGNL) injection yer alır. Kavram tüm interpreter’larda aynıdır. Source code review, uygulamaların injection’a açık olup olmadığını tespit etmenin en iyi yöntemidir. Tüm parametrelerin, header’ların, URL, cookie’lerin, JSON, SOAP ve XML data input’larının otomatik test edilmesi şiddetle tavsiye edilir. Kuruluşlar, production’a dağıtımdan önce eklenen injection kusurlarını belirlemek için CI/CD pipeline’ına static (SAST), dynamic (DAST) ve interactive (IAST) application security testing tool’larını dahil edebilir.

Nasıl Önlenir

Injection’ı önlemek, veriyi komut ve query’lerden ayrı tutmayı gerektirir:

Tercih edilen seçenek, interpreter kullanımını tamamen önleyen, parameterized arayüz sağlayan veya ORM’lere migrate eden güvenli bir API kullanmaktır.
Not: Parameterized olsalar bile stored procedure’ler, eğer PL/SQL veya T-SQL query ve data’yı concat ediyorsa ya da hostile data’yı EXECUTE IMMEDIATE veya exec() ile çalıştırıyorsa, yine SQL injection’a yol açabilir.
Pozitif (allow-list tabanlı) server-side input validation kullanın. Bu, tek başına tam bir savunma değildir; birçok uygulama text area gibi özel karakterler veya mobil uygulamalar için API’ler gerektirir.
Kalan dynamic query’ler için, ilgili interpreter’ın özel escape syntax’ını kullanarak special character’ları escape edin.
Not: Tablo adları, kolon adları gibi SQL yapıları escape edilemez; bu nedenle user-supplied yapı adları tehlikelidir. Bu, raporlama yazılımlarında yaygın bir sorundur.

Örnek Saldırı Senaryoları

Senaryo #1: Bir uygulama, güvensiz veriyi aşağıdaki zafiyetli SQL çağrısının oluşturulmasında kullanıyor:

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

Senaryo #2: Benzer şekilde, bir uygulamanın framework’lere körü körüne güvenmesi, sorguların yine zafiyetli olmasına yol açabilir (ör. Hibernate Query Language - HQL):

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

Her iki durumda da saldırgan, tarayıcısında ‘id’ parametre değerini şu şekilde değiştirir: ' UNION SELECT SLEEP(10);--. Örneğin:

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

Bu, her iki sorgunun da anlamını değiştirerek accounts tablosundaki tüm kayıtların döndürülmesine neden olur. Daha tehlikeli saldırılar veriyi değiştirebilir veya silebilir, hatta stored procedure’leri bile tetikleyebilir.