SQL Injection (SQLi) Açıkları Nedir ve Prepared Statements ile Nasıl Engellenir?

1. Giriş ve Karşılaşılan Temel Zorluklar

Hacker'ların giriş formuna veya URL parametresine ' OR 1=1 -- gibi zararlı SQL komutları enjekte ederek tüm müşteri veritabanını ele geçirmesi veya silmesi en eski ve en tehlikeli OWASP zafiyetidir.

Modern kurumsal yazılım mimarisinde bu adımı doğru tasarlamak; hem uygulamanın bakım maliyetini (maintainability) düşürür hem de gelecekteki ölçekleme (scaling) süreçlerinde refactor ihtiyacını en aza indirir. Bu rehberde, sektörde kabul görmüş standartlar ışığında adım adım uygulamayı ele alıyoruz.

2. Ortam Hazırlığı ve Gerekli Bağımlılıklar

Geliştirmeye başlamadan önce sistem ortamınızın ve ilgili paketlerin hazır olduğundan emin olmalısınız. Terminalinizde aşağıdaki komutları çalıştırarak ilgili yapılandırmayı tamamlayın:

• Adım: Veritabanı sürücünüzde (PDO veya ORM) hazır deyim (Prepared Statements) desteğini aktifleştirin.
• Adım: Kullanıcı girdisini ham sorgu stringine ekleyen tüm eski kodları tespit edin.

3. Uygulama Mimarisi ve Kod Örneği

Aşağıdaki kod bloğunda, temiz kod (Clean Code) prensiplerine ve SOLID standartlarına uygun olarak tasarlanmış örnek implementasyonu inceleyebilirsiniz:

<?php
// ÖLÜMCÜL TEHLİKELİ KOD:
// $sql = "SELECT * FROM users WHERE email = '" . $_POST['email'] . "'";

// GÜVENLİ KOD: PDO Prepared Statement Kullanımı
$pdo = new PDO('mysql:host=localhost;dbname=kurumsal_db;charset=utf8mb4', $dbUser, $dbPass, [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false, // Gerçek sunucu seviyesinde hazırlık
]);

$stmt = $pdo->prepare('
    SELECT id, name, email, password_hash, role
    FROM users
    WHERE email = :email
      AND is_active = 1
    LIMIT 1
');

// Parametre ayrı bir paket olarak veritabanı motoruna iletilir, asla kod olarak yorumlanamaz
$stmt->execute([
    'email' => $_POST['email']
]);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

4. Kod Analizi ve Çalışma Mantığı

prepare() komutu veritabanı motoruna sorgunun şablonunu iletir. execute() ile gelen parametreler ise yalnızca 'veri' olarak işlenir; tırnak işaretleri veya SQL anahtar kelimeleri sorgu yapısını değiştiremez.

Yukarıdaki implementasyonda dikkat edilmesi gereken en kritik husus, işlemlerin bağımsız (decoupled) ve test edilebilir şekilde katmanlara ayrılmış olmasıdır. Bu yaklaşım, birim testlerin (Unit Tests) ve entegrasyon testlerinin hızlıca yazılabilmesine olanak tanır.

5. Performans ve Güvenlik İpuçları

Canlı üretim (production) ortamında sistemin kararlı çalışması için aşağıdaki pratikleri mutlaka dikkate almalısınız:

• PDO::ATTR_EMULATE_PREPARES seçeneğini 'false' yaparak sahte değil gerçek sunucu tabanlı parametre bağlama sağlayın.
• Ham SQL sorguları yerine Laravel Eloquent veya Prisma gibi modern ORM'lerin koruyucu katmanlarını kullanın.
• Veritabanı kullanıcısına sadece ihtiyaç duyduğu yetkileri (Least Privilege Principle) tanıyın; web uygulamasına DROP DATABASE yetkisi vermeyin.

6. En Sık Yapılan Hatalar ve Hata Ayıklama (Troubleshooting)

LIKE aramalarında '%$search%' ifadesini prepare etmeden string içine gömmek SQL Injection açığı yaratmaya devam eder.

Eğer beklenmedik bir hata ile karşılaşırsanız; öncelikle log dosyalarını incelemeli, ortam değişkenlerinin (.env) doğru tanımlandığını doğrulamalı ve önbellek (cache) mekanizmalarını temizleyerek sistemi yeniden başlatmalısınız.

7. Sonuç ve Mimari Değerlendirme

Parametreli sorgular (Prepared Statements), veritabanı güvenliğinin tartışmasız ilk ve en temel kuralıdır.

Cengiz Bozdemir olarak 18 yılı aşkın kurumsal yazılım mimarlığı deneyimimle tavsiyem; sistem tasarımında her zaman sürdürülebilirlik, güvenlik ve yüksek eşzamanlılık (high concurrency) hedeflerini ön planda tutmanızdır. Kurumsal projelerinizde özel mimari danışmanlık veya uçtan uca yazılım geliştirme desteği için bizimle iletişime geçebilirsiniz.