Güvenli kodlama: girdi doğrulama, SQL injection, XSS, buffer overflow, CSRF

Geçen hafta tasarım kararlarını konuştuk. Bu hafta tek tek kod satırlarına iniyoruz. Sınavda neredeyse kesin gelen soru tipi: sana açık bir kod parçası verilir, “what is the vulnerability, how do you fix it?” ya da “what query is executed for this input?” diye sorulur. Beş açığın hepsi aynı kökten gelir: dışarıdan gelen veriye güvenmek ve veriyi kodla karıştırmak.

Altın kurallar:

1. Her girdi düşmandır. Form alanı, URL, çerez, HTTP başlığı, dosya adı, API yanıtı.
2. Doğrulamayı sunucuda yap. JavaScript kontrolü kullanıcı içindir, saldırgan onu atlar.
3. Veriyi koddan ayır. SQL için parametre, HTML için kodlama, komut için argüman dizisi.
4. Sınırları bil. C’de her tamponun boyutu ve \0 baytı hesapta olmalı.
5. Durum değiştiren her istek kanıt ister. CSRF token olmadan transfer yok.

Bu sayfadaki kod parçaları açığı anlamak ve düzeltmek için. Gerçek bir sistemde izinsiz denemek suçtur.

Girdi doğrulama (input validation)

İki yaklaşım var:

Allowlist örneği: kullanıcı adı sadece harf, rakam, alt çizgi ve 3-16 karakter.

const USERNAME = /^[A-Za-z0-9_]{3,16}$/;
for (const s of ["deniz_07", "ab", "ali veli", "x<script>", "AAAAAAAAAAAAAAAAA"]) {
  console.log(JSON.stringify(s), USERNAME.test(s));
}

"deniz_07" true
"ab" false
"ali veli" false
"x<script>" false
"AAAAAAAAAAAAAAAAA" false

Son girdi 17 karakter, bir fazla. ^ ve $ çapaları şart: onlar olmadan regex metnin bir parçasını eşleştirir ve geri kalanı denetlenmez.

TUZAK · Doğrulama tek savunma değildir. İsim alanında O'Brien meşrudur, tırnak içerir. Bu yüzden doğrulama yanında SQL için parametre, HTML için kodlama da gerekir. Doğrulama “biçim doğru mu” sorusunu, kodlama “bu bağlamda güvenli mi” sorusunu cevaplar.

SQL injection

Sorun, sorguyu metin birleştirerek kurmak:

// AÇIK: girdi SQL metnine yapıştırılıyor
String sql = "SELECT * FROM users WHERE name = '" + name + "'";
ResultSet rs = stmt.executeQuery(sql);

Ders kitaplarının klasik örneği: name = ' OR '1'='1. Metin şuna dönüşür:

SELECT * FROM users WHERE name = '' OR '1'='1'

'1'='1' her satırda doğru, sorgu tüm tabloyu döndürür. Üç kullanıcılı tabloda simülasyon:

rows matched (concat)   3
rows matched (param)    0

Düzeltme, parametreli sorgu:

// GÜVENLİ: sorgu yapısı sabit, girdi sadece değer
PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();

Veritabanı sorguyu önce derler, ? yerine gelen değeri hiçbir zaman SQL olarak yorumlamaz. Aynı girdiyle adı tam olarak ' OR '1'='1 olan kullanıcı aranır, 0 satır döner.

Ek katmanlar: veritabanı kullanıcısına sadece gereken tablolarda gereken yetkiyi ver (least privilege), hata mesajında SQL ayrıntısı gösterme, ORM kullanıyorsan ham sorgu birleştirmekten kaçın.

TUZAK · AND/OR önceliği. ... WHERE user = 'admin' AND pass = ' + girdi + ' sorgusunda girdi x' OR 'a'='a olursa metin user = 'admin' AND pass = 'x' OR 'a'='a' olur. AND önce bağlanır: (user='admin' AND pass='x') OR 'a'='a', sonuç her satırda doğru. Çözüm yine parametre.

Cross-site scripting (XSS)

XSS’te saldırgan kendi script’ini başka bir sitenin sayfasında, o sitenin kullanıcısının tarayıcısında çalıştırır. Çerez çalma, sahte form gösterme, kullanıcı adına işlem yapma mümkün olur.

Açık ve düzeltilmiş kod:

// AÇIK: kullanıcı metni HTML olarak yorumlanır
comment.innerHTML = userText;

// GÜVENLİ: metin olarak eklenir, etiket oluşturmaz
comment.textContent = userText;

Sunucu tarafında şablon kullanıyorsan çıktıyı HTML bağlamına göre kodla:

const esc = (s) => s.replace(/&/g, "&amp;").replace(/</g, "&lt;")
  .replace(/>/g, "&gt;").replace(/"/g, "&quot;").replace(/'/g, "&#x27;");
console.log(esc('<b>"Hi"</b>'));
console.log(esc("<script>alert(1)</script>"));
console.log(esc("Tom & Jerry's"));

<b>"Hi"</b>
<script>alert(1)</script>
Tom & Jerry's

& her zaman ilk değiştirilir; yoksa sonradan üretilen < içindeki & tekrar kodlanır. Bağlam önemlidir: HTML gövdesi, HTML özniteliği, JavaScript metni ve URL için kurallar farklıdır. Modern şablon motorları (React JSX, Thymeleaf) varsayılan olarak kodlar.

İkinci katman Content Security Policy: Content-Security-Policy: script-src 'self' başlığı tarayıcıya sadece kendi origin’inden gelen script dosyalarını çalıştırmasını söyler, satır içi script engellenir. Üçüncü katman: oturum çerezine HttpOnly vermek, böylece JavaScript çerezi okuyamaz.

Buffer overflow (C)

C dizileri boyutlarını bilmez. strcpy kaynağın sonunu (\0) görene kadar kopyalar, hedefin dolup dolmadığına bakmaz.

/* AÇIK */
void greet(const char *name) {
    char buf[10];
    strcpy(buf, name);          /* uzunluk kontrolü yok */
    printf("Hello %s\n", buf);
}

name = "HelloWorld!!" (12 karakter) ise 13 bayt yazılır, 10 baytlık tamponun 3 bayt dışına taşar. Yığında tamponun ötesinde başka değişkenler ve fonksiyonun dönüş adresi durur; bunların bozulması çökme ya da kontrol akışının ele geçirilmesi demektir.

/* GÜVENLİ */
void greet(const char *name) {
    char buf[10];
    if (strlen(name) >= sizeof buf) {   /* \0 için yer kalmalı */
        fprintf(stderr, "name too long\n");
        return;
    }
    snprintf(buf, sizeof buf, "%s", name);
    printf("Hello %s\n", buf);
}

Derleyici ve işletim sistemi katmanları (stack canary, ASLR, DEP/NX) saldırıyı zorlaştırır ama hatayı düzeltmez. Kalıcı çözüm sınır kontrolü ya da bellek güvenli bir dil (Java, Rust, Go).

TUZAK · off-by-one. char buf[16] için en uzun güvenli metin 15 karakterdir. if (len <= sizeof buf) yazarsan 16 karakter + \0 = 17 bayt yazılır. Doğrusu len < sizeof buf.

Cross-site request forgery (CSRF)

Kullanıcı bankaya giriş yapmış, oturum çerezi tarayıcıda. Başka bir sitede gizli bir form bankaya otomatik POST gönderir. Tarayıcı çerezi kendiliğinden ekler, sunucu isteği kullanıcıdan geldi sanır. XSS’ten farkı: saldırgan bankanın sayfasında kod çalıştırmaz, sadece kullanıcının tarayıcısına istek attırır.

<!-- AÇIK: sunucu sadece çereze bakıyor -->
<form action="/transfer" method="POST">
  <input name="to"> <input name="amount">
</form>

<!-- GÜVENLİ: oturuma bağlı, tahmin edilemez token -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="(sunucunun ürettiği rastgele değer)">
  <input name="to"> <input name="amount">
</form>

Sunucu her durum değiştiren istekte token’ı oturumdaki değerle karşılaştırır, uyuşmazsa reddeder. Saldırganın sayfası bu değeri okuyamaz (same-origin policy). Ek savunmalar: çereze SameSite=Lax ya da Strict vermek (çerez siteler arası POST’ta gönderilmez), kritik işlemde parola ya da MFA tekrar istemek, GET isteklerini asla durum değiştirmek için kullanmamak.

Sık yapılan hatalar

String sql = "SELECT * FROM users WHERE name = '" + name + "'";
ResultSet rs = stmt.executeQuery(sql);

PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();

char buf[8];
strcpy(buf, input);   /* no length check */