Hafta 5 — Kod Sağlamlaştırma: Java ve Yorumlanan Diller¶

Sunumun içine tıklayıp ok tuşlarıyla ilerleyin; tam ekran için sunumun sağ altındaki düğmeyi ya da yukarıdaki "Sunumu tam ekran aç" bağlantısını kullanın.

java -version; python --version
cd cen429-secure-programming\code\week-05\01-sql-injection
.\demo.ps1

sudo apt install -y openjdk-17-jdk python3
cd cen429-secure-programming/code/week-05/01-sql-injection
sh demo.sh

0. Başlamadan önce¶

Bu bölüm haftaya hazırlık içindir. Önce bu haftanın dayandığı önceki konuları kısaca hatırlatır; sonra bu haftanın kavramlarını birer cümleyle tanımlayıp her birini ayrıntılı anlatıldığı bölüme bağlar. Önceki haftalarda görülmemiş temel bilgiler ise "Ön bilgi" başlıkları altında sıfırdan anlatılır.

Önceki haftalardan gelenler¶

• Bellek hataları (taşma, serbest bellek kullanımı, tanımsız davranış) — ilk dört hafta boyunca C/C++'ta arabellek taşmasının, serbest bırakılmış belleğin kullanımının ve tanımsız davranışın nasıl oluştuğunu ve önlendiğini gördük (Hafta 4). Bu hafta §1'de bu hata sınıflarının hangilerinin yönetilen dillerde dil düzeyinde ortadan kalktığını, hangilerinin kalmadığını karşılaştırıyoruz.
• SEI CERT kural kitabının yapısı — dördüncü haftada SEI CERT C/C++ kurallarının kimlik, başlık, hatalı örnek, uyumlu çözüm ve risk bölümlerinden oluşan ortak yapısını görmüştük (Hafta 4, §2). Bu hafta §2'de aynı yapıyı Java standardında, IDS/SER/FIO/MSC/ERR kategorileriyle yeniden kullanıyoruz.
• TOCTOU (denetim ile kullanım arasındaki zaman) — ikinci haftada bir dosyanın izin denetimiyle gerçek kullanımı arasındaki zaman farkının bir yarış durumu açığı olduğunu görmüştük (Hafta 2, §12). Bu hafta §6'da yol geçişine karşı dosya açıldıktan sonra da kök içinde kalındığının doğrulanmasını aynı ilkeyle gerekçelendiriyoruz.

Bu haftanın kavram haritası¶

Ön bilgi: Yönetilen diller ve çöp toplama¶

Bir yönetilen dil (managed language — Java, C#, Python, JavaScript gibi), belleği programcı yerine çalışma ortamının otomatik yönettiği bir dildir; programcı malloc/free çağırmaz, bunun yerine bir çöp toplayıcı (garbage collector, GC) artık kullanılmayan nesneleri arka planda otomatik olarak temizler. Bu tek fark, ilk dört haftada C/C++'ta gördüğümüz taşma ve serbest bellek kullanımı gibi hataların büyük kısmının dil düzeyinde ortadan kalkmasını sağlar; §1 bunu ayrıntılı biçimde gösterir.

Ön bilgi: Veritabanları ve SQL¶

SQL, bir veritabanına sorgu göndermek için kullanılan sorgulama dilidir (SELECT ... WHERE ... gibi); bir uygulama, kullanıcıdan aldığı bir değeri (kullanıcı adı, arama terimi) bu sorgunun içine koyarak veritabanından veri okur ya da yazar. Bu değer sorgunun metnine kaçışsız biçimde eklenirse §3–4'te göreceğimiz SQL enjeksiyonu ortaya çıkar.

Ön bilgi: Yansıma ve bağımlılıklar¶

Yansıma (reflection), bir sınıfı ya da metodu kaynak kodda doğrudan adıyla yazmak yerine çalışma anında bir dizeden (Class.forName("..."), getMethod("...") gibi) bulup çağırma yeteneğidir; §12 bunun gizlemeyle nasıl etkileştiğini gösterecek. Bağımlılık (dependency), projenizin kullandığı, kendi ekibinizin yazmadığı dış bir kütüphanedir; kendi kodunuz güvenli olsa bile, kullandığınız bir bağımlılıktaki bir açık uygulamanızı da etkiler — §14 bunu SBOM ile ele alır.

Kavramlar birbirine nasıl bağlanır?¶

Yukarıdaki terimler rastgele bir liste değildir; her biri bir öncekinin üstüne oturur. Aşağıdaki tablo "bunu anlamak için önce şunu bilmem gerekir" ilişkisini gösterir — bir terimi unutursanız tablodaki "önkoşul" sütununa geri dönün.

Bu tablonun okunuş yönü önemlidir: satır başındaki terimi anlamak için önce "önkoşulu" sütunundaki terimi bilmelisiniz. Örneğin "parametreli sorgu" bölümünü okumadan önce "enjeksiyon" kavramının ("veri, komutla aynı kanaldan geçerse komut sanılır") oturmuş olması gerekir; aksi hâlde "neden ? işareti güvenli de dize birleştirme değil?" sorusu havada kalır.

1. Yönetilen diller neyi çözer, neyi çözmez?¶

İlk dört hafta C ve C++ ile geçti: arabellek taşması, serbest bırakılmış bellek, tamsayı taşması, tanımsız davranış. Java, Kotlin, C#, Python, JavaScript gibi yönetilen (managed) dillerde bu hataların büyük kısmı dil düzeyinde ortadan kalkar:

Bu büyük bir kazançtır; ama "Java kullanıyoruz, güvendeyiz" demek için yeterli değildir. Aşağıdaki sınıflar dilden bağımsızdır ve web uygulamalarından mobil uygulamalara kadar en çok bulunan zafiyetlerdir:

İşlenmiş örnek: bir dizi taşması Java'da neden çöker de C'de çökmez¶

Dördüncü haftada buf[10] gibi 10 elemanlı bir diziye 10. indeksle (11. eleman) yazmanın C'de tanımsız davranış olduğunu, çoğu zaman hiçbir hata vermeden bitişik belleği bozduğunu görmüştük. Aynı hatayı Java'da adım adım izleyelim.

public class ArrayOverflow {
    public static void main(String[] args) {
        int[] array = new int[10];      // a 10-element array: indices 0..9 are valid
        array[9] = 42;                   // valid: the last element
        System.out.println("array[9] = " + array[9]);
        array[10] = 99;                  // INVALID: there is no 11th element
    }
}

array[9] = 42
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
    Index 10 out of bounds for length 10
        at ArrayOverflow.main(ArrayOverflow.java:6)

Adım adım ne oldu:

1. JVM her dizi erişiminde (array[10]) önce indeksin 0 ≤ i < length sınırında olup olmadığını denetler; bu denetim derleyicinin ürettiği bayt kodunun her aload/iastore öncesinde çalışan bir parçasıdır.
2. 10, dizinin uzunluğu olan 10'a eşit ya da büyük olduğu için denetim başarısız olur.
3. JVM bitişik belleğe yazmaz; bunun yerine ArrayIndexOutOfBoundsException fırlatır ve programı (ya da try/catch varsa yalnız o bloğu) kontrollü biçimde durdurur.
4. Hangi satırda, hangi indeksle olduğu hata iletisinde görünür — dördüncü haftadaki C örneğinde ise sessiz bir bellek bozulması ya da rastgele bir çökme olurdu, hatanın kaynağını bulmak saatler sürebilirdi.

2. SEI CERT Oracle Java: yönetilen dilin kural kitabı¶

Dördüncü haftada tanıdığımız SEI CERT'in Java standardı da aynı yapıdadır: kimlik, başlık, hatalı örnek, uyumlu çözüm, risk. Kimlikler -J sonekiyle biter.

Neden CERT kuralları hâlâ gerekli, Java bellek hatalarını çözdüyse?¶

Dördüncü haftada C için gördüğümüz SEI CERT C kuralları (ARR, STR, MEM…) büyük ölçüde bellek yönetimi hatalarını hedefliyordu; JVM bu sınıfı otomatik olarak kapattığı için Java standardında MEM kategorisi neredeyse boştur. Ama tablodaki IDS, SER, FIO, MSC, ERR kategorileri dilin çözmediği hatalardır: girdi doğrulama, seri durumdan çıkarma, hassas bilginin sızması gibi konular bellekle değil tasarım kararlarıyla ilgilidir. Bu yüzden CERT, dilden dile "hangi kategori büyür, hangisi küçülür" ilkesiyle çalışır: C standardında MEM ve ARR kalın, Java standardında IDS ve SER kalın basılıdır.

3. Enjeksiyonun ortak kökü: veri ile komutun karışması (Tarif 3.11)¶

SQL enjeksiyonu, komut enjeksiyonu, yol geçişi, XML enjeksiyonu, şablon enjeksiyonu, 2. haftadaki günlük enjeksiyonu ve 4. haftadaki biçim dizesi açığı aynı hatanın farklı yüzleridir: bir yorumlayıcıya (SQL motoru, kabuk, dosya sistemi, XML ayrıştırıcı, printf) verilen metnin içinde komut ile veri aynı kanaldan geçer. Kullanıcı verisi, yorumlayıcının özel karakterlerini (', ;, ../, <, %) içeriyorsa, veri komutun bir parçası olur.

Bu yüzden bütün enjeksiyonların asıl düzeltmesi aynıdır: komut ile veriyi ayrı kanallardan ver. Kaçış karakteriyle temizlemek (' → '') ikinci savunma hattıdır; her yorumlayıcının kaçış kuralları farklıdır ve bir tanesini unutmak yeter.

Yorumlayıcı girdiyi neden "kod" sanır? Adım adım¶

Öğrencilerin en çok kaçırdığı halka budur: yorumlayıcı, kendisine gelen dizenin hangi karakterlerinin "programcının yazdığı sabit kod", hangilerinin "kullanıcının girdiği veri" olduğunu bilmez. Elindeki tek şey, art arda gelen karakterlerdir. Bunu somutlaştıralım; "SELECT ... WHERE name = '" + name + "'" ifadesinin çalışma zamanında oluşturduğu dizeyi bir SQL motorunun nasıl okuduğunu karakter karakter izleyelim (name değişkeninin içinde x' OR '1'='1 girdisi olduğunu varsayalım):

1. Java önce dize birleştirmeyi yapar; sonuçta ortaya tek bir düz metin çıkar: SELECT ... WHERE name = 'x' OR '1'='1'. Bu noktadan itibaren "bu parça geliştiricinin yazdığı", "bu parça kullanıcının girdiği" bilgisi kaybolmuştur — elde yalnız karakterler vardır.
2. Bu düz metin SQL motoruna tek bir komut olarak gönderilir. Motorun ayrıştırıcısı (lexer/parser) dizeyi soldan sağa, karakter karakter tarar ve her karaktere göre bir duruma girer.
3. WHERE name = okunduktan sonra bir boşluk, sonra bir ' karakteriyle karşılaşır → ayrıştırıcı "dize sabiti başladı" durumuna geçer. Bundan sonraki her karakteri (harf, boşluk, O, R…) bu dize sabitinin içeriği sayar, bir sonraki ' karakterine kadar.
4. Girdideki ilk ' (kullanıcının yazdığı) tam olarak bu bekleneni sağlar: ayrıştırıcı "dize sabiti bitti" der ve normal SQL söz dizimine geri döner.
5. Geri dönülen noktada ayrıştırıcının önünde artık OR '1'='1' metni durur; bu metin SQL anahtar sözcükleri ve operatörleri olarak okunur (OR, =), çünkü ayrıştırıcı "dize sabiti" durumundan çıkmıştır.
6. Sonuç: motor tek bir sorgu ayrıştırmıştır, ama bu sorgunun mantıksal yapısı (... AND ... yerine ... OR always_true) kullanıcının girdiği karakterler tarafından belirlenmiştir.

Kritik nokta şudur: ayrıştırıcı hata yapmıyor; tam olarak SQL söz dizimi kurallarına göre davranıyor. Hata, yorumlayıcıya "kodun bir parçası mısın, veri misin?" bilgisini taşıyan ayrı bir kanal olmamasıdır. Aynı adım dizisi (bir yorumlayıcı → karakter karakter tarama → özel karakterde durum değişikliği) kabuk için ;, dosya sistemi için ../, XML için </& ile birebir tekrarlanır; yalnız "özel karakter" ve "durum makinesi" değişir. Bölüm 4–8, bu adımların her yorumlayıcıdaki somut karşılığını gösterecek.

4. SQL enjeksiyonu¶

Bir giriş formunun arkasında şöyle bir kod olduğunu düşünün:

String sql = "SELECT id, role FROM users WHERE name = '" + name +
             "' AND password_hash = '" + hash + "'";
ResultSet rs = connection.createStatement().executeQuery(sql);

Kullanıcı adı alanına alice yazıldığında sorgu beklendiği gibidir. Ama kullanıcı alice' -- yazarsa sorgu şuna dönüşür:

SELECT id, role FROM users WHERE name = 'alice' --' AND password_hash = '...'

-- SQL'de satır sonuna kadar yorum demektir: parola denetimi sorgudan silinmiştir. Girdideki tek bir tırnak işareti, sorgunun yapısını değiştirdi. Aynı teknikle saldırgan başka tabloları okuyabilir (UNION SELECT), kayıtları değiştirebilir ya da silebilir; veritabanı yapılandırmasına göre işletim sistemi komutu bile çalıştırabilir. SQL enjeksiyonu yirmi yılı aşkın süredir OWASP Top 10 listelerinin üst sıralarındadır (CWE-89).

Doğrusu: parametreli sorgu¶

String sql = "SELECT id, role FROM users WHERE name = ? AND password_hash = ?";
try (PreparedStatement ps = connection.prepareStatement(sql)) {
    ps.setString(1, name);
    ps.setString(2, hash);
    try (ResultSet rs = ps.executeQuery()) {
        /* ... */
    }
}

Sorgunun metni sabittir ve veritabanına önce gönderilip derlenir; değerler ayrı bir kanaldan gelir. Değer ne içerirse içersin (', --, ;), yalnız bir değer olarak karşılaştırılır; sorgunun yapısına dokunamaz. Bu, önceki bölümdeki "iki kanal" ilkesinin tam karşılığıdır (IDS00-J).

Aşağıdaki canlandırma, bir parola değerinin harf harf sorgu metnine eklendiğinde saldırganın tek bir tırnak işaretiyle "veri"yi nasıl "koda" çevirdiğini — ve parametreli sorguda bunun neden mümkün olmadığını — gösterir.

Normal, Zor (' OR '1'='1) ve Uç durum örneklerini deneyin; 🎲 ile rastgele bir parola üretin ya da kendi değerinizi yazın.

Parametreli sorgu mekanik olarak neden çalışır?¶

Bölüm 3'te ayrıştırıcının karakter karakter çalıştığını gördük. PreparedStatement bu mekanizmayı iki aşamaya böler; sihir burada gizlidir:

1. Hazırlama (prepare) aşaması: connection.prepareStatement(sql) çağrıldığında, veritabanı sunucusuna yalnız SELECT id, role FROM users WHERE name = ? AND password_hash = ? metni gönderilir — kullanıcının girdisi henüz ortada yoktur. Sunucu bu metni ayrıştırır (Bölüm 3'teki durum makinesiyle), bir sorgu planı (query plan) üretir ve bu planı bellekte tutar. ? işaretleri plan içinde "buraya bir değer gelecek" diye işaretlenmiş yer tutuculardır.
2. Bağlama (bind) aşaması: ps.setString(1, name) çağrıldığında, name değişkeninin içeriği hiçbir zaman SQL metniyle birleştirilmez. Sürücü, değeri ayrı bir binary protokol mesajıyla (JDBC/veritabanı arasındaki tel protokolü) "1 numaralı yer tutucunun değeri şu bayt dizisidir" diye gönderir.
3. ps.executeQuery() çalıştığında veritabanı, zaten ayrıştırılmış olan plana, gelen değerleri doğrudan yerleştirir. Değerin içinde ' ya da -- olsa bile, bu karakterler hiçbir zaman ayrıştırıcıdan geçmez — ayrıştırma çoktan bitmiştir. Karakterler yalnız "bu sütunla karşılaştırılacak bayt dizisi" olarak kopyalanır.

Bunu Bölüm 3'teki printf("%s", input) örneğiyle karşılaştırmak öğretici: %s'in yerine konan dize, biçim dizesindeki bir %n gibi yeniden yorumlanmaz; olduğu gibi yazdırılır. Parametreli sorguda da ?'nin yerine konan değer, sorgu metni gibi yeniden ayrıştırılmaz; olduğu gibi karşılaştırılır. İki mekanizma da aynı ilkeye dayanır: yapıyı belirleyen ayrıştırma bir kez, veri bağlama ayrı ve sonra.

Parametreli sorgunun yetmediği yerler¶

Derinlemesine savunma¶

• En az ayrıcalık: Uygulamanın veritabanı kullanıcısı yalnız gerektiği tablolara, yalnız gerektiği işlemlerle erişsin. Giriş ekranının kullanıcısının DROP TABLE yetkisi olmamalı.
• Hata iletisi: Veritabanı hatasını kullanıcıya olduğu gibi göstermek, sorgunun yapısını ve tablo adlarını sızdırır (ERR01-J). Kullanıcıya genel bir ileti, ayrıntı güvenli günlüğe.
• Girdi doğrulama: Beklenen biçim bilinen alanlarda (kimlik numarası, tarih, e-posta) beyaz liste doğrulaması saldırı yüzeyini daraltır; ama parametreli sorgunun yerine geçmez.

İşlenmiş örnek: Demo 1'in çıktısını satır satır okumak¶

Demo 1'in Python bölümü (sql_injection.py) üç sentetik kullanıcı (alice, bob, yönetici admin) içeren bir SQLite veritabanı kurar ve aynı giriş sorgusunu iki yolla çalıştırır. Kodu okuyup çalıştırdığınızda göreceğiniz çıktıyı adım adım izleyelim; her adımda neden o sonucun çıktığını Bölüm 3–4'teki mekanizmaya bağlıyoruz.

[BAD WAY]
   Generated SQL:
   SELECT id, name, role FROM user WHERE name = 'alice' AND password = 'password123'
   -> 1 row(s) returned. LOGIN SUCCESSFUL:
      id=1 name=alice role=user
[GOOD WAY]
   Generated SQL (template):
   SELECT id, name, role FROM user WHERE name = ? AND password = ?   [values sent separately]
   -> 1 row(s) returned. LOGIN SUCCESSFUL:
      id=1 name=alice role=user

Beklendiği gibi: girdi zararsız olduğunda hatalı kod da doğru kod da aynı sonucu üretir. Bu yüzden hatalı kod geliştirme sırasında fark edilmez — testler dürüst girdiyle yapılır.

[BAD WAY]
   Generated SQL:
   SELECT id, name, role FROM user WHERE name = 'alice' AND password = '' OR '1'='1'
   -> 3 row(s) returned. LOGIN SUCCESSFUL:
      id=1 name=alice role=user
      id=2 name=bob role=user
      id=3 name=admin role=admin
   ^ Logged in without knowing the password: query structure changed.
[GOOD WAY]
   -> No rows. LOGIN REJECTED.
   ^ Input was searched for as a VALUE; no such password exists: rejected.

Bölüm 3'teki adımları burada takip edin: password = ' yazıldıktan sonra saldırganın ilk ' karakteri dize sabitini kapatır; ardından gelen OR '1'='1' metni SQL operatörü olarak okunur. '1'='1' her zaman doğru olduğu için AND bağlacının sağ tarafı her satır için doğrudur; sorgu fiilen WHERE name='alice' OR doğru olur ve bütün tablo döner. İyi yolda ise saldırganın yazdığı bütün dize (tırnak, OR, eşitlikler dahil) veritabanına tek bir metin değeri olarak gider; böyle bir parolaya sahip kimse olmadığı için sonuç boştur.

[BAD WAY]
   Generated SQL:
   SELECT id, name, role FROM user WHERE name = '' OR role='admin' --' AND password = 'doesn't matter'
   -> 1 row(s) returned. LOGIN SUCCESSFUL:
      id=3 name=admin role=admin
   ^ Another user's (admin's) row was leaked.
[GOOD WAY]
   -> No rows. LOGIN REJECTED.
   ^ No such name exists: no leak.

Burada saldırgan hem sorgu yapısını OR ile değiştirdi hem de -- ile sorgunun geri kalanını (parola denetimini) SQL yorumuna çevirip devre dışı bıraktı; parola alanına ne yazıldığının artık hiçbir önemi yok. Parametreli sorguda bu dize (', OR, -- dahil) tek bir metin değeri olarak ad sütunuyla karşılaştırılır; böyle bir kullanıcı adı olmadığı için sonuç boştur.

Demo 1 — SQL enjeksiyonu: dize birleştirme ve parametreli sorgu¶

cd code\week-05\01-sql-injection
.\demo.ps1

cd code/week-05/01-sql-injection
sh demo.sh

5. Komut enjeksiyonu¶

Uygulamalar bazen bir işi dış bir programa yaptırır: bir resmi dönüştürmek, bir arşivi açmak, bir ağ adresini sınamak. Komut tek bir dize olarak bir kabuğa verilirse, dizedeki kabuk karakterleri (;, &&, |, `, $( )) yeni komutlar başlatır:

String user = request.getParameter("name");
Runtime.getRuntime().exec(new String[]{"sh", "-c", "echo Hello " + user});
/* name = "alice; <another command>"  →  the shell runs two commands */

Windows'ta aynı durum cmd /c ile ve & karakteriyle oluşur. Java'nın tek dize alan Runtime.exec(String) biçimi ayrıca dizeyi boşluklardan kendi kurallarıyla böler; tırnaklarla oynayarak argümanları kaydırmak mümkündür (IDS07-J).

Kabuk girdiyi adım adım nasıl ayrıştırır?¶

Bölüm 3'teki genel ilkeyi kabuğa (sh, bash, cmd) uygulayalım. user değişkeninin içeriği "alice; echo LEAKED" olsun; Java bu dizeyi birleştirip kabuğa şu tek metni verir: echo Hello alice; echo LEAKED. Kabuk bunu şöyle işler:

1. Kabuk, aldığı metni komut ayırıcı karakterlere göre (;, &&, ||, satır sonu) önce komutlara böler. Bu, tıpkı SQL ayrıştırıcısının ' karakterinde durum değiştirmesi gibi, kabuğun kendi söz dizimi kuralıdır.
2. ; karakterine kadar olan kısım (echo Hello alice) birinci komut olarak ayrılır.
3. ;'den sonraki kısım (echo LEAKED) ikinci, bağımsız bir komut olarak ayrılır.
4. Kabuk, iki komutu da sırayla çalıştırır — sanki kullanıcı terminale iki ayrı satır yazmış gibi.
5. Uygulamanın kendisi tek bir exec çağrısı yaptığını sanır; ama kabuk açısından ortada iki komut vardır, çünkü kabuk metni kendi kurallarıyla yeniden ayrıştırmıştır.

Kritik nokta yine aynıdır: kabuk hata yapmıyor, ; karakterini tam olarak söz dizimi kuralına göre okuyor. Java'nın "bu bir kullanıcı adıydı" bilgisi, dize kabuğa ulaştığı anda kaybolmuştur.

Doğrusu: kabuksuz, argüman listesiyle¶

private static final Pattern NAME = Pattern.compile("^[A-Za-z0-9_]{1,32}$");

if (!NAME.matcher(user).matches()) {
    throw new IllegalArgumentException("invalid name");       // default: reject
}
Process p = new ProcessBuilder("/usr/bin/printf", "Hello %s\n", user)
        .redirectErrorStream(true)
        .start();

1. Kabuk yok: ProcessBuilder programı doğrudan başlatır; ; ya da & yalnız argümanın içindeki karakterlerdir.
2. Tam yol: 1. haftadaki PATH saldırısına karşı programın tam yolu verilir.
3. İzin listesi: Argüman, çalıştırılmadan önce beklenen biçime göre doğrulanır.
4. En iyisi: Dış programa hiç gerek bırakmamak. Bir resim dönüştürmek için bir kütüphane, bir adresi sınamak için InetAddress.isReachable kullanmak, bütün sorunu ortadan kaldırır.

Aşağıdaki canlandırma, kabuğun tek bir komut dizesini nasıl belirteçlere ayırdığını ve ;/& gibi bir belirtecin neden "ek bir argüman" değil "yeni bir komut başlat" anlamına geldiğini gösterir.

Normal, Zor (; ile Linux tarzı) ve Uç durum (& ile Windows tarzı) örneklerini deneyin.

İşlenmiş örnek: Demo 2'nin çıktısını satır satır okumak¶

Demo 2'nin Python bölümü (command_injection.py) bir "selamlama aracı"nı önce kabuk üzerinden (shell=True), sonra argüman listesiyle (shell=False) çalıştırır. WSL/Linux'ta gerçek çıktı şöyledir:

[BAD WAY]
   Command sent to the shell:
   echo "TOOL OUTPUT: Hello" Alice
   | TOOL OUTPUT: Hello Alice
[GOOD WAY]
   Argument list:
   [python, -c, ...] ... 'Alice'
   | TOOL OUTPUT: Hello Alice

[BAD WAY]
   Command sent to the shell:
   echo "TOOL OUTPUT: Hello" Alice ; echo LEAKED-COMMAND-INJECTION
   | TOOL OUTPUT: Hello Alice
   | LEAKED-COMMAND-INJECTION
   ^ The 'LEAKED...' line = the injected command ran.
[GOOD WAY]
   Allow-list REJECTED it (^[A-Za-z0-9_]+$):
   input = Alice ; echo LEAKED-COMMAND-INJECTION
   -> The program was never run.
   ^ The allow-list saw a space/;/& and rejected it.

Kötü yolda kabuk, yukarıdaki beş adımı izleyerek dizeyi ; üzerinden ikiye böldü ve iki ayrı komut çalıştırdı; ikinci satır (LEAKED-...) enjekte edilen komutun gerçekten çalıştığının kanıtıdır (demo zararsız bir echo kullanır). İyi yolda ProcessBuilder/subprocess hiçbir kabuk çağırmaz; girdi tek bir argümandır ve izin listesi (^[A-Za-z0-9_]+$) boşluk ile ; içeren bu girdiyi çalıştırmadan önce reddeder.

Demo 2 — Komut enjeksiyonu¶

cd code\week-05\02-command-injection
.\demo.ps1

cd code/week-05/02-command-injection
sh demo.sh

6. Yol geçişi (Tarif 3.7)¶

Bir dosya sunucusu yalnız belirli bir klasörün altındaki dosyaları vermelidir. İstenen dosya adı doğrudan bu klasörün yoluna eklenirse, ../ dizileri kökün dışına çıkar:

Path root = Paths.get("/srv/data");
Path file = root.resolve(request);                  // request = "../../etc/passwd"
return Files.readAllBytes(file);                 // a file outside the root is read

Yol normalleştirme adım adım: ../ neden köke geri çıkarır?¶

resolve()/normalize() bir yolu tek bir yığın (stack) algoritmasıyla işler. root = "/srv/data" ve request = "../../etc/passwd" olsun. Dosya sistemi bu isteği aşağıdaki gibi, segment segment işler:

Sonuç: /etc/passwd — kökün (/srv/data) tamamen dışında bir yol. .. karakterleri, ayrıştırıcı için "bir üst klasöre çık" komutudur; SQL'deki ' nasıl "dize sabitini kapat" komutuysa, dosya sisteminde de .. aynı rolü oynar. Bu yüzden ham dizede yalnız ".." arayan bir denetim (request.contains("..")) yeterli değildir: ..%2f (URL kodlanmış), ....// (iç içe yazım) gibi biçimler bu aramayı atlatırken, aynı yığın algoritmasıyla işlendiğinde yine kökün dışına çıkabilir. Doğru sıra bu yüzden önce normalleştir (yığın algoritmasını tamamen çalıştır), sonra sonucu denetlemektir — ara adımları değil, nihai yığın içeriğini kontrol ederiz.

Doğrusu: önce kanonikleştir, sonra kökün içinde mi diye bak¶

Path root = Paths.get("/srv/data").toRealPath();
Path candidate = root.resolve(request).normalize();      // if request is an absolute path, resolve returns it unchanged
if (!candidate.startsWith(root)) throw new SecurityException("outside root");
Path real = candidate.toRealPath();                  // also resolves symbolic links
if (!real.startsWith(root)) throw new SecurityException("outside root");
return Files.readAllBytes(real);

Sıra önemlidir: önce kanonik (tek, kesin) yol elde edilir, sonra denetlenir. Denetimi ham dizeye yapmak (request.contains("..")) yetmez; ..%2f, ....//, Windows'ta ..\ ve sürücü harfli mutlak yollar, Unicode biçimleri ve sembolik bağlantılar denetimi atlatabilir. toRealPath() sembolik bağlantıları da gerçek hedeflerine çözer; İkinci haftadaki TOCTOU (denetim ile kullanım arasındaki zaman) sorunu hâlâ geçerli olduğu için dosya açıldıktan sonra da kök içinde olduğunun doğrulanması en sağlamıdır.

Aşağıdaki canlandırma, istek yolunun bir segment adım adım nasıl çözüldüğünü ve kökteyken bir ..'nin neden kökün dışına çıkma girişimi sayıldığını gösterir.

Normal, Zor (../secret.txt) ve Uç durum örneklerini deneyin.

İşlenmiş örnek: Demo 3'ün çıktısını satır satır okumak¶

Demo 3'ün Python bölümü (path_traversal.py) output/data/ klasörünü kök kabul eder; kök dışında (output/secret.txt) sentetik bir "yönetici notu" bulunur. Gerçek çıktı:

[BAD WAY]
   Resolved path: .../output/data/report.txt
   READ -> Public report (synthetic).
[GOOD WAY]
   Resolved path: .../output/data/report.txt
   READ -> Public report (synthetic).

[BAD WAY]
   Resolved path: .../output/secret.txt
   READ -> SECRET: synthetic admin note (outside the root).
   ^ The secret file outside the root was leaked.
[GOOD WAY]
   REJECTED: escapes outside the root -> .../output/secret.txt
   ^ Canonicalization + root check blocked it.

Kötü yolda ROOT / "../secret.txt" ifadesi, yukarıdaki yığın algoritmasıyla data segmentini pop'lar ve doğrudan output/secret.txt'ye ulaşır — kökün bir üst klasörüne çıkmıştır. İyi yolda aynı normalleştirme yapılır, ama sonuç kök (output/data) ile başlamadığı için istek çalıştırılmadan reddedilir.

Demo 3 — Yol geçişi¶

cd code\week-05\03-path-traversal
.\demo.ps1

cd code/week-05/03-path-traversal
sh demo.sh

7. Güvensiz seri durumdan çıkarma¶

Serileştirme (serialization), bir nesneyi bayt dizisine çevirip saklamak ya da ağdan göndermektir; seri durumdan çıkarma (deserialization) ise tersidir. Java'nın yerleşik ObjectInputStream mekanizması, bayt akışında adı yazan herhangi bir serileştirilebilir sınıfın nesnesini oluşturur ve bu sırada o sınıfın bazı metotlarını (readObject, readResolve gibi) çalıştırır.

Sorun şudur: bayt akışı güvenilmez bir kaynaktan geliyorsa, hangi sınıfların oluşturulacağını saldırgan seçer. Uygulamanın sınıf yolunda (classpath) bulunan kütüphanelerdeki masum görünen sınıflar, oluşturulurken birbirini tetikleyecek biçimde zincirlenebilir. Gerçek olaylarda bu zincirler uzaktan kod çalıştırmaya kadar gitmiştir; 2015'te yaygın bir ortak kütüphanedeki sınıflar üzerinden birçok kurumsal sunucu ürününü etkileyen bir dizi zafiyet bu yüzden ortaya çıktı. Bu nedenle CWE-502 ("güvenilmeyen verinin seri durumdan çıkarılması"), OWASP Top 10'daki "yazılım ve veri bütünlüğü hataları" kategorisinin parçasıdır.

Bayt akışı nasıl bir sınıf adı taşır? Mekanizma adım adım¶

Saldırı zincirinin kendisini yazmıyoruz ama saldırganın elindeki yetkinin nereden geldiğini anlamak savunmayı da anlamlı kılar. ObjectOutputStream'in ürettiği bayt akışının başı sabit bir biçime sahiptir:

1. İlk iki bayt her zaman AC ED — "stream magic" (bu akışın bir Java nesne akışı olduğunu belirten imza).
2. Sonraki iki bayt 00 05 — akış biçiminin sürümü.
3. Ardından bir nesne bloğu gelir; bu blok önce bir sınıf tanımlayıcısı (class descriptor) içerir: sınıfın tam adı (com.example.Setting gibi), uzunluk öneki ile birlikte düz metin olarak akışta durur.
4. ObjectInputStream.readObject() çalıştığında, önce bu ismi okur, sonra Class.forName(name) benzeri bir çağrıyla sınıfı sınıf yolunda (classpath) arayıp yükler — henüz hiçbir tür denetimi yapılmamıştır, çünkü beklenen türün ne olduğunu akışın kendisi söylemektedir.
5. Sınıf yüklendikten sonra JVM bu sınıftan bir nesne ayırır (adi bir kurucu çağrısı olmadan, seri durumdan çıkarmaya özgü bir mekanizmayla) ve akıştaki alan değerlerini bu nesneye yazar; sınıfın tanımladığı readObject/readResolve gibi özel metotlar varsa bunlar da bu sırada çalıştırılır.

Adım 3–4'ün sonucu şudur: hangi sınıfın yükleneceğine akışı gönderen karar verir, uygulama değil. Akış güvenilmez bir kaynaktan geliyorsa, sınıf yolundaki herhangi bir sınıf adı yazılabilir; o sınıfın readObject/readResolve metotları çalışırken yaptığı her şey (dosya açmak, başka bir nesne oluşturmak, bir metot çağırmak) saldırganın kontrolündedir. Bir dizi böyle sınıfın birbirini zincirleme tetiklemesi (gerçek olaylardaki "gadget zinciri"), sonunda keyfi kod çalıştırmaya kadar gidebilir — zincirin nasıl kurulduğunu yazmıyoruz, ama "neden mümkün olduğunu" Adım 3–4 tam olarak açıklar.

Savunma katmanları¶

ObjectInputFilter filter = ObjectInputFilter.Config.createFilter(
        "com.example.Setting;java.base/*;maxdepth=5;maxarray=1000;maxbytes=65536;!*");
try (ObjectInputStream in = new ObjectInputStream(stream)) {
    in.setObjectInputFilter(filter);
    Setting s = (Setting) in.readObject();          // beklenmeyen sınıf → InvalidClassException
}

Desen soldan sağa okunur: com.example.Setting ve java.base modülündeki sınıflara izin ver, sınırları uygula, geri kalan her şeyi reddet (!*). Son öğe varsayılan-reddet ilkesidir; unutulursa filtre bir kara listeye dönüşür.

Aşağıdaki canlandırma, akıştaki bir sınıf adının filtresiz her zaman kabul edildiğini, filtreli sürümde ise önce izin listesi kalıbıyla karşılaştırıldığını gösterir.

Normal, Zor (şüpheli bir sınıf adı) ve Uç durum örneklerini deneyin.

İşlenmiş örnek: Demo 7'nin çıktısını satır satır okumak¶

Demo 7'nin Java kodu (SerializationDemo.java), iki zararsız sınıf tanımlar: beklenen Setting (ad + değer taşır) ve beklenmeyen OtherClass (gerçek bir saldırıda bir "gadget" olurdu; burada yalnızca bir dize taşır). Her ikisi de serileştirilip, önce filtresiz, sonra filtreli çözülür. Gerçek çıktı:

   [expected Setting] ACCEPTED -> Setting(name=timeout, value=30)  (Setting)
   [unexpected OtherClass] ACCEPTED -> OtherClass(payload=unexpected-class)  (OtherClass)
   ^ Without a filter, EVERY class in the stream is built;
     in a real attack this could have been a gadget chain.

   [expected Setting] ACCEPTED -> Setting(name=timeout, value=30)
   [unexpected OtherClass] REJECTED (filter): unexpected class blocked.

Filtre "SerializationDemo$Setting;java.base/*;!*" yalnız Setting sınıfına ve Java'nın kendi çekirdek sınıflarına izin verir. Adım 1'deki mekanizmayı hatırlayın: filtre, sınıf yüklenmeden önce akıştan okunan adı denetler; OtherClass listede olmadığı için readObject çağrısı InvalidClassException ile durur — sınıf hiç örneklenmez, hiçbir metodu çalışmaz.

Demo 7 — Güvenli seri durumdan çıkarma¶

cd code\week-05\07-deserialization
.\demo.ps1

cd code/week-05/07-deserialization
sh demo.sh

8. XML, şablon ve diğer enjeksiyonlar¶

Aynı "veri ile komutun karışması" hatası her yorumlayıcıda karşımıza çıkar. En sık görülen dördü:

XXE mekanizması adım adım (yük yazmadan)¶

XML standardı, bir belgenin başında bir DTD (Document Type Definition) tanımlamasına ve bu DTD içinde özel kısaltmalar (varlık, entity) tanımlanmasına izin verir — tıpkı bir metin editöründeki "ara-değiştir" kısayolu gibi: belge içinde &kisaltma; yazılan her yere, DTD'de tanımlanan gerçek içerik yerleştirilir. Sorun, bu "gerçek içeriğin" dış bir kaynaktan (SYSTEM anahtar sözcüğüyle işaretli bir dosya yolu ya da ağ adresi) gelebilmesidir:

1. Ayrıştırıcı belgeyi okurken önce DTD bloğunu işler; DTD içindeki her <!ENTITY ad SYSTEM "kaynak"> tanımını bir kısaltma tablosuna kaydeder (ad → kaynak).
2. Ayrıştırıcı belgenin gövdesini işlerken &ad; biçiminde bir referansla karşılaşırsa, kısaltma tablosundaki kaynak'ı açar (dosyayı okur ya da ağ isteği yapar) ve içeriğini &ad;'nin yerine yerleştirir.
3. Bu yerleştirme, uygulamanın kendi mantığı devreye girmeden, ayrıştırma sırasında olur; uygulama XML'i "okumayı bitirdiğinde" varlık zaten genişletilmiş, dosya içeriği belge metnine karışmıştır.
4. Eğer uygulama bu genişletilmiş metni herhangi bir biçimde kullanıcıya geri gösteriyorsa (bir hata iletisinde, bir yanıt alanında), dosyanın içeriği sızdırılmış olur; kaynak bir ağ adresiyse bu aynı zamanda sunucunun iç ağa istek göndermesi (SSRF, 3. hafta) anlamına gelir.

Kritik nokta yine aynı: ayrıştırıcı hata yapmıyor, DTD standardını tam olarak uyguluyor. Aşağıdaki sağlamlaştırma (hardening), bu dört adımın birinci adımını (DTD'nin hiç işlenmesini) ve ikinci adımını (dış kaynaklı varlıkların açılmasını) baştan kapatır; böylece 3–4. adımlara hiç sıra gelmez.

DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
f.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);   // DTD yok
f.setFeature("http://xml.org/sax/features/external-general-entities", false);
f.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
f.setXIncludeAware(false);
f.setExpandEntityReferences(false);

Kural her seferinde aynıdır: yorumlayıcının hangi özelliklerinin açık olduğunu bil, ihtiyacın olmayanı kapat, veriyi komut kanalından geçirme. Kitabın Tarif 3.10'daki XSS önerileri (çıktıyı bağlama göre kodlamak, girdiyi beyaz listeyle doğrulamak) bugünkü web çerçevelerinin varsayılan davranışı haline gelmiştir; ama bir şablonda "ham HTML" seçeneğini açmak ya da bir sayfayı dize birleştirerek üretmek aynı hatayı geri getirir.

XSS'te aynı mekanizma: tarayıcı HTML'i nasıl ayrıştırır?¶

XXE'deki "ayrıştırıcı, dış kaynaklı içeriği genişletir" fikrinin tam karşılığı, XSS'te tarayıcının HTML ayrıştırıcısıdır. "<p>" + yorum + "</p>" gibi bir dize birleştirmede, yorum değişkeni bir HTML etiket açma karakteri (<) içeriyorsa, tarayıcı bu karakteri gördüğü anda "metin durumundan" "etiket durumuna" geçer — SQL ayrıştırıcısının ' karakterinde durum değiştirmesiyle birebir aynı mekanizma. Sonuç: kullanıcının yazdığı metnin bir kısmı, sayfanın yapısının (yeni bir etiket, dolayısıyla çalıştırılabilir bir betik etiketi) bir parçası olur ve bu HTML'i görüntüleyen her kullanıcının tarayıcısında çalışır — SQL enjeksiyonundan farkı, kurbanın veritabanı değil, sayfayı açan başka bir kullanıcı olmasıdır. Şablon motorlarının "otomatik kaçışı" tam olarak Bölüm 4'teki parametreli sorguyla aynı işi yapar: kullanıcı verisini HTML söz dizimi olarak değil, salt metin içeriği olarak kodlar (< yerine < yazar), böylece ayrıştırıcı hiçbir zaman "etiket durumuna" geçmez.

9. Yorumlanan diller: Python ve JavaScript'te aynı hatalar¶

İzlence bu haftayı "Java ve yorumlanan diller" diye adlandırır. Python, JavaScript (Node.js), Ruby, PHP gibi dillerde de bellek güvenliği bedavadır; ama bu diller çalışma anında kod üretip çalıştırmayı Java'dan çok daha kolay hale getirir. Aynı hata sınıfları burada farklı adlarla karşımıza çıkar:

eval ve arkadaşları: veriyi kod olarak çalıştırmak¶

Yorumlanan dillerin en tehlikeli özelliği, bir dizeyi kod olarak çalıştırabilmeleridir. Kullanıcıdan gelen bir dizenin eval'e ulaşması, enjeksiyonun en doğrudan biçimidir: yorumlayıcının kendisi komut kanalıdır.

value = eval(input_text)                 # WRONG: input_text could be any Python expression

import ast
value = ast.literal_eval(input_text)     # Better: accepts only LITERALS such as numbers, strings, lists
value = int(input_text)                  # Best: parse the expected type directly, catch the error

Kural basittir: kullanıcı verisi eval, exec, new Function ya da bir betik motoruna asla ulaşmamalı. Bir hesap makinesi ya da kural motoru gerekiyorsa, yalnız izin verilen işlemleri tanıyan küçük bir ayrıştırıcı yazılır.

Seri durumdan çıkarma: pickle ve YAML¶

Python'un pickle modülü, Java serileştirmesiyle aynı sorunu taşır: çözülen veri, hangi nesnelerin nasıl oluşturulacağını belirler; belgelerinde de açıkça "güvenilmeyen veriyi asla pickle ile çözmeyin" yazar. YAML kütüphanelerinin tam yükleyicileri de benzer biçimde nesne oluşturabilir.

import json, yaml

data = json.loads(text)             # data only: dict, list, number, string
config = yaml.safe_load(text)       # only basic YAML types
# pickle.loads(text)                # ONLY on data you produced yourself and verified with an HMAC

Düzenli ifade ile hizmet engelleme (ReDoS)¶

Girdi doğrulamanın en yaygın aracı düzenli ifadelerdir; ama kötü yazılmış bir düzenli ifade kendisi bir saldırı yüzeyi olabilir. Geri izleme (backtracking) yapan motorlarda (Java, Python, JavaScript'in yerleşik motorları) iç içe tekrarlar içeren bir desen, özel olarak hazırlanmış bir girdide üstel sürede çalışır:

Desen:  ^(a+)+$
Girdi:  "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa!"   → motor, eşleşmeyi kanıtlamak için milyonlarca yol dener

Tek bir istek, sunucunun bir işlemcisini saniyelerce ya da dakikalarca meşgul edebilir (CWE-1333). Savunma:

1. İç içe tekrarlardan ((a+)+, (a|a)*, (\w+\s?)*) kaçının; deseni olabildiğince kesin yazın.
2. Girdinin uzunluğunu düzenli ifadeden önce sınırlayın (4. haftadaki "önce uzunluk" ilkesi).
3. Mümkünse doğrusal zamanlı bir motor kullanın (RE2 ve türevleri).
4. Statik analiz araçlarının ReDoS kurallarını açın.

İşlenmiş örnek: geri izleme neden üstel büyür? Elle sayalım¶

Yukarıdaki "milyonlarca yol dener" cümlesini soyut bırakmayalım; küçük bir girdi üzerinde gerçekten kaç yol denendiğini sayalım. Desen ^(a+)+$ iki iç içe tekrardan oluşur: iç (a+) "bir ya da daha çok a" demektir, dış (...)"+" bu grubu "bir ya da daha çok kez" tekrarlar. Motor bir a dizisini, iç grubu kaç parçaya böleceğine dair bütün olasılıkları dener — buna bir sayının birleşimleri (compositions) denir.

Girdi olarak yalnız 4 tane a alalım ("aaaa") ve motorun iç grubu bu 4 a'yı kaç farklı biçimde bölümleyebileceğini elle çıkaralım (her bölüm en az 1 a içermeli, çünkü a+ boş olamaz):

Tam 8 farklı bölümleme var. Genel kural: n tane a'nın kompozisyon sayısı 2^(n-1)'dir (n=4 için 2³=8, tablo bunu doğruluyor). Girdi "aaaa" tek başına eşleşir (desen $ ile biter, tam eşleşme başarılı olur), bu yüzden motor ilk denemede durabilir. Ama girdinin sonuna eşleşmeyi bozan tek bir karakter eklersek ("aaaa!"), $ hiçbir zaman sağlanamaz; motor 8 bölümlemenin hepsini dener, hepsi başarısız olur, sonunda "eşleşme yok" der — ama bu sonuca varmadan önce bütün yolları tüketmiştir.

n büyüdükçe deneme sayısı 2^(n-1) ile üstel büyür:

Saldırganın yapması gereken tek şey, n'i yeterince büyütüp (ör. 40-50 karakter, hiç uzun değil) sonuna eşleşmeyi bozan bir karakter eklemektir; girdi kilobayt mertebesinde bile değildir, ama sunucunun tek bir işlem çekirdeğini dakikalarca kilitleyebilir. Bu, dördüncü haftadaki "küçük girdi, orantısız etki" fikrinin düzenli ifade karşılığıdır.

Prototip kirlenmesi (JavaScript)¶

JavaScript'te nesneler bir prototip zincirinden özellik devralır. Kullanıcıdan gelen bir JSON nesnesini derinlemesine birleştiren (merge) bir fonksiyon, __proto__ gibi özel bir anahtara yazmaya izin verirse, bütün nesnelerin ortak prototipine yeni bir özellik eklenmiş olur; uygulamanın başka bir yerindeki if (user.admin) denetimi beklenmedik biçimde doğru çıkabilir. Savunma: __proto__, constructor ve prototype anahtarlarını reddetmek, prototipsiz nesneler (Object.create(null)) ya da Map kullanmak, gelen JSON'u bir şemayla doğrulamak.

10. Bayt kodu ve tersine derleme¶

C/C++ derleyicisi kaynak kodu doğrudan makine koduna çevirir; bu sırada değişken adları, tipler ve yapının büyük kısmı kaybolur. Java derleyicisi ise kaynak kodu, Java'yı çalıştıran sanal makine olan JVM'nin (Java Virtual Machine) anladığı bayt koduna (.class) çevirir; Android'de bu bayt kodu ayrıca DEX biçimine dönüştürülür. Bayt kodu makine kodundan çok daha yüksek düzeylidir:

Bu yüzden bir Java ya da Android uygulamasını tersine çevirmek için uzmanlık gerekmez. JDK'nin kendi aracı javap, bayt kodunu metin olarak gösterir; jadx, CFR, Fernflower gibi tersine derleyiciler (decompiler) ise okunabilir Java kaynağı üretir. Dokuzuncu haftada, gizlemeye karşı kullanılan bu tür araçları (sembolik yürütme, kalıp tanıma) ve bunlara karşı dayanıklılık ilkesini C/C++ tarafında derinlemesine işleyeceğiz (Hafta 9, §10).

private static final java.lang.String VALID_PIN;
static boolean pinCorrect(java.lang.String);
  Code:
     0: ldc           #9                  // String 4729
     2: aload_0
     3: invokevirtual #11                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
     6: ireturn

Bayt kodu satır satır: JVM bir yığın makinesidir¶

Yukarıdaki dört satırı hiç bayt kodu görmemiş biri için de okunur hale getirelim. JVM bir yığın makinesidir: her komut, küçük bir yığına (stack) değer iter (push) ya da yığından değer çeker (pop):

Bu dört satır, kaynaktaki return VALID_PIN.equals(entered); ifadesinin birebir karşılığıdır — hiçbir bilgi kaybolmamıştır. // String 4729 yorumu, javap'ın sabit havuzundaki 9 numaralı girişi okuyup göstermesidir; tersine derleyiciler (jadx, CFR) bu dört satırı görüp doğrudan return VALID_PIN.equals(entered); kaynak kodunu üretir. C'de strip sonrası eşdeğer makine kodunda ne sabitin değeri ne de equals çağrısının hangi tür üzerinde olduğu bu kadar açık kalırdı (dördüncü haftadaki makine kodu örnekleriyle karşılaştırın).

Kaynak kod olmadan bile üç şey açıkça görünür: sabit (4729), anlamlı adlar (VALID_PIN, pinCorrect) ve mantık ("girdiyi şu sabitle karşılaştır"). Koda gömülü bir parola, API anahtarı ya da sunucu adresi, uygulamayı indiren herkese verilmiş demektir (MSC03-J, CWE-798).

Aşağıdaki canlandırma, tam olarak bu dört bayt kodu komutunun kaynak koda nasıl birebir eşlendiğini, adım adım gösterir — ta ki tüm metot yeniden kurulana kadar.

Normal (PIN denetimi, yanlış tahmin), Zor (doğru PIN) ve Uç durum (lisans denetimi) örneklerini deneyin.

Demo 4 — Bayt kodunda ne görünür?¶

cd code\week-05\04-bytecode-decompile
.\demo.ps1

cd code/week-05/04-bytecode-decompile
sh demo.sh

11. ProGuard ve R8: küçültme, iyileştirme, gizleme¶

ProGuard, Java bayt kodunu işleyen açık kaynak bir araçtır; R8 ise Google'ın Android için geliştirdiği ve Android derleme sisteminde varsayılan olarak gelen, ProGuard kurallarıyla uyumlu halefidir. İkisi de dört iş yapar:

Gizlemenin çıktısı, eski ve yeni adları eşleştiren bir eşleme dosyasıdır (mapping.txt):

com.example.payment.CardManager -> com.example.a:
    android.content.Context context -> a
    boolean setDefaultCard(java.lang.String) -> b

-keep kuralları: neyin adı korunmalı?¶

Gizleyici, bir sınıfın ya da metodun dışarıdan adıyla çağrılıp çağrılmadığını bilemez. Aşağıdaki durumlarda adın korunması gerekir; aksi halde uygulama çalışma anında ClassNotFoundException ya da NoSuchMethodException verir:

• Uygulamanın giriş noktaları (Android'de manifest'te adı geçen etkinlikler ve servisler; masaüstünde main).
• Yansıma (reflection) ile adıyla çağrılan sınıf ve metotlar.
• JNI ile native koddan adıyla çağrılan metotlar ve native metotlar.
• Serileştirilen sınıfların alanları (JSON kütüphaneleri alan adlarını kullanır).
• Bir kütüphanenin dışa açık API'si.

Kural yazmanın altın ilkesi en dar kuralı yazmaktır. -keep class com.example.** { *; } gibi geniş bir kural gizlemeyi fiilen kapatır; bu, sahada en sık görülen "gizleme var ama işe yaramıyor" durumudur.

İşlenmiş örnek: eksik -keep neden uygulamayı çökertir¶

Bir sınıfın adı yansımayla (Class.forName("com.example.Payment")) çağrılıyorsa ama proguard-rules.pro içinde bu sınıf için -keep yoksa, adım adım şu olur:

1. Derleme sırasında ProGuard/R8, com.example.Payment sınıfına hiçbir statik çağrı görmez — çünkü çağrı Class.forName içindeki bir dize olarak yazılıdır; gizleyici dizeleri sınıf grafiğinin parçası saymaz.
2. Gizleyici bu sınıfı "kullanılmıyor" sanıp küçültme aşamasında kaldırır ya da adını a.b.c'ye değiştirir.
3. Uygulama çalışırken Class.forName("com.example.Payment") çağrılır; ama sürümdeki sınıfın adı artık farklıdır (ya da sınıf hiç yoktur).
4. Çalışma anında ClassNotFoundException (sınıf silinmişse) ya da NoSuchMethodException (metot adı değişmişse) fırlatılır — bu, yalnızca sürüm (release) derlemesinde görülür, çünkü hata ayıklama derlemesinde gizleme kapalıdır (Bölüm 13); geliştirici sorunu genelde ancak mağaza testinde fark eder.

java.lang.ClassNotFoundException: com.example.Payment
    at java.lang.Class.forName(Class.java:...)
    at com.example.a.b.start(Unknown Source:1)

Aşağıdaki canlandırma, ProGuard/R8'in bir sınıfın üyelerini tek tek dolaşıp her birini -keep kuralına göre koruduğunu ya da kısa, anlamsız bir adla yeniden adlandırdığını gösterir.

Normal, Zor (hiçbir şey korunmuyor) ve Uç durum (-keep çok geniş — gizleme boşa gidiyor) örneklerini deneyin.

Gelişmiş kurallar: sahadan bir yapılandırma¶

Sertifikasyondan geçmiş bir mobil ödeme kütüphanesinin gizleme yapılandırmasında şu kurallar ve gerekçeleri yer alır (kütüphanenin kendi kurallarının genelleştirilmiş hali):

ProGuard'ın yapmadıkları¶

ProGuard ve R8 adları gizler, dizeleri gizlemez. javap çıktısındaki // String 4729 satırı gizlemeden sonra da aynen durur. Kontrol akışını da ancak iyileştirmenin yan etkisi kadar değiştirir. Dize şifreleme, kontrol akışı gizleme ve kurcalamaya karşı denetimler için ticari araçlar (DexGuard, iXGuard gibi) ya da uygulamanın kendi yöntemleri gerekir (sonraki bölüm).

12. Dize gizleme ve dinamik yöntem çağrısı¶

Demo 4'teki sızıntının iki kaynağı vardı: düz metin sabitler ve doğrudan çağrılar. İki basit yöntem bunları azaltır.

Statik dize gizleme¶

Dördüncü haftada C tarafında sembol ve dize gizlemeyi görmüştük; burada aynı fikri Java bayt kodunda uyguluyoruz. Hassas dize kaynakta düz metin olarak değil, şifrelenmiş ya da karıştırılmış bir bayt dizisi olarak durur ve kullanım anında çözülür. Sabit havuzunda dizenin kendisi yerine anlamsız baytlar görünür.

• Basit bir XOR karıştırması javap ve strings taramasını durdurur; ama çözme fonksiyonu ve anahtarı da uygulamanın içindedir. Bu bir engel, kilit değildir.
• Sahada dizeler derleme öncesinde bir araçla AES ile şifrelenir ve derleme yapılandırmasına şifreli sabitler olarak gömülür; çözme işi native tarafta, ek denetimlerle korunan tek bir fonksiyona bırakılır ve çözülen dize iş bitince bellekten silinir. Böylece Java tarafında ne dizenin kendisi ne de çözme anahtarı bulunur.
• Çözülen dize kullanım anında bellekte açıktır; bu yüzden dize gizleme, çalışma anı korumasıyla (RASP, 6. hafta) birlikte anlam kazanır.

İşlenmiş örnek: XOR gizlemeyi elle çözmek¶

Demo 5'in HiddenConstant.java dosyası, "server-key-9F3A" sentetik dizesini XOR anahtarı 0x5A (ondalık 90) ile karıştırıp bayt dizisi olarak saklar. Kaynaktaki dizinin ilk üç baytını (41, 63, 40) elle çözelim; XOR'un tanımı gereği aynı anahtarla iki kez XOR'lamak orijinal değeri geri verir (x ⊕ k ⊕ k = x) — bu yüzden şifreleme ve çözme aynı işlemdir:

  41 = 0010 1001
  90 = 0101 1010
  ----------------  (bit bit XOR: aynıysa 0, farklıysa 1)
 115 = 0111 0011  =  0x73  =  's'

  63 = 0011 1111
  90 = 0101 1010
  ----------------
 101 = 0110 0101  =  0x65  =  'e'

  40 = 0010 1000
  90 = 0101 1010
  ----------------
 114 = 0111 0010  =  0x72  =  'r'

Kalan 12 bayt aynı işlemle çözülür ve sırasıyla v, e, r, -, k, e, y, -, 9, F, 3, A karakterlerini verir; birleştirince tam olarak kaynaktaki "server-key-9F3A" dizesi ortaya çıkar. javap -c -p bu dizeyi değil, yalnızca 15 anlamsız bayt değeri ve KEY sabitini gösterir; strings taraması da düz metni bulamaz. Ama anahtar (0x5A) ve çözme döngüsü aynı sınıfın içindedir — bu yüzden aşağıdaki uyarı geçerlidir.

Aşağıdaki canlandırma, tam olarak bu XOR döngüsünü bayt bayt oynatır: şifreli bayt dizisinden başlayıp çözülen dizeyi canlı olarak kurar.

Normal (gerçek Demo 5 sabiti), Zor ve Uç durum (anahtar 0x00 — hiçbir şey gizlenmiyor!) örneklerini deneyin.

Dinamik yöntem çağrısı (yansıma)¶

Bir metodu doğrudan çağırmak (object.hiddenOperation()), bayt kodunda o metoda giden açık bir bağlantı (invokevirtual) bırakır; tersine derleyici "bu fonksiyon şuradan çağrılıyor" grafiğini kolayca çıkarır. Yansıma ile çağrıda metot adı çalışma anında üretilir (ve bu ad da gizlenebilir):

result = Account.hiddenOperation(input);                                   // bayt kodunda açık bağlantı

Method m = Account.class.getDeclaredMethod(resolveName(NAME_BYTES), String.class);
m.setAccessible(true);
result = (String) m.invoke(null, input);                            // statik çağrı grafiği kırılır

Sınırları dürüstçe söyleyelim: metot hâlâ sınıfta tanımlıdır ve javap -p onu listeler; yansıma yalnız çağrı bağlantısını gizler. Asıl güç, ProGuard'ın metodu yeniden adlandırmasıyla birleştiğinde ortaya çıkar (bu durumda yansımayla çağrılan metot için -keep kuralı gerekir; kural, adı çalışma anında üretilen yeni adla eşleşecek biçimde yazılır). Yansıma ayrıca yavaştır ve derleme anındaki tip denetimini kaybettirir; yalnız gerçekten hassas birkaç çağrıda kullanılır.

Demo 5 — Dize gizleme, yansıma ve ProGuard¶

cd code\week-05\05-obfuscation
.\demo.ps1

cd code/week-05/05-obfuscation
sh demo.sh

13. Android'de R8, gizlemenin etkisini ölçmek ve Java için statik analiz¶

Android derleme hattında R8¶

Android uygulamalarında R8, Gradle yapılandırmasındaki birkaç satırla açılır. Sürüm derlemesinde açık olması, mobil güvenlik standartlarının (OWASP MASVS-RESILIENCE) temel beklentisidir:

android {
    buildTypes {
        release {
            minifyEnabled true          // R8: küçültme + iyileştirme + gizleme
            shrinkResources true        // kullanılmayan kaynakları (resim, düzen) da kaldır
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                          'proguard-rules.pro'
        }
    }
}

proguard-android-optimize.txt, Android için makul varsayılanları içerir; uygulamaya özgü -keep kuralları proguard-rules.pro dosyasına yazılır. JNI ile native koddan çağrılan metotlar ve native metotlar için tipik kural:

-keepclasseswithmembernames class * {
    native <methods>;
}

Çökme raporlarını okumak: retrace¶

Gizlenmiş bir uygulamanın çökme raporu a.b.c(Unknown Source) gibi satırlar içerir. Eşleme dosyası, bu raporu geri çevirmek için kullanılır (retrace aracı ya da çökme raporlama hizmetlerine eşleme dosyasının güvenli biçimde yüklenmesi). Bu yüzden eşleme dosyası silinmez; ama yukarıda söylediğimiz gibi uygulamayla birlikte de dağıtılmaz. -keepattributes SourceFile,LineNumberTable eklemek raporları okunaklı yapar ama kaynak dosya adlarını ve satır numaralarını pakete koyar; bu da bir ödünleşimdir ve kayda geçirilir.

Gizlemenin etkisini ölçmek¶

"Gizleme açık" demek yetmez; gerçekten ne değiştiğini göstermek gerekir. Basit ve tekrarlanabilir ölçütler:

Bu tabloyu gizleme öncesi ve sonrası için doldurup güvenlik kılavuzuna koymak, "gizleme yapıldı" iddiasını kanıta dönüştürür.

İşlenmiş örnek: ölçümü Demo 5 üzerinde adım adım yapmak¶

Bu tablonun ilk iki satırını Demo 5'in ürettiği jar dosyaları üzerinde gerçekten çalıştıralım (demo prepare betiğiyle ProGuard'ı indirdiyseniz):

cd code/week-05/05-obfuscation/output
javap -p -classpath sample.jar DirectCall | grep -c "hiddenOperation"
# Output: 1 (the source method name appears verbatim)

mkdir -p extracted && (cd extracted && jar -xf ../sample-obfuscated.jar)
javap -p -classpath extracted DirectCall | grep -c "hiddenOperation"
# Expected: 0 (the unused private member was removed by shrinking)

ls -la sample.jar sample-obfuscated.jar
# Shrinking reduces the size depending on the class count; obfuscation alone barely changes the size

Bu üç komut, "gizleme çalıştı" iddiasını ölçülebilir bir sayıya dönüştürür: birinci komutun çıktısı sıfırdan büyükse (anlamlı ad hâlâ bulunuyorsa), ya -keep kuralı fazla geniş yazılmıştır ya da gizleme aşaması hiç çalışmamıştır — ikisi de Bölüm 11'deki "sahada en sık görülen hata" ile aynı belirtidir.

Java için statik analiz¶

Dördüncü haftada C/C++ için gördüğümüz statik analiz katmanlarının Java karşılıkları:

mvn com.github.spotbugs:spotbugs-maven-plugin:check
# pom.xml'de eklenti yapılandırmasına findsecbugs-plugin eklenir

Bu araçlar, 4. haftadaki güvenli derleme hattına (CI) aynı biçimde eklenir: yeni bir yüksek önem dereceli bulgu, birleştirmeyi durdurur.

14. Bağımlılık güvenliği ve yazılım malzeme listesi (SBOM)¶

Modern bir uygulamanın kodunun büyük kısmı, onu yazan ekibe ait değildir. Tipik bir Java ya da JavaScript uygulamasında doğrudan eklenen birkaç düzine kütüphane, onların bağımlılıklarıyla birlikte yüzlerce bileşene ulaşır. Bu bileşenlerden birindeki bir zafiyet, uygulamanın zafiyetidir.

SBOM nedir?¶

Yazılım malzeme listesi (Software Bill of Materials, SBOM), bir yazılımın içindeki bütün bileşenlerin makine tarafından okunabilir listesidir: gıda paketinin üzerindeki içindekiler listesi gibi. Her bileşen için en az şunlar yazılır:

İki yaygın standart vardır: Linux Vakfı'nın SPDX'i (Software Package Data Exchange, 2011'de yayımlandı, önce lisans uyumluluğu için; sonradan ISO/IEC 5962 standardı oldu) ve OWASP'ın CycloneDX'i (2017'de yayımlandı, doğrudan güvenlik/SBOM kullanım örneği düşünülerek tasarlandı). ABD Başkanlık Kararnamesi EO 14028 ("Improving the Nation's Cybersecurity", Mayıs 2021) federal tedarikçilerden SBOM istemeyi zorunlu kılan ilk büyük düzenlemelerden biridir; Avrupa Birliği'nin Siber Dayanıklılık Yasası (Cyber Resilience Act) benzer bir gerekliliği AB'ye getirir.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "example-json",
    "version": "1.2.0",
    "purl": "pkg:maven/com.example/example-json@1.2.0",
    "hashes": [{ "alg": "SHA-256", "content": "9f86d081884c7d65..." }]
  }]
}

SBOM'dan zafiyet listesine¶

SBOM tek başına bir envanterdir; değerini yazılım bileşen analizi (SCA) araçlarıyla birleşince kazanır. Bu araçlar SBOM'daki her bileşeni zafiyet veritabanlarıyla (NVD, GitHub Advisory Database, OSV) eşleştirir:

Bir eşleşme her zaman "etkileniyoruz" demek değildir: zafiyetli fonksiyon hiç çağrılmıyor olabilir. Bu bilgiyi makine tarafından okunabilir biçimde yayımlamak için VEX (Vulnerability Exploitability eXchange) belgeleri kullanılır: "bu bileşende CVE-X var, ama ürünümüz etkilenmiyor, çünkü …".

Bağımlılık hijyeni: kontrol listesi¶

• Sürümleri sabitle: kilit dosyası (package-lock.json, gradle.lockfile, poetry.lock) depoda olsun; "en son sürüm" gibi kayan sürümler kullanılmasın.
• Özetleri doğrula: Maven/Gradle bağımlılık doğrulama, pip --require-hashes; indirilen dosya beklenen dosya mı?
• Kullanılmayanı kaldır: sınıf yolundaki her kütüphane bir saldırı yüzeyidir (seri durumdan çıkarma zincirleri kullanılmayan kütüphanelerden de kurulabilir).
• Sürekli izle: SBOM'u her sürümde üret, izleme platformuna gönder; yeni bir CVE yayımlandığında hangi ürünlerin etkilendiğini dakikalar içinde bil.
• Kaynağı denetle: ad benzetme (typosquatting: reqeusts gibi) ve bağımlılık karışıklığı (iç paket adının herkese açık depoda sahte bir paketle ele geçirilmesi) saldırılarına karşı paket kaynağını sabitle.
• Derleme bütünlüğü: 2. haftadaki tedarik zinciri olayları ve SLSA çerçevesi: derlemenin kendisi de kanıtlanabilir olmalı.

Aşağıdaki canlandırma, bir bağımlılık ağacındaki her bileşenin adı ve tam sürümüyle bilinen zafiyetler listesine karşı nasıl tek tek denetlendiğini gösterir — Demo 6'nın kullandığı aynı sentetik listeyle.

Normal (dördü de güvenli), Zor (Demo 6'nın gerçek SBOM'u, iki eşleşme) ve Uç durum (düzeltilmiş sürüm artık işaretlenmiyor) örneklerini deneyin.

İşlenmiş örnek: Demo 6'nın çıktısını satır satır okumak¶

Demo 6 (sbom.py), dört sentetik kütüphaneden küçük jar dosyaları üretir, her biri için CycloneDX bileşeni yazar ve küçük bir "bilinen zafiyetli sürümler" sözlüğüyle eşleştirir. Gerçek çıktı (bileşen adları ve sürümleri kaynak koddaki sabit listeden):

name                   version  SHA-256 (first 16)
crypto-helper          3.0.4    <computed from the jar bytes>...
json-tool              2.5.1    <computed from the jar bytes>...
log-core               2.14.0   <computed from the jar bytes>...
record-library         1.2.0    <computed from the jar bytes>...

pkg:maven/example.group/crypto-helper@3.0.4
pkg:maven/example.group/json-tool@2.5.1
pkg:maven/example.group/log-core@2.14.0
pkg:maven/example.group/record-library@1.2.0

[WARNING] json-tool 2.5.1  (CEN429-2026-0002)
          Unsafe deserialization (synthetic example).
          Fix: upgrade to >= 2.6.0.
[WARNING] log-core 2.14.0  (CEN429-2026-0001)
          Remote code execution via a formatted message (synthetic example).
          Fix: upgrade to >= 2.17.1.

SHA-256 değerleri her çalıştırmada farklı çıkar (üretilen jar'ın ZIP meta verisi zaman damgası içerir); bu kasıtlıdır ve iyi bir tedarik zinciri dersidir — özet, dosyanın tam olarak hangi bayt dizisi olduğunu doğrular, yalnız "ad ve sürüm aynı" demek yeterli değildir. record-library ve crypto-helper, sentetik zafiyet listesinde bulunmadığı için uyarı almaz — bir SBOM'un boş kalan kısmı da bilgidir: "bu bileşenler bilinen listede yok" demektir, "güvenli" demek değildir.

Demo 6 — SBOM üretmek ve zafiyetle eşleştirmek¶

cd code\week-05\06-sbom
.\demo.ps1

cd code/week-05/06-sbom
sh demo.sh

15. Dönem projesi: bu hafta¶

Projeniz C/C++ olsa bile bu haftanın iki konusu doğrudan projenize uygulanır:

• SBOM: Projenizin bütün bağımlılıklarını (kütüphaneler, derleme araçları, CMake ile indirilen bileşenler) CycloneDX biçiminde listeleyin. vcpkg ya da Conan kullanıyorsanız SBOM üretim desteklerini deneyin; yoksa elle yazın. Her bileşeni OSV veritabanında arayın ve sonucu kılavuza ekleyin.
• Girdi doğrulama tablosu: Projenizin dışarıdan veri aldığı her noktayı (dosya, komut satırı, ağ, yapılandırma) listeleyin; her biri için beklenen biçimi, uzunluk sınırını ve doğrulamanın yapıldığı fonksiyonu yazın.
• Projeniz bir dosya yolu, bir SQL sorgusu ya da bir dış program çağrısı içeriyorsa, bu haftanın kalıplarıyla (kanonikleştirme + kök, parametreli sorgu, argüman listesi) yeniden gözden geçirin.
• Projenizde bir betik ya da Java bileşeni varsa, gizleme gereksinimini ve -keep kurallarını S9 bölümüne ekleyin.

16. Kendi başına çalış¶

17. Kendini sınama¶

18. Kaynaklar ve ileri okuma¶

Ders kitabı — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Tarif 3.1 (temel girdi doğrulama), 3.7 (dosya adları ve yolları doğrulama), 3.10 (siteler arası betiği önleme), 3.11 (SQL enjeksiyonunu önleme)
• Tarif 1.7–1.8 (dış programları güvenli çalıştırma)
• Tarif 12.9 (fonksiyon işaretçileri ve dolaylı çağrı — kavram), 12.11 (dizeleri gizleme)

Açık standartlar ve kaynaklar

• SEI CERT Oracle Coding Standard for Java (IDS, FIO, SER, MSC, ERR kuralları).
• OWASP: Top 10, SQL Injection Prevention Cheat Sheet, OS Command Injection Defense Cheat Sheet, XML External Entity Prevention Cheat Sheet, Deserialization Cheat Sheet; MASVS-CODE ve MASVS-RESILIENCE.
• Oracle: JEP 290 (seri durumdan çıkarma filtreleri), JEP 415 (bağlama özgü filtreler); Java Secure Coding Guidelines.
• ProGuard kılavuzu (Guardsquare) ve Android geliştirici belgeleri: "Shrink, obfuscate, and optimize your app" (R8).
• CycloneDX 1.5 ve SPDX 2.3 (ISO/IEC 5962) belirtimleri; package-url (purl) belirtimi; CISA SBOM ve VEX belgeleri; SLSA çerçevesi.
• MITRE CWE: CWE-89, CWE-78, CWE-88 (argüman enjeksiyonu), CWE-22, CWE-502, CWE-611, CWE-79, CWE-798, CWE-1104 (bakımı yapılmayan üçüncü taraf bileşen kullanımı).