# SQL Injection ve Veritabanı Güvenliği: Uygulama ile Database Arasındaki Riskler **URL:** https://securesys.com.tr/tr/bilgi-merkezi/veritabani-guvenligi/sql-injection-ve-veritabani-guvenligi ![SQL Injection ve Veritabanı Güvenliği: Uygulama ile Database Arasındaki Riskler](/images/bilgi-merkezi/covers/cover-veritabani-06.webp) SQL Injection, yıllardır bilinen ancak hâlâ web uygulamaları, API servisleri ve kurumsal yazılımlarda ciddi veri ihlallerine yol açabilen en kritik güvenlik açıklarından biridir. Bu zafiyet çoğu zaman uygulama katmanında ortaya çıkar. Ancak etkisi doğrudan veritabanında görülür. Bu nedenle SQL Injection yalnızca yazılım geliştirme ekibinin değil; database administrator, DevSecOps, SOC, Red Team, Blue Team, application security ve bilgi güvenliği ekiplerinin de ortak konusu olmalıdır. Bir uygulama dışarıdan aldığı kullanıcı girdisini güvenli şekilde işlemiyorsa saldırgan SQL sorgusunun mantığını değiştirebilir. Sonuç olarak; yetkisiz veri görüntüleme, veri değiştirme, authentication bypass, hassas bilgi sızıntısı ve bazı durumlarda daha geniş sistem etkileri oluşabilir. Bu nedenle SQL Injection'a karşı yalnızca: **“WAF kullanıyoruz.”** veya: **“Input validation yapıyoruz.”** demek yeterli değildir. Güvenli yaklaşım; **Parameterized Query, Prepared Statement, Least Privilege, Secure Coding, Input Validation, ORM Security, Error Handling, WAF, Logging ve Database Monitoring** kontrollerinin birlikte uygulanmasını gerektirir. ### SQL Injection Nedir? SQL Injection, uygulamanın kullanıcı girdisini SQL sorgusuna güvenli olmayan şekilde dahil etmesi sonucu sorgu mantığının manipüle edilebilmesi zafiyetidir. Temel problem şudur: **Data ile SQL command birbirinden ayrılmamıştır.** Kullanıcıdan gelen veri yalnızca veri olarak işlenmesi gerekirken SQL sorgusunun bir parçası haline gelir. ### SQL Nedir? SQL: #### Structured Query Language ilişkisel veritabanlarıyla iletişim kurmak için kullanılan sorgu dilidir. SQL ile; veri okunabilir, eklenebilir, güncellenebilir, silinebilir ve database objeleri yönetilebilir. ### SQL Injection Neden Tehlikelidir? Çünkü web uygulaması çoğu zaman database'e kullanıcı adına erişir. Eğer uygulama SQL sorgusunu güvenli oluşturmuyorsa saldırgan uygulamanın sahip olduğu database yetkilerini kötüye kullanabilir. Burada kritik nokta: **SQL Injection etkisi application database account'un yetkileri kadar büyüyebilir.** ### SQL Injection Uygulama Zafiyeti midir? Evet. Zafiyet genellikle application code içerisinde oluşur. Ancak sonuç database üzerinde ortaya çıkar. Bu nedenle database security ekibi de bu riskle ilgilenmelidir. ### SQL Injection Nasıl Oluşur? Temel olarak kullanıcı girdisinin SQL sorgusuna doğrudan birleştirilmesi nedeniyle oluşur. Örneğin uygulama; username, search term, product id gibi girdileri güvenli parametreler yerine SQL cümlesine doğrudan ekleyebilir. Bu durumda saldırgan sorgu mantığını etkileyebilir. ### SQL Injection'ın Temel Kök Nedeni Nedir? En temel kök neden: #### Untrusted Input + Dynamic SQL kombinasyonudur. ### Untrusted Input Nedir? Kullanıcıdan veya dış sistemden gelen ve güvenli kabul edilmemesi gereken veridir. Örneğin; URL parameter, HTTP header, form field, JSON body, cookie, API input untrusted input olabilir. ### Sadece Form Alanları mı Risklidir? Hayır. SQL Injection yalnızca username/password formunda oluşmaz. Risk; search, filter, sort, report, API, mobile backend, admin panel gibi birçok noktada bulunabilir. ### Second-Order SQL Injection Nedir? Zararlı veya beklenmeyen veri ilk aşamada database'e normal veri olarak kaydedilir. Daha sonra başka bir işlem bu veriyi dinamik SQL içerisinde güvenli olmayan şekilde kullanır. Bu durumda zafiyet daha sonraki aşamada ortaya çıkar. ### Blind SQL Injection Nedir? Uygulamanın database cevabını doğrudan göstermediği ancak davranış farklılıklarından sorgu sonucuna ilişkin çıkarım yapılabildiği SQL Injection türüdür. Savunma açısından önemli olan nokta şudur: **Hata mesajının gösterilmemesi SQL Injection'ı ortadan kaldırmaz.** ### Error-Based SQL Injection Nedir? Database error mesajlarının saldırgana query veya yapı hakkında bilgi sağlayabildiği senaryolardır. Bu nedenle production ortamında detaylı database hata mesajları kullanıcıya gösterilmemelidir. ### SQL Injection ile Authentication Bypass Mümkün mü? Güvensiz authentication sorgularında olabilir. Bu nedenle login sistemlerinde de parameterized query kullanılmalıdır. ### SQL Injection ile Veri Okunabilir mi? Application database hesabının SELECT yetkileri ölçüsünde hassas veriler risk altına girebilir. ### SQL Injection ile Veri Değiştirilebilir mi? Application account UPDATE veya DELETE yetkisine sahipse risk artabilir. Bu nedenle Least Privilege kritik öneme sahiptir. ### SQL Injection Etkisini Ne Belirler? Başlıca faktörler: - Application account yetkileri - Database configuration - Network erişimi - Stored procedure yetkileri - DBMS özellikleri - Logging ve monitoring seviyesi - Uygulama mimarisi ### Application Account DBA Olursa Ne Olur? SQL Injection'ın etkisi çok daha büyük hale gelebilir. Bu nedenle web application hesabı hiçbir gereklilik yoksa DBA veya superuser olmamalıdır. ### Least Privilege SQL Injection'a Karşı Nasıl Korur? Zafiyeti ortadan kaldırmaz. Ancak saldırının etkisini sınırlar. Örneğin application yalnızca belirli tablolarda SELECT yapabiliyorsa saldırganın erişebileceği alan azalır. ### Defense in Depth Nedir? SQL Injection güvenliği tek kontrolle sağlanmamalıdır. Örnek: #### Secure Coding ↓ #### Parameterized Query ↓ #### Input Validation ↓ #### WAF ↓ #### Application Account Least Privilege ↓ #### Database Audit ↓ #### DAM / SIEM Bu yapı farklı savunma katmanları oluşturur. ### Parameterized Query Nedir? Parameterized Query, SQL komutu ile kullanıcı verisini birbirinden ayırır. Kullanıcı girdisi SQL syntax olarak değil, yalnızca veri olarak işlenir. SQL Injection'a karşı en temel savunma yöntemlerinden biridir. ### Prepared Statement Nedir? SQL sorgusunun önceden hazırlanıp parametrelerin ayrı şekilde bağlandığı yöntemdir. Parameterized Query ile aynı güvenlik prensibini destekler. ### Parameter Binding Nedir? Kullanıcı girdisinin SQL sorgusundaki parametrelere güvenli şekilde bağlanmasıdır. Bu sayede input sorgu yapısını değiştiremez. ### String Concatenation Neden Risklidir? Kullanıcı girdisini SQL string'i ile birleştirmek risk oluşturur. Özellikle dynamic query üretiminde kaçınılmalıdır. ### Dynamic SQL Nedir? SQL sorgusunun çalışma zamanında string olarak oluşturulmasıdır. Bazı durumlarda gerekli olabilir. Ancak kullanıcı girdisiyle birlikte kullanıldığında güvenli tasarım gerekir. ### Dynamic SQL Tamamen Yasaklanmalı mı? Her zaman mümkün değildir. Ancak mümkün olduğunca parameterized ve allow-list tabanlı yöntemler kullanılmalıdır. ### Input Validation SQL Injection'ı Engeller mi? Tek başına yeterli değildir. Input validation önemli bir ek kontroldür. Ana savunma parameterized query olmalıdır. ### Allow-List Validation Nedir? Sadece beklenen değerlerin kabul edilmesidir. Örneğin sort order yalnızca; ASC veya DESC olabilir. Bu durumda kullanıcıdan gelen her string kabul edilmez. ### Deny-List Validation Nedir? Belirli karakter veya kelimeleri engelleme yaklaşımıdır. Tek başına güvenilir değildir. Çünkü saldırgan farklı encoding veya syntax yöntemleri kullanabilir. ### Allow-List Neden Daha Güvenlidir? Beklenen değer kümesini tanımlar. Bilinmeyen her şey reddedilir. Bu daha kontrollü bir modeldir. ### Escaping SQL Injection İçin Yeterli mi? Her zaman değil. DBMS, encoding ve context'e göre escaping hataları oluşabilir. Parameterized query daha güvenli yaklaşım olmalıdır. ### ORM Nedir? ORM: #### Object Relational Mapping uygulama objeleri ile database tabloları arasında soyutlama sağlayan yazılım katmanıdır. ### ORM SQL Injection'ı Otomatik Engeller mi? Hayır. ORM doğru kullanıldığında parameterization sağlayabilir. Ancak developer raw SQL veya string concatenation kullanırsa SQL Injection yine oluşabilir. ### Raw SQL Nedir? ORM yerine doğrudan SQL sorgusu yazılmasıdır. Raw SQL kullanılacaksa parameterized olması gerekir. ### ORM Query Builder Güvenli midir? Güvenli API'ler kullanıldığında risk azalır. Ancak dynamic filter veya raw fragment eklenmesi dikkat gerektirir. ### Stored Procedure SQL Injection'ı Engeller mi? Otomatik olarak engellemez. Stored procedure içerisinde kullanıcı girdisi güvenli şekilde kullanılmalıdır. ### Stored Procedure İçinde Dynamic SQL Riskli mi? Evet. Girdi SQL string'ine doğrudan ekleniyorsa aynı risk devam eder. ### Stored Procedure Güvenlik Avantajı Sağlayabilir mi? Evet. Application'a doğrudan table permission vermek yerine sadece belirli procedure çalıştırma yetkisi verilebilir. ### EXECUTE Only Model Nedir? Application'ın tablolara doğrudan erişmek yerine sadece izin verilen stored procedure'leri çalıştırmasıdır. Bu saldırı yüzeyini azaltabilir. ### Stored Procedure İçin Least Privilege Gerekli mi? Evet. Procedure gereğinden fazla yetkiyle çalışmamalıdır. ### SQL Injection ve API Güvenliği Modern sistemlerde backend API'ler database'e erişir. Bu nedenle SQL Injection artık yalnızca klasik web form problemi değildir. REST API, GraphQL resolver, microservice gibi katmanlarda da risk oluşabilir. ### JSON Input SQL Injection'a Neden Olabilir mi? Evet. JSON içindeki string değer doğrudan SQL sorgusuna eklenirse risk oluşabilir. ### GraphQL SQL Injection'a Karşı Güvenli mi? GraphQL tek başına SQL Injection'ı engellemez. Backend resolver'ın database sorgusunu nasıl oluşturduğu belirleyicidir. ### Mobile Application SQL Injection Riski Taşır mı? Evet. Mobile uygulamanın backend API'si SQL Injection içerebilir. Ayrıca cihaz üzerindeki local database kullanımı da güvenli tasarlanmalıdır. ### Microservice Architecture SQL Injection Riskini Azaltır mı? Otomatik olarak hayır. Her microservice kendi database erişim katmanında aynı güvenli geliştirme prensiplerini uygulamalıdır. ### Database-per-Service Modeli Avantaj Sağlar mı? Blast radius'u azaltabilir. Bir microservice compromise olduğunda diğer database'lere doğrudan erişim olmayabilir. ### Shared Database Microservice Mimarisinde Riskli mi? Birçok servisin aynı database ve aynı credential'ı kullanması saldırının etkisini büyütebilir. ### Service Account Her Microservice İçin Ayrı Olmalı mı? Mümkün olduğunca evet. Bu hem Least Privilege hem Audit sağlar. ### WAF SQL Injection'ı Engeller mi? WAF birçok SQL Injection pattern'ini tespit edip engelleyebilir. Ancak ana çözüm değildir. ### Neden WAF Tek Başına Yeterli Değildir? Çünkü; encoding, obfuscation, business logic, API structure nedeniyle bazı saldırılar detection mekanizmasını aşabilir. Ayrıca WAF application code'daki zafiyeti düzeltmez. ### WAF Virtual Patching Nedir? Application zafiyeti düzeltilene kadar belirli saldırı pattern'lerini geçici olarak engelleme yöntemidir. ### Virtual Patch Kalıcı Çözüm mü? Hayır. Kalıcı çözüm source code'un düzeltilmesidir. ### RASP Nedir? RASP: #### Runtime Application Self-Protection uygulamanın çalışma anında şüpheli davranışları tespit etmeye veya engellemeye çalışan güvenlik yaklaşımıdır. ### RASP SQL Injection'a Yardımcı Olabilir mi? Evet. Ancak secure coding ve parameterization'ın yerine geçmez. ### Database Firewall Nedir? Database'e giden query'leri analiz eden güvenlik katmanıdır. ### Database Firewall SQL Injection'ı Tespit Edebilir mi? Bazı anomalileri veya yasaklanmış query pattern'lerini tespit edebilir. ### DAM SQL Injection Tespitinde Kullanılabilir mi? Evet. Database Activity Monitoring, alışılmadık query davranışlarını gösterebilir. ### SQL Injection Olayı Database Loglarında Görünür mü? Uygun audit ve logging varsa görülebilir. Ancak logging seviyesi yetersizse olayın detayını bulmak zor olabilir. ### SQL Injection İçin Hangi Loglar Önemlidir? Örneğin: Web server logs Application logs WAF logs Database audit logs DAM logs SIEM events birlikte analiz edilebilir. ### SOC SQL Injection'ı Nasıl İzler? SOC farklı kaynaklardan gelen olayları korele edebilir. Örneğin: WAF → Suspicious request Application → SQL error spike Database → Unusual query DAM → Bulk table read SIEM → Correlated incident ### SQL Error Spike Nedir? Normalden çok daha fazla database syntax veya query error oluşması saldırı denemesi veya application bug göstergesi olabilir. ### Failed Query Monitoring Faydalı mı? Evet. Özellikle kısa sürede birçok sıra dışı query error oluşması araştırılabilir. ### Sensitive Table Access SQL Injection Göstergesi Olabilir mi? Normal application davranışına uymuyorsa evet. ### Bulk Data Extraction Nasıl Tespit Edilebilir? Normalden çok daha fazla satır okunması veya büyük response oluşturulması izlenebilir. ### Query Baseline Nedir? Application'ın normalde çalıştırdığı query davranışlarının profilidir. ### Query Allow-Listing Kullanılabilir mi? Bazı yüksek güvenlik ortamlarında beklenen query pattern'leri tanımlanabilir. Ancak dinamik uygulamalarda dikkatli tasarım gerekir. ### Database Account Kaynak IP ile Sınırlandırılmalı mı? Evet. Application account yalnızca application server'lardan bağlanabilmelidir. ### Application Account Kullanıcı Laptop'undan Bağlanabilmeli mi? Genellikle hayır. Bu account yalnızca ilgili uygulama infrastructure'ından kullanılmalıdır. ### Application Database Credential Nasıl Saklanmalı? Source code içerisinde hard-coded tutulmamalıdır. Secret manager veya vault kullanılabilir. ### SQL Injection Sonrası Credential Ele Geçirilebilir mi? Database içerisinde veya application yapılandırmasında yanlış saklanan secret'lar varsa etki büyüyebilir. Bu nedenle sensitive secret'lar database içerisinde plaintext olarak tutulmamalıdır. ### Database İçinde Password Tutulmalı mı? Kullanıcı password'leri güvenli password hashing yöntemiyle tutulmalıdır. Reversible plaintext veya basit encryption uygun değildir. ### SQL Injection ve Password Hash Sızıntısı User tablosuna erişim sağlanırsa password hash'leri dışarı çıkabilir. Bu nedenle password hashing kalitesi de önemlidir. ### SQL Injection ve Data Classification İlişkisi Hangi tabloların hassas veri tuttuğu bilinirse bu tablolara erişimler daha sıkı izlenebilir. ### Sensitive Database Tables Nasıl Belirlenir? Data discovery ve classification ile; PII, payment, health, credential, financial veri içeren tablolar işaretlenebilir. ### Sensitive Table Access Ek Alarm Üretebilir mi? Evet. Örneğin application normalde bu tabloya erişmiyorsa beklenmeyen sorgu alarm oluşturabilir. ### SQL Injection ve Row-Level Security RLS ek bir savunma katmanı sağlayabilir. Application account compromise olsa bile kullanıcı sadece belirli satırları görebilir. ### SQL Injection ve Column-Level Security Kullanıcının hassas kolonlara erişimini sınırlandırabilir. ### Dynamic Data Masking SQL Injection'a Karşı Korur mu? Zafiyeti çözmez. Ancak bazı kullanıcıların gördüğü hassas veri miktarını azaltabilir. ### SQL Injection ve Encryption İlişkisi TDE SQL Injection'a karşı koruma sağlamaz. Çünkü database normal sorguya plaintext cevap verir. ### Column Encryption Yardımcı Olabilir mi? Encryption key application katmanında tutuluyorsa database üzerinden elde edilen ciphertext'in doğrudan anlamlı olmasını zorlaştırabilir. ### Application-Level Encryption SQL Injection Etkisini Azaltabilir mi? Evet. Özellikle çok hassas alanlarda ayrı cryptographic boundary avantaj sağlayabilir. ### SQL Injection ve Backup Güvenliği İlişkisi Var mı? Dolaylı olarak vardır. Saldırgan database üzerinde veri bozarsa recovery için güvenli backup gerekir. ### SQL Injection Veri Bütünlüğünü Bozabilir mi? Application account write yetkisine sahipse evet. Bu durumda Integrity etkilenir. ### Point-in-Time Recovery Neden Önemli Olabilir? Hatalı veya kötü niyetli veri değişikliğinin hangi anda gerçekleştiği biliniyorsa database önceki zamana döndürülebilir. ### SQL Injection Sonrası Restore Her Zaman Yeterli mi? Hayır. Önce saldırının kök nedeni kapatılmalıdır. Aksi halde restore edilen sistem tekrar etkilenebilir. ### Incident Response SQL Injection Olayında Nasıl Düşünülmeli? Genel savunma akışı: Detection ↓ Containment ↓ Application Investigation ↓ Database Activity Analysis ↓ Credential Review ↓ Impact Assessment ↓ Code Remediation ↓ Validation ↓ Recovery ### SQL Injection Sonrası Hangi Sorular Sorulmalı? Hangi endpoint etkilendi? Hangi database account kullanıldı? Hesabın hangi yetkileri vardı? Hangi tablolara erişildi? Veri değiştirildi mi? Export yapıldı mı? Credential sızdı mı? Zafiyet ne kadar süredir vardı? ### SQL Injection Veri İhlaline Dönüştü mü Nasıl Anlaşılır? Database audit, DAM, application logs, network logs incelenerek erişilen veri kapsamı belirlenmeye çalışılır. ### Audit Yoksa Ne Olur? Incident scope belirlemek çok zorlaşabilir. Bu nedenle preventive security kadar logging de kritiktir. ### SQL Injection ile Ransomware Aynı Şey mi? Hayır. Ancak saldırganın application ve database üzerindeki erişimi genişlerse veri bütünlüğü veya erişilebilirlik etkilenebilir. ### SQL Injection ve Insider Threat Arasında İlişki Var mı? Zafiyet dış saldırgan tarafından kullanılabileceği gibi içeride yetkili bir kullanıcı tarafından da kötüye kullanılabilir. ### Secure Software Development Lifecycle – SSDLC Nedir? Güvenliğin yazılım yaşam döngüsünün her aşamasına dahil edilmesidir. ### SQL Injection SSDLC İçinde Nerede Ele Alınmalı? Requirements, design, development, code review, testing, deployment aşamalarının tamamında düşünülmelidir. ### Secure Coding Standard Nedir? Developer'ların takip edeceği güvenli yazılım geliştirme kurallarıdır. SQL Injection açısından örneğin: Parameterized query zorunlu. Raw dynamic SQL kısıtlı. Secret hard-code yasak. gibi kurallar belirlenebilir. ### Code Review SQL Injection'ı Tespit Edebilir mi? Evet. Özellikle database query oluşturan kodlar review edilmelidir. ### SAST Nedir? SAST: #### Static Application Security Testing source code'u çalıştırmadan güvenlik zafiyetleri açısından analiz eder. ### SAST SQL Injection Bulabilir mi? Bazı taint flow ve query construction problemlerini tespit edebilir. Ancak false positive ve false negative olabilir. ### DAST Nedir? DAST: #### Dynamic Application Security Testing çalışan uygulamayı dışarıdan test eder. ### DAST SQL Injection Tespitinde Kullanılır mı? Evet. Web ve API input noktalarında SQL Injection belirtileri aranabilir. ### IAST Nedir? IAST: #### Interactive Application Security Testing uygulama çalışırken runtime ile test trafiğini birlikte analiz eder. ### SAST mı DAST mı Daha İyi? Birbirinin alternatifi değildir. Birlikte kullanıldığında daha güçlü coverage sağlayabilir. ### SCA SQL Injection Bulur mu? SCA daha çok third-party dependency risklerini analiz eder. Doğrudan custom SQL Injection code'unu bulma amacı taşımaz. ### Penetration Test SQL Injection İçin Gerekli mi? Web application ve API pentest sırasında SQL Injection kontrolleri yapılabilir. Ancak pentest secure SDLC'nin yerine geçmez. ### Code Review ile Pentest Birlikte Kullanılmalı mı? Evet. Code review root cause'u bulabilir. Pentest ise çalışan sistemde gerçek exposure'ı değerlendirebilir. ### CI/CD Pipeline SQL Injection Riskini Azaltabilir mi? Security testleri pipeline'a entegre edilirse zafiyetler production öncesi tespit edilebilir. ### DevSecOps SQL Injection'a Nasıl Yaklaşır? Örneğin: Developer IDE security plugin ↓ Secure Code Review ↓ SAST ↓ Unit Security Test ↓ DAST/API Test ↓ Production WAF/DAM/SIEM şeklinde katmanlı süreç kurulabilir. ### Security Unit Test Nedir? Belirli input'ların query construction davranışını bozmadığını doğrulayan otomatik testlerdir. ### Regression Test Neden Önemlidir? Daha önce kapatılan SQL Injection zafiyetinin yeni code change sonrası tekrar oluşmasını önlemeye yardımcı olur. ### False Positive Nedir? Security tool'un aslında zafiyet olmayan durumu zafiyet olarak işaretlemesidir. ### False Negative Nedir? Gerçek zafiyet olduğu halde security tool'un bunu tespit edememesidir. Bu nedenle tek araca güvenilmemelidir. ### Developer Security Training Neden Önemlidir? SQL Injection'ın kalıcı çözümü çoğu zaman source code düzeltmesidir. Developer güvenli query oluşturmayı bilmelidir. ### ORM Kullanan Developer'ların SQL Bilmesi Gerekir mi? Evet. ORM abstraction sağlar ancak underlying database davranışının anlaşılması güvenlik ve performans açısından önemlidir. ### Database DBA ile Developer Birlikte Çalışmalı mı? Evet. DBA; permission, stored procedure, performance alanında katkı sağlar. Developer ise application logic'i yönetir. ### AppSec ile DBA İş Birliği Neden Önemlidir? AppSec zafiyeti tespit eder. DBA database account yetkilerini ve olası impact'i değerlendirir. ### SQL Injection Risk Severity Nasıl Belirlenir? Sadece zafiyetin varlığına değil; erişilen veri, application account privilege, internet exposure, data classification, exploitability gibi faktörlere bakılmalıdır. ### CVSS SQL Injection İçin Kullanılabilir mi? Evet. Teknik severity değerlendirmesinde kullanılabilir. Ancak business impact ayrıca değerlendirilmelidir. ### SQL Injection ve Business Impact Örneğin; public ürün kataloğunda SQL Injection ile müşteri finans database'ine ulaşan SQL Injection aynı iş etkisine sahip değildir. ### Risk-Based Remediation Nedir? Zafiyetlerin business impact ve technical severity'ye göre önceliklendirilmesidir. ### Kritik SQL Injection Ne Kadar Hızlı Kapatılmalı? Kurumun vulnerability management SLA'sına göre mümkün olan en hızlı şekilde ele alınmalıdır. Internet-facing ve hassas veriye erişen zafiyetler en yüksek önceliğe alınabilir. ### SQL Injection İçin Compensating Control Nedir? Kalıcı düzeltme hemen yapılamıyorsa geçici olarak; WAF rule, endpoint restriction, account privilege reduction, monitoring uygulanabilir. Ancak source code remediation yine yapılmalıdır. ### SQL Injection ve API Gateway API Gateway; authentication, rate limiting, request validation sağlayabilir. Ancak backend'in SQL query güvenliğini otomatik garanti etmez. ### Rate Limiting SQL Injection'ı Engeller mi? Hayır. Ancak otomatik saldırı denemelerinin hızını azaltabilir. ### Authentication SQL Injection'ı Engeller mi? Hayır. Authenticated endpoint de SQL Injection içerebilir. ### Internal Application SQL Injection'dan Muaf mı? Hayır. Internal uygulamalar da compromise olmuş kullanıcı veya insider tarafından hedef alınabilir. ### “İnternete Açık Değil, Güvenli” Yaklaşımı Doğru mu? Hayır. Network location tek başına güvenlik garantisi değildir. ### Zero Trust SQL Injection İçin Ne İfade Eder? Application'ın database'e sınırsız güvenle erişmemesi, minimum yetki ve sürekli monitoring uygulanması anlamına gelir. ### Database Query Timeout Nedir? Çok uzun süren sorguların belirli süre sonra sonlandırılmasına yardımcı olabilir. ### Query Timeout Security Kontrolü müdür? Doğrudan SQL Injection önleme kontrolü değildir. Ancak resource exhaustion etkisini azaltabilir. ### Resource Governor Kullanılabilir mi? Bazı platformlarda kullanıcı veya workload'un CPU ve kaynak tüketimini sınırlamak için kullanılabilir. ### SQL Injection DoS Etkisi Oluşturabilir mi? Evet. Ağır query'ler database kaynaklarını tüketerek availability etkileyebilir. ### Connection Limit Neden Önemlidir? Application veya saldırı nedeniyle aşırı bağlantı database kaynaklarını tüketebilir. ### SQL Injection ve Query Cost Monitoring Normalden çok daha yüksek maliyetli sorgular anomaly olarak değerlendirilebilir. ### Database Error Handling Nasıl Olmalı? Kullanıcıya generic hata mesajı gösterilmeli. Detaylı database error server-side loglarda tutulmalıdır. ### Stack Trace Kullanıcıya Gösterilmeli mi? Production ortamında genellikle hayır. Framework, path, SQL ve internal sistem bilgisi sızdırabilir. ### Database Name Kullanıcıya Gösterilmeli mi? Gereksiz information disclosure azaltılmalıdır. ### SQL Error Log Tamamen Kapatılmalı mı? Hayır. Kullanıcıya gösterilmemeli ancak güvenli internal logging yapılmalıdır. ### Loglarda Hassas Veri Tutulabilir mi? Dikkat edilmelidir. SQL query logları password, token veya kişisel veri içerebilir. ### Log Masking Nedir? Log içerisindeki hassas alanların maskelenmesidir. ### Prepared Statement Her SQL Injection Türünü Çözer mi? Veri parametreleri için çok güçlüdür. Ancak table name, column name veya sort direction gibi SQL yapısal öğeleri parametrelemek her zaman mümkün değildir. Bu alanlarda allow-list kullanılmalıdır. ### Dynamic Table Name Nasıl Güvenli Yönetilir? Kullanıcıdan doğrudan table name alınmamalıdır. Uygulama önceden izin verilen seçenekleri kendi içerisinde eşlemelidir. ### ORDER BY Parametresi Riskli mi? Kullanıcı tarafından kontrol ediliyorsa dinamik SQL riski oluşturabilir. Allow-list kullanılmalıdır. ### Pagination SQL Injection Riski Taşır mı? Page, limit veya offset değerleri güvenli şekilde validate ve parametrize edilmelidir. ### Search Filter Riskli mi? Evet. Özellikle advanced search ekranları birçok dinamik query üretir. ### Reporting Module SQL Injection Açısından Neden Kritik? Dynamic filter, sorting ve complex query kullanımının yoğun olduğu alanlardır. ### Admin Panel SQL Injection Daha mı Riskli? Admin account'lar geniş uygulama fonksiyonlarına sahip olabilir. Ancak database account yetkisi yine minimum tutulmalıdır. ### Multi-Tenant Database SQL Injection Riski Bir müşterinin diğer müşterinin verisine ulaşması ciddi isolation problemidir. ### Tenant Isolation Nasıl Güçlendirilir? Application logic yanında; Row-Level Security, separate schema, separate database gibi modeller kullanılabilir. ### Tenant ID Kullanıcıdan Güvenilir Kabul Edilmeli mi? Hayır. Authorization server-side olarak doğrulanmalıdır. ### SQL Injection ile IDOR Aynı mı? Hayır. SQL Injection query manipulation zafiyetidir. IDOR ise authorization problemidir. Ancak her ikisi de yetkisiz veri erişimine yol açabilir. ### SQL Injection ile Command Injection Aynı mı? Hayır. SQL Injection database sorgularını hedefler. Command Injection operating system command execution riskidir. ### NoSQL Injection Nedir? MongoDB gibi NoSQL sistemlerinde query object veya filter'ın manipüle edilmesiyle oluşabilecek benzer injection sınıfıdır. ### Parameterized Query NoSQL İçin de Önemli mi? NoSQL teknolojisine göre güvenli query API'leri kullanılmalıdır. ### ORM Kullanmak NoSQL Injection'ı da Otomatik Çözmez mi? Hayır. Kullanıcı input'unun query object'e kontrolsüz aktarılması yine risk oluşturabilir. ### SQL Injection'a Karşı Kurumsal Kontrol Listesi Kurum şu kontrolleri değerlendirmelidir: - Parameterized Query - Prepared Statement - Input Allow-List - Secure ORM Usage - Dynamic SQL Review - Least Privilege - Separate Application Account - No DBA Privilege for Applications - Secret Management - WAF - API Security - SAST - DAST - Code Review - Database Audit - DAM - SIEM - Sensitive Data Monitoring - Secure Error Handling - Security Testing ### Developer SQL Injection Checklist Developer şu soruları sormalıdır: User input SQL string'e ekleniyor mu? Parameterized query kullanılıyor mu? Dynamic SQL gerçekten gerekli mi? Sort/filter alanlarında allow-list var mı? Raw SQL kullanılıyor mu? Database error kullanıcıya gösteriliyor mu? Application account gereğinden fazla yetkili mi? ### DBA SQL Injection Checklist DBA açısından: Application account DBA mı? Hangi tabloları okuyabiliyor? DROP yetkisi var mı? Stored procedure yetkileri doğru mu? Connection sadece application server'dan mı geliyor? Audit aktif mi? Sensitive table access izleniyor mu? ### SOC SQL Injection Checklist SOC açısından: WAF alertleri izleniyor mu? SQL error spike tespit ediliyor mu? Database audit SIEM'e geliyor mu? Bulk data query alarmı var mı? Application account anomalileri izleniyor mu? ### SQL Injection İçin Yönetimin Sorması Gereken Sorular Kurumsal yöneticiler şu soruların cevabını bilmelidir: Internet-facing uygulamalarımız düzenli security testinden geçiyor mu? Developer'lar parameterized query kullanıyor mu? Application database hesaplarımız minimum yetkili mi? SQL Injection bulunursa kapatma SLA'mız nedir? Database audit loglarımız var mı? Bir SQL Injection üzerinden veri çekilirse bunu tespit edebilir miyiz? Son pentest ne zaman yapıldı? ### Sık Sorulan Sorular #### SQL Injection nedir? Kullanıcı girdisinin güvenli olmayan şekilde SQL sorgusuna dahil edilmesi sonucu sorgu mantığının değiştirilebilmesi zafiyetidir. #### SQL Injection database zafiyeti midir? Genellikle application code'da oluşur ancak etkisi database üzerinde ortaya çıkar. #### SQL Injection nasıl önlenir? En temel yöntem Parameterized Query veya Prepared Statement kullanılmasıdır. #### Input validation yeterli mi? Hayır. Parameterization ana kontrol olmalıdır. #### ORM SQL Injection'ı engeller mi? Doğru kullanılırsa riski azaltır ancak raw veya dynamic SQL nedeniyle zafiyet yine oluşabilir. #### WAF SQL Injection'ı tamamen engeller mi? Hayır. WAF ek güvenlik katmanıdır; source code düzeltmesinin yerini tutmaz. #### TDE SQL Injection'a karşı korur mu? Hayır. TDE disk üzerindeki veriyi korur. Yetkili database sorguları plaintext veri alabilir. #### Application account DBA olmalı mı? Çoğu durumda kesinlikle hayır. Minimum yetki prensibi uygulanmalıdır. #### SQL Injection pentest ile bulunur mu? Evet, web ve API pentestlerinde SQL Injection testleri yapılabilir. Ancak secure coding ve sürekli güvenlik testlerinin yerine geçmez. #### SQL Injection sonrası ne yapılmalı? Zafiyet kapatılmalı, erişim kapsamı araştırılmalı, database logları incelenmeli, credential ve veri etkisi değerlendirilmelidir. ### Sonuç: SQL Injection'ın Etkisini Application Code Kadar Database Yetkileri Belirler SQL Injection çoğu zaman yazılım geliştirme problemi olarak görülür. Ancak gerçekte bu zafiyet: #### Application Security ile #### Database Security arasındaki sınırda bulunur. Application güvenli query oluşturmuyorsa zafiyet ortaya çıkar. Database account gereğinden fazla yetkiliyse zafiyetin etkisi büyür. Logging yoksa saldırı sonrası ne olduğunun belirlenmesi zorlaşır. Monitoring yoksa saldırı uzun süre fark edilmeyebilir. Bu nedenle SQL Injection'a karşı gerçek savunma: #### Parameterized Query #### Least Privilege #### Secure Coding #### WAF #### Database Audit #### DAM/SIEM yaklaşımıdır. En kritik prensip şudur: **Kullanıcı girdisi hiçbir zaman SQL komutu olarak güvenilir kabul edilmemelidir.** Uygulama input ile query syntax'ı birbirinden ayırmalıdır. Database ise application'a yalnızca gerçekten ihtiyaç duyduğu yetkileri vermelidir. Bu iki yaklaşım birlikte uygulandığında yalnızca SQL Injection oluşma olasılığı azaltılmaz; bir zafiyet ortaya çıksa bile saldırının blast radius'u ciddi ölçüde sınırlandırılabilir. Kurumsal açıdan doğru soru: **“Uygulamamızda SQL Injection var mı?”** değil; **“Bir uygulamamızda SQL Injection ortaya çıkarsa hangi database'e, hangi hesapla, hangi verilere ve ne kadar yetkiyle ulaşılabilir?”** olmalıdır. Bu soruya verilen cevap database güvenliğinin gerçek seviyesini gösterir.