Konuyu Açan #1
Giriş ve amacın netleşmesi
SQL enjeksiyonu (SQLi) türündeki açıklar, doğrudan veritabanı katmanına yönelik bir saldırı yüzeyi sağlar. Bu tür açıkların riskini nicel olarak ifade etmek için CVSS (Common Vulnerability Scoring System) temel alınır. Amacımız, bir SQL açığının CVSS v3.x/3.1 çerçevesinde hangi bileşenlerle değerlendirileceğini somut bir dille anlatmak ve uygulamaya yönelik örnekler sunmaktır.


[i]Temel ağırlıklar ve üç temel metriksiz (v3.x) yapı
CVSS üç ana kategoriden oluşur: Temel (Base), Geçici (Temporal) ve Ortam (Environmental). SQL açığı için çoğu an için başlangıçta Base skoru hesaplanır ve şu bileşenler dikkate alınır:
  • Sınıflandırma: Açığın hangi tür güvenlik kaybını tetiklediği (Kritik bilgiya erişim, yetkisiz komut çalıştırma, bütünlük bozulması vs.).
  • Etki alanı: Bütünlük, bütünlük ve gizlilik üzerinde ne tür bir etki var? Ayrıca kullanılabilirlik kaybı da değerlendirilebilir.
  • Erişim zorluk düzeyi: Saldırganın açığa karşı hangi arayüzü kullanabildiği (farklı kullanıcı rolleri, oturum durumları) ve özel koşullara ihtiyaç olup olmadığı.
  • Saldırı karmaşıklığı: Saldırının tecrübe gerektirip gerektirmediği, çok adımlı mı olduğu.


[code]Base metrics örnekleri:
  • Attack Vector (AV): Network üzerinden SQLiye maruz kalan bir açık için AV=Network olabilir.
  • Attack Complexity (AC): Basit bir SQL enjeksiyonu ise AC=Low.
  • Privileges Required (PR): Saldırganın belirli bir kullanıcıya sahip olup olmadığına bağlı olarak PR=None veya Low.
  • User Interaction (UI): Saldırganın kullanıcı dışında bir etkileşim gerekip gerekmediği (genelde UI=Required olmayan durumlar tercih edilir).
  • Scope (S): Etki alanının veritabanı sınırlarıyla sınırlı mı yoksa modüler olarak tüm sistem etkilenebilir mi.
  • Confidentiality (C), Integrity (I), Availability (A): Gizlilik, bütünlük ve hizmet kesintisi üzerindeki etkilerin katsayıları.


[Daha somut bir akış]
1) Açığın türünü sınıflandırın: SQL enjeksiyonu olup olmadığını ve hangi tablolara/yetkilere erişim sağladığını belirleyin.
2) Etkilerin kapsamını belirleyin: Veritabanı üzerinde hangi veriler tehlikeye giriyor? Özellikle kullanıcı verileri, kimlik doğrulama bilgilerinin ifşası vb.
3) Erişim gereksinimlerini ve saldırı kolaylığını seçin: Uzaktan mı yoksa lokal/ısmarlama bir bağlam mı gerekli?
4) Base skoru hesaplayın: CVSS v3.x matematikselliğiyle (AV, AC, PR, UI, S, C, I, A) temel skor elde edilir.
5) Gerektiğinde Temporal ve Environmental skorları ekleyin: Zamanla değişebilen güvenlik yamaları, mevcut savunmalar ve kurumsal ortam farklılıkları bu adımla yedirilir.

Birkaç pratik ipucu
[list]
  • Data exfiltration potansiyeli olan SQLi için C ve I değerleri genelde yüksek seyreder.
  • URI parametreleri üzerinden gerçekleşen enjeksiyonlar için AV=Network ve AC=Low tercih edilebilir.
  • Privileges Required’ın None olması, etkileyici bir Base skoruna sebep olur; bu, savunma takımını önceliklendirmede kritik olabilir.
  • Ortam (Environmental) metriği, şirketin güvenlik kontrolleri (WAF, DB güvenliği, ağ segmentasyonu) dikkate alınırken kullanılır; bu, potansiyel kayıpları azaltan faktörleri içerebilir.

  • [/list]

    Sonuç olarak, SQL açığı CVSS ile değerlendirildiğinde, temel olarak hangi saldırı route’unun kullanıldığı ve hangi zararın ortaya çıkabileceği netleştirilir. Sizce mevcut uygulama katmanında en kritik SQLi riskinizi hangi metriklerle ifade ediyorsunuz? Deneyimleriniz veya varsa örnek vakalarla paylaşabilir misiniz?

    Yanıt vermek için giriş yapmış olmalısınız.

    Bu konuyu görüntüleyen kullanıcılar (Toplam: 1, Üyeler: 1, Misafirler: 0)
    Toplam: 1 (üyeler: 1, misafirler: 0)
    0 alıntı seçildi