Özet

Bu oda, modern web uygulaması güvenliğinin temel taşlarından biri olan OWASP Top 10 listesinin 2025 yılındaki güncellemelerini, özellikle "Güvensiz Veri İşleme" (Insecure Data Handling) teması etrafındaki kritik zafiyetleri analiz etmektedir. Oda, kriptografik hatalar, enjeksiyon yöntemleri ve veri bütünlüğü yetersizlikleri üzerine odaklanarak teknik detaylar ve çözüm önerileri sunmaktadır.

1. Introduction

OWASP Top 10 2025 listesi, uygulama güvenliği tehdit ortamındaki evrimi yansıtmaktadır. 2021'den 2025'e geçişte, kriptografik hatalar ve enjeksiyon gibi temel zafiyetlerin sıralamasında düşüş gözlemlense de, bu unsurlar halen sistemler için yüksek risk teşkil etmektedir. Kriptografik hatalar (A04) 2. sıradan 4. sıraya, Enjeksiyon (A05) ise 3. sıradan 5. sıraya gerilemiştir. Yazılım ve Veri Bütünlüğü Hataları (A08) ise yerini korumuştur.

Bu odada incelenen temel bulgular şunlardır:

  • Kendi Kriptografini Oluşturma: Standart dışı, zayıf anahtarlı veya "ev yapımı" algoritmalar kullanmak sistemleri savunmasız bırakmaktadır.
  • SSTI ve Dinamik İçerik Tehlikesi: Sunucu Tarafı Şablon Enjeksiyonu (SSTI), saldırganların sunucu üzerinde kod yürütmesine olanak tanıyan kritik bir enjeksiyon türüdür.
  • Güvensiz Serisizleştirme (Insecure Deserialization): Python'ın pickle modülü gibi formatların kontrolsüz kullanımı, veri bütünlüğünün bozulmasına ve tam sistem ele geçirilmesine yol açabilmektedir.

OWASP Top 10 2025 Genel Görünümü

2025 listesi, uygulama davranışları ve kullanıcı girdileriyle ilgili kritik alanları kapsamaktadır. Aşağıdaki tablo, 2021 ve 2025 arasındaki temel sıralama değişimlerini ve listenin güncel halini özetlemektedir:

None

A01 Erişimin Kırılması (Broken Access Control)

A02 Güvenlik Yapılandırma Hataları (Security Misconfiguration)

A03 Yazılım ve Tedarik Zinciri Hataları (Software Supply Chain Failures)

A04 Kriptografik Hatalar (Cryptographic Failures)

A05 Enjeksiyon (Injection)

A06 Güvensiz Tasarım (Insecure Design)

A07 Kimlik Doğrulama Hataları (Authentication Failures)

A08 Yazılım veya Veri Bütünlüğü Hataları (Software or Data Integrity Failures)

A09 Günlüğe Kaydetme ve Uyarı Hataları (Logging/Alerting Failures)

A10 İstisnai Durumların Yanlış Yönetilmesi (Mishandling of Exceptional Conditions)

2. A04: Kriptografik Hatalar (Cryptographic Failures)

Kriptografik hatalar, hassas verilerin şifreleme eksikliği, hatalı uygulama veya zayıf algoritmalar nedeniyle korunamaması durumunda ortaya çıkar.

Temel Riskler ve Sebepler

  • Zayıf Algoritmalar: MD5, SHA1 veya ECB modu gibi artık güvenli kabul edilmeyen yapıların kullanımı.
  • Ev Yapımı Kriptografi: Bir uygulama servisinin, yerleşik ve doğrulanmış standartlar yerine kendi şifreleme algoritmasını tasarlamaya çalışması en büyük risklerden biridir.
  • Kısa ve Öngörülebilir Anahtarlar: Kısa anahtar kullanımı, saldırganların kaba kuvvet (brute force) yöntemleriyle veriyi deşifre etmesine olanak tanır.

Vaka Analizi: XOR Şifreleme Zafiyeti

Base64 formatında kodlanmış notların 4 karakterli, hem harf hem rakam içeren zayıf bir XOR anahtarı ile şifrelendiği görülmüştür. XOR işleminin tersine çevrilebilir olması ve anahtarın kısalığı, saldırganın deneme yanılma yoluyla verilere erişmesini sağlar. Yapılan testlerde, anahtarın son karakterinin rakam (örneğin Ƈ') olduğu ve doğru anahtar girildiğinde tüm notların çözüldüğü doğrulanmıştır.

Önleme Stratejileri

  • Modern Algoritmalar: Hash işlemleri için bcrypt, scrypt veya argon2 gibi yavaş ve güvenli algoritmalar tercih edilmelidir.
  • Standartlara Bağlılık: Kendi algoritmanızı oluşturmak yerine endüstri standartlarına güvenilmelidir.
  • Anahtar Yönetimi: Kimlik bilgileri ve şifreleme anahtarları kaynak kodda veya yapılandırma dosyalarında korunmasız bırakılmamalıdır.

Decrypt the encrypted notes. One of them will contain a flag value. What is it? Answer: THM{WEAK_CRYPTO_FLAG}

4 karakterli bir anahtarın son karakterini bulmamızı istiyor. Ayrıca anahtarın harf ve rakamlardan oluştuğunu belirtiyor. 0 (sıfır) dan itibaren sırayla denediğimizde anahtarın son karakterinin 1 olduğunu buluyoruz.

None

3. A05: Enjeksiyon (Injection)

Enjeksiyon zafiyetleri, bir saldırganın sisteme kötü niyetli kod eklemesine izin veren sistem kusurlarıdır. 2025 listesinde 5. sıraya gerilese de, SQL enjeksiyonundan komut enjeksiyonuna kadar geniş bir yelpazeyi kapsar.

Sunucu Tarafı Şablon Enjeksiyonu (SSTI-Server Side Template Injection)

SSTI, kullanıcı girdilerinin bir şablon motoruna (örneğin Python'da Jinja) doğrudan aktarılmasıyla oluşur.

  • Tespit: Girdi alanına {{7*7}} gibi bir matematiksel ifade yazıldığında sunucu 49 sonucunu döndürüyorsa, bu bir SSTI zafiyetine işaret eder.
  • İstismar: Saldırganlar, Python nesnelerine (config, request vb.) erişerek sistem üzerinde komut çalıştırabilir. Örneğin, os.popen veya lipsum gibi nesneler kullanılarak sunucudaki dosyalar (dockerfile, flag.txt) listelenebilir ve okunabilir.

Önleme Stratejileri

  • Veri Doğrulama: Kullanıcı girdileri hiçbir zaman doğrudan güvenilir kabul edilmemelidir.
  • Hazırlanmış İfadeler (Prepared Statements): SQL sorguları için PDO gibi yapılar kullanılmalıdır.
  • Güvenli Şablon Kullanımı: Şablon motorları kısıtlanmalı ve kullanıcı girdileri uygun şekilde sanitize edilmelidir.

Perform an SSTI attack on the practical. You need to read the contents of flag.txt that is located within the same directory as the web application. Answer: THM{SSTI_FLAG_OBTAINED}

Web uygulamasının en altında aşamaları anlatmış aslında.

None

Prove code execution

{{ 7 * 7 }}

→ Eğer 49 dönüyorsa, yazdığın ifade sunucuda çalıştırılıyor demektir. SSTI teyit.

Enumerate context

{{ config.items() }}
veya
{{ request.__dict__ }}

Bunlar template içinde erişebildiğin objeleri gösterir. Yani "arka tarafta hangi Python nesnelerine dokunabiliyorum?" sorusunun cevabı.

Read the flag (olayın kalbi)

Flask, template içine bazı global nesneleri koyar. Bu nesneler üzerinden Python'un builtins alanına yürüyebilirsin. Orada da open() vardır.

Yani:

request → application → __globals__ → __builtins__ → open()

zinciri.

Ne işe yarıyor?

open("flag.txt").read()

çalıştırabilme. Ve dosyanın içeriği ekrana basılır.

Why it works?

Çünkü:

request.application → seni Flask'ın iç yapısına taşır. Oradan Python'un temel fonksiyonlarına ulaşılır.

Bir nevi sandbox'ı dolaşıp arka kapıdan mutfağa girmek.

None

4. A08: Yazılım ve Veri Bütünlüğü Hataları (Software and Data Integrity Failure)

Bu kategori, yazılım kodu ve veri bileşenlerinin bütünlüğünün doğrulanamadığı durumlara odaklanır. 2025'te ismi netleştirilmiş ve güven sınırlarının korunmasına vurgu yapılmıştır.

Kritik Zafiyet Alanları

  • Güvensiz Güncellemeler: Kaynağı doğrulanmamış kod güncellemelerinin veya GitHub gibi platformlardan indirilen kontrolsüz betiklerin çalıştırılması.
  • Insecure Deserialization (Güvensiz Serisizleştirme): Uygulamanın, serisizleştirilmiş veriyi bütünlük kontrolü yapmadan kabul etmesi durumudur.

Vaka Analizi: Python Pickle İstismarı

Python'ın pickle modülü, verileri serisizleştirmek için kullanılır ancak bu süreçte bütünlük kontrolü yapılmazsa keyfi kod yürütülmesine (RCE) yol açabilir.

  • Saldırı Yöntemi: Saldırgan, pickle formatında kötü niyetli bir payload hazırlar. Bu payload, base64 ve subprocess modüllerini kullanarak sistemde ls veya cat flag.txt gibi komutlar çalıştırır.
  • Sonuç: Veri işlendiği anda sunucu tarafında saldırganın komutu yürütülür ve hassas bilgiler ele geçirilir.

Önleme Stratejileri

  • Güven Sınırları Oluşturma: Uygulamalar, dışarıdan gelen kod veya verilerin meşru olduğunu asla varsaymamalıdır.
  • İmza Doğrulama: Yazılım güncellemeleri ve veri paketleri için dijital imzalar ve bütünlük kontrolleri zorunlu tutulmalıdır.
  • CI/CD Güvenliği: Yazılım tedarik zinciri süreçlerinde sıkı güvenlik kontrolleri uygulanmalıdır.

Use Python to pickle a malicious, serialised payload that reads the contents of flag.txt and submits it to the application.

What are the contents of flag.txt? Answer: THM{INSECURE_DESERIALIZATION}

None

Pickle neden tehlikeli?

Normalde veri saklamak için kullanılır. Ama objeyi geri açarken Python şunu yapabilir:

Bu objeyi yeniden oluşturmak için hangi fonksiyonu çağırmalıyım?

İşte burada saldırgan devreye girer.

Der ki:

Benim objemi açarken şu fonksiyonu çalıştır.

Ve kod yürür.

reduce nedir?

pickle objeyi geri kurarken __reduce__ metoduna bakar.

Bu metod şunu döndürür:

(çalıştırılacak_fonksiyon, argümanlar)

Yani direkt execution noktasıdır.

Çözümde ne yapılıyor?

Bu obje deserialize edilirken open("flag.txt").read() çalıştır.

Adım adım

1. Zararlı class yazılıyor

class Malicious:

2. __reduce__ override ediliyor

return (eval, ("open('flag.txt').read()",))

Bu demek oluyor ki pickle açarken:

eval("open('flag.txt').read()")

çalıştır.

3. Payload pickle'a dönüştürülüyor

pickle.dumps()

Artık binary exploit var.

4. Base64 neden?

Çünkü web formları binary kabul etmez. Metne çeviriyoruz.

5. Sunucu ne yapıyor?

gelen_veri → base64 decode → pickle.loads()

Kod çalışıyor → flag okunuyor → çıktı dönüyor.

Kritik öğrenme noktası

Bu aslında şudur:

Kullanıcıdan gelen pickle verisini ASLA deserialize etme.

Gerçek hayatta bu, full RCE demektir.

Mülakat cümlesi

Şöyle söylersen seviye atlarsın:

Pickle deserialization is dangerous because attackers can control the __reduce__ method to achieve arbitrary code execution during object reconstruction.

Pickle ile seri durumdan çıkarma işlemi tehlikelidir çünkü saldırganlar, nesne yeniden oluşturma sırasında rastgele kod yürütme elde etmek için __reduce__ yöntemini kontrol edebilirler.

Web uygulamasında verilen payload oluşturmak için Python kodunu bir dosyaya kaydediyoruz.

None

.py uzantılı kaydetdiğimiz dosyayı çalıştırıyoruz. Base64 ile encode edilmiş bir metin veriyor.

None

Base64 metni web uygulamasında Deserialize ederek flag elde ediliyor.

None