Tryhackme OWASP Top 10 2025: IAAA Başarısızlıkları

Siber güvenlik dünyasının en prestijli listelerinden biri olan OWASP Top 10, 2025 güncellemesiyle modern uygulama güvenliğine ışık tutmaya devam ediyor. Bu yazımızda, özellikle TryHackMe üzerindeki “OWASP Top 10 2025” odasından yola çıkarak; Kimlik, Kimlik Doğrulama, Yetkilendirme ve Hesap Verilebilirlik (IAAA) süreçlerindeki kritik hataları ele alacağız.

Bu rehber, siber güvenliğe yeni başlayanlar için karmaşık görünen kavramları basitleştirirken, pratik laboratuvar çözümleriyle teoriyi pratiğe dökmeyi hedefliyor.

IAAA Nedir? Güvenliğin Dört Temel Taşı

Uygulamalarda kullanıcıların ve gerçekleştirdikleri eylemlerin nasıl doğrulandığını anlamanın en basit yolu IAAA modelidir. Bu model hiyerarşik bir yapıdadır; yani bir önceki adım doğru çalışmıyorsa, bir sonraki adımı güvenli bir şekilde gerçekleştirmek mümkün değildir.

Identity (Kimlik – Tanımlama): Bir kişiyi veya servisi temsil eden benzersiz hesap (Örn: Kullanıcı adı, e-posta).
Authentication (Kimlik Doğrulama): Beyan edilen kimliğin ispatlanması (Örn: Şifreler, OTP kodları, passkeyler).
Authorisation (Yetkilendirme): Doğrulanmış kimliğin hangi kaynaklara erişebileceğinin belirlenmesi.
Accountability (Hesap Verilebilirlik): Kimin, neyi, ne zaman ve nereden yaptığının kayıt altına alınması (Logging).

OWASP Top 10 2025 listesindeki birçok kategori, aslında bu IAAA döngüsündeki başarısızlıklardan kaynaklanır. Bu zayıflıklar, saldırganların diğer kullanıcıların verilerine erişmesine veya yetkisiz ayrıcalıklar (Privilege Escalation) kazanmasına neden olabilir.

A01: Broken Access Control (Kırık Erişim Kontrolü)

Broken Access Control, sunucunun her istekte “kimin neye erişebileceğini” düzgün bir şekilde denetleyemediği durumlarda ortaya çıkar. Bu kategori, 2025 listesinin en kritik başlıklarından biri olmaya devam ediyor.

IDOR (Insecure Direct Object Reference) Nedir?

Erişim kontrolü hatalarının en yaygın örneklerinden biri IDOR‘dur. Eğer URL üzerindeki bir parametreyi değiştirerek (Örn: ?id=7 yerine ?id=6 yazarak) başka bir kullanıcının özel verilerini görebiliyor veya düzenleyebiliyorsanız, sistemde erişim kontrolü kırılmış demektir.

Bu durum pratikte iki şekilde karşımıza çıkar:

Horizontal Privilege Escalation (Yatay Yetki Yükseltme): Sizinle aynı yetki seviyesindeki başka bir kullanıcının verilerine erişmek.
Vertical Privilege Escalation (Dikey Yetki Yükseltme): Sadece adminlerin yapabileceği işlemleri (Kullanıcı silme vb.) gerçekleştirmek.

Uygulama Zamanı: TryHackMe Laboratuvarı

TryHackMe üzerindeki senaryoda, URL’deki accountID değerini manipüle ederek uygulamayı test edebilirsiniz. Uygulamanın istemci tarafına (client-side) fazla güvenip güvenmediğini anlamak için farklı ID değerlerini deneyin. Bakalım hangi kullanıcının hesabında 1 milyon dolardan fazla bakiye olduğunu bulabilecek misiniz?

İD değerlerinde oynama yaparak hesaplar arası geçiş yaptık ve IDOR zaafiyetini anladık.

A07: Authentication Failures (Kimlik Doğrulama Hataları)

Authentication Failures, bir uygulamanın kullanıcı kimliğini güvenilir bir şekilde doğrulayamadığı veya bir kimliği kullanıcıyla doğru şekilde eşleştiremediği durumlarda meydana gelir. Bu zafiyet, saldırganların başka bir kullanıcının hesabına giriş yapmasına veya bir oturumu yanlış hesapla ilişkilendirmesine olanak tanır.

Bu kategoride en sık karşılaşılan güvenlik açıkları şunlardır:

Kullanıcı Adı Numaralandırma (Username Enumeration): Saldırganın sistemde kayıtlı olan geçerli kullanıcı adlarını tespit edebilmesi.
Zayıf ve Tahmin Edilebilir Şifreler: Hesap kilitleme (lockout) veya hız sınırlaması (rate limit) gibi önlemlerin olmaması nedeniyle kaba kuvvet (brute-force) saldırılarına açık olunması.
Giriş/Kayıt Akışındaki Mantık Hataları: Yazılımın kayıt olma veya giriş yapma süreçlerindeki tasarım kusurları.
Güvensiz Oturum ve Çerez Yönetimi: Session ID veya çerezlerin (cookies) ele geçirilmeye veya taklit edilmeye müsait olması.

Uygulama: Admin Hesabını Ele Geçirme (Mantık Hatası İstismarı)

TryHackMe laboratuvarındaki senaryoda, uygulamanın kimlik doğrulama akışındaki bir mantık hatasını (logic flaw) istismar edeceğiz. Hedefimiz admin kullanıcısının hesabına sızmak.

Uygulamanın büyük/küçük harf duyarlılığındaki bir hatayı kullanarak sistemi kandırmayı deneyeceğiz:

Kayıt sayfasında admin ismiyle hesap açmaya çalıştığımızda sistem muhtemelen hata verecektir.
Ancak aDmiN gibi farklı varyasyonlarla kayıt olmayı deneyerek sistemin bu ismi nasıl işlediğini (normalize edip etmediğini) test edebiliriz.
Eğer uygulama kayıt sırasında aDmiN ismini kabul edip, veritabanına yazarken veya oturum açarken bunu admin olarak yorumlarsa, yetkisiz erişim sağlamış oluruz.

Hemen statik siteyi başlatın, bu mantık hatasını kullanarak kayıt olun ve bir sonraki flag’e ulaşmak için admin hesabına giriş yapın!

Bu zaafiyet işlem sayesinde sistemi kandırıp admin olarak sisteme giriş yaptık.

A09: Logging & Alerting Failures (Günlükleme ve Uyarı Hataları)

Bir uygulamada güvenlikle ilgili kritik olaylar kaydedilmediğinde veya bu olaylar için uyarı mekanizmaları kurulmadığında, savunma ekiplerinin bir saldırıyı tespit etmesi veya soruşturması imkansız hale gelir. İyi bir günlükleme (logging) altyapısı, IAAA modelinin “Accountability” (Hesap Verilebilirlik) ilkesinin temelini oluşturur. Yani kimin, neyi, ne zaman ve nereden yaptığını kanıtlayabilmemizi sağlar.

Pratikte karşılaşılan yaygın Logging ve Alerting hataları şunlardır:

Eksik Kimlik Doğrulama Olayları: Başarılı veya başarısız giriş denemelerinin kaydedilmemesi.
Belirsiz Hata Logları: “Bir hata oluştu” gibi, teknik detay içermeyen ve soruşturmayı zorlaştıran kayıtlar.
Uyarı Mekanizması Eksikliği: Kaba kuvvet (brute-force) saldırıları veya yetki değişiklikleri anında sistemin alarm vermemesi.
Kısa Saklama Süreleri (Retention): Logların çok çabuk silinmesi nedeniyle geçmişe dönük analiz yapılamaması.
Güvensiz Depolama: Saldırganların ulaşıp değiştirebileceği veya silebileceği şekilde saklanan log dosyaları.

Uygulama: Saldırı Analizi ve Soruşturma

TryHackMe laboratuvarındaki bu görevde, saldırı altındaki bir uygulamada nelerin olup bittiğini anlamak için bir olay incelemesi (investigation) gerçekleştireceğiz.

Statik siteyi başlatın ve sunulan log kayıtlarını inceleyin.
Saldırganın hangi IP adresinden geldiğini, hangi hesapları hedeflediğini ve başarılı olup olmadığını loglar üzerinden tespit edin.
Kendinize şu soruyu sorun: Eğer bu log kayıtlarındaki anahtar bilgiler (IP adresi, zaman damgası veya işlem türü) eksik olsaydı, bu saldırıyı analiz etmek ne kadar zor olurdu?

Log analizi yaparken, eksik bir verinin bir siber güvenlik analisti için “karanlıkta yürümek” gibi olduğunu unutmayın!

Soru 1-) Saldırganın kaba kuvvet saldırısı yapmaya çalıştığı anlaşılıyor, saldırganın IP adresi nedir?

Anlatım 1-)

Görselde göründüğü üzre bir ip adresinden admin paneli giriş sayfamıza çok sayıda kullanıcı adı ve parola denendiğini görüyoruz.

Soru 2-) Görünüşe göre bir hesaba erişim sağlamayı başardılar! Bu hesapla ilişkili kullanıcı adı nedir?

Anlatım 2-)

İp adresinin hareketlerine baktığımızda sunucudan dönen 200 OK (tamam arkadaş sana inanıyorum sen geçebilirsin) yanıtı bize hesabımıza giriildiğini gösterir. loglara baktığımızda ?user=admin kullanıcı adının bizim kullanıcı adımız olduğunu görüyoruz.

Soru 3-) Saldırgan hesapla hangi işlemi yapmaya çalıştı? Eriştiği uç noktaları listeleyin.

Cevap-) yukarıdaki görsele bakarsanız aynı ip numarasının girdiği dizinin /supersecretadminstuff dizini olduğunu görüyoruz.

Bu eğitimlere bir oyun olarak bakabilirsiniz. eğer merakınız varsa ne kadar eğlenceli olduğunu fark edeceksiniz.

⚠️ Küçük Bir Not: Burada paylaşılan bilgiler sadece eğitim ve etik hacking amaçlıdır. Bu teknikleri izin almadığın sistemlerde denersen, kariyerine “içeriden” devam etmek zorunda kalabilirsin ( 2 yıldan başlar, sen bilirsin… ). Yani sorumluluk tamamen sende, ben sadece yolu gösteriyorum! 😉

Etik sınırlarda kal ama sistemlerin sınırlarını zorlamaktan asla vazgeçme. Bilgi en büyük güçtür ve sen bu gücü yönetmeye adayısın. Şimdi terminale dön ve dünyayı daha güvenli bir yer yapmaya devam et! 🚀💻