> For the complete documentation index, see [llms.txt](https://emre-ermenek.gitbook.io/sqli-egitimi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://emre-ermenek.gitbook.io/sqli-egitimi/sql-injection-sqli-egitim-modulu-ve-portswigger/mitigation-onleme.md).

# Mitigation(Önleme)

#### Mitigation (Sistemleri SQL Injection'dan Nasıl Koruruz?)

**1. Kesin Çözüm: Prepared Statements (Parametrik Sorgular)** SQL Injection'ı önlemenin bir numaralı, en kesin ve tartışmasız kuralı "Prepared Statements" kullanmaktır.

*Neden işe yarar?* Çünkü bu yöntem, **SQL komutu ile kullanıcının girdiği veriyi birbirinden tamamen ayırır.** Veritabanına önden bir şablon gönderilir ve denir ki: *"Sana birazdan bir veri göndereceğim. İçinde tek tırnak da olsa, UPDATE kelimesi de olsa bunu ASLA bir komut olarak algılama, sadece zararsız bir metin (veri) olarak oku."*

```php
// Güvensiz (Klasik) Yöntem:
$sql = "SELECT * FROM users WHERE username = '$username'";

// Güvenli (Prepared Statement) Yöntemi:
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username");
$stmt->execute(['username' => $username]);
```

**2. Asla Güvenme: Girdi Doğrulama (Input Validation)** Kullanıcıdan gelen hiçbir veriye güvenmeyin. Eğer kullanıcıdan bir "Yaş" veya "ID" numarası istiyorsanız, sistemin sadece rakamları kabul ettiğinden emin olun. Harf veya noktalama işareti girildiğinde sistemi durdurun ve hata verin (Buna *Whitelist* yani Beyaz Liste mantığı denir).

**3. Hasar Kontrolü: En Az Yetki Prensibi (Least Privilege)** Diyelim ki bir şekilde kodunuzda açık kaldı ve hacker veritabanına sızdı. İşte burada hasar kontrolü devreye girer. Bir web uygulamasını veritabanına bağlarken **ASLA** `root`, `admin` veya `sa` (System Administrator) gibi en yetkili hesabı kullanmayın. Eğer web sitenizin sadece makale okumak ve yorum yazmak için veritabanına erişmesi gerekiyorsa, ona sadece `SELECT` ve `INSERT` yetkisi verin. `DROP` (Tablo silme) yetkisi olmayan bir kullanıcı hesabı kullanırsanız, hacker içeri sızsa bile tablolarınızı silemez.

**4. Stored Procedures (Saklı Yordamlar) Kullanımı**

Tıpkı Prepared Statements gibi, SQL mantığını uygulamanın içinde değil de doğrudan veritabanının kendi içinde önceden derlenmiş bir şekilde tutma yöntemidir.

> **Önemli Uyarı:** Stored Procedure kullanmak tek başına sihirli bir koruma sağlamaz! Eğer veritabanı uzmanı, Stored Procedure'ün *içerisinde* gelen verileri güvenli parametreler olarak işlemek yerine, metin birleştirme (String Concatenation / Dinamik SQL) yöntemleriyle işlerse, sistem SQL Injection'a karşı **hala savunmasızdır.**

**5. Düzenli Kod İncelemesi (Code Review) ve WAF** Yazının önceki bölümlerinde WAF'ları (Web Application Firewall) nasıl atlattığımızı gördük. WAF'lar tek başına bir kurtarıcı değildir ama **harika bir ilk savunma hattıdır.** Çoğu amatör saldırıyı ve script kiddie taramalarını daha kapıdayken engeller. Bunun yanında düzenli aralıklarla kaynak kodlarınızı güvenlik testinden (Code Review) geçirmek hayat kurtarır.

***

#### Kapanış ve Gerçek Bir Dünyaya Bakış

Bu modül boyunca SQL Injection'ı her yönüyle öğrendiniz. Ancak bu zafiyetin gerçek dünyada nasıl bir "anahtar" olarak kullanıldığını görmek siber güvenlik vizyonunuzu çok daha ileriye taşıyacaktır.

Sektörün en saygın isimlerinden biri olan ve siber güvenlik alanına ilgi duymama vesile olan **Mehmet Dursun İnce**’nin, gerçek bir üründe keşfettiği SSRF ve SQL Injection zafiyetlerini nasıl zincirlediğini (Exploit Chain) anlattığı şu harika sunumu kesinlikle izlemenizi tavsiye ederim:

<https://youtu.be/7uK9Gce4PQs?si=yk6JUloFQjNMoJd9>