Selamlar Sevgili Siberatay Mensupları,
Web Güvenliği serimizin yedinci partına hepiniz hoş geldiniz.
Şimdiye kadar bu seride sunucunun en karanlık köşelerine kadar indik. XSS ile tarayıcıları esir aldık, SQL Injection ile veritabanlarının şah damarını kestik, Dosya Yükleme zafiyetleriyle RCE tetikleyip sunucunun dosya sistemini ele geçirdik, hatta SSRF ve XXE ile iç ağın ve XML işleyicilerinin gizli kalmış zaaflarını sömürdük. Tüm bu anlattıklarımız teknik olarak muazzam ve kritik açılardı. Peki, bir uygulamanın ön yüzü taş gibi görünüyorsa, arka planda tek bir satır bile açık kod (RCE veya SQLi) barındırmıyorsa ama sistemin kim olduğu veya neye gücünün yeteceği tamamen yanlış kurgulandıysa ne olur?
İşte o an, kalenin ana kapısının aslında hiç kilitlenmediğini, üzerine sadece rüzgârda sallanan "Lütfen bu kapıyı zorlamayın" yazılı bir tabela asıldığını anlarsınız.
Bugün siber güvenliğin en yaygın, en sinsi ve OWASP Top 10 listesinin her zaman zirvesine oynayan iki devasa problemini masaya yatırıyoruz: Broken Authentication (Kırık Oturum Yönetimi) ve Broken Access Control / Authorization (Yetkilendirme Hataları). Bu açıklar öyle sıradan hatalar değildir; uygulamanın mantığını, işleyiş kurallarını ve en temel mantıksal emniyet supaplarını doğrudan bypass eder.
Çaylar kahveler hazırsa, sistemin en hassas noktası olan "kimlik, rol ve oturum" mekanizmalarını kökten parçalamaya başlıyoruz.
1. BÖLÜM: Kimlik Doğrulama (Authentication) İle Yetkilendirme (Authorization) Arasındaki İnce Çizgi
Konunun derinliklerine dalmadan önce, sektörde çalışan yazılımcıların bile sürekli birbirine karıştırdığı o iki temel kavramı net bir şekilde ayıralım. Bu ayrımı yapamayan bir geliştirici sistem güvenliğini asla sağlayamaz:
- Authentication (Kimlik Doğrulama - Sen Kimsin?): Kullanıcının sisteme kullanıcı adı ve şifreyle, SMS/Authenticator kodlarıyla (MFA) veya biyometrik verilerle giriş yaparak gerçekte kim olduğunu kanıtlaması sürecidir. Sistem burada şunu doğrular: "Evet, bu gelen kişi veritabanındaki kayıtlı Ahmet kullanıcısıdır." Kimlik doğrulama bittikten sonra sisteme bir oturum anahtarı (token veya çerez) verilir.
- Authorization (Yetkilendirme - Ne Yapabilirsin?): Kullanıcı giriş yaptıktan sonra sistem içerisindeki hangi sayfaları görebileceğini, hangi API uç noktalarına (endpoints) istek atabileceğini, hangi verileri okuyabileceğini veya hangi kritik işlemleri (silme, güncelleme, rol değiştirme) yapabileceğini belirleyen yetki matrisidir. Sistem burada şunu sorgular: "Tamam, senin Ahmet olduğunu doğruladık; ama sen standart bir üyesin, şu an admin paneline girmeye çalışıyorsun, bu yetkiye sahip misin?"
İşte güvenliğin koptuğu noktalar tam olarak buralarda başlar. Broken Authentication, adamın kimliğini zayıf veya yanlış doğrulaması (tahmin edilebilir çerezler, açıkta kalan token'lar); Broken Access Control ise Ahmet'in sisteme girdikten sonra yetkisini aşarak Mehmet'in verilerine erişmesi ya da doğrudan admin endpoint'lerine istek atıp yetki yükseltmesidir.
2. BÖLÜM: Yetkilendirme Hataları ve Privilege Escalation (Yetki Yükseltme)
Modern web uygulamaları genellikle istemci tarafı (frontend) ile sunucu tarafı (backend) mimarisiyle çalışır. Geliştiricilerin yaptığı en büyük hata, güvenliği istemci tarafındaki arayüze emanet etmektir. Örneğin geliştirici panelinde şöyle bir mantık kurulur: "Eğer kullanıcının rolü 'user' ise, ekrandaki 'Admin Paneli' butonunu gizle/gösterme."
Bir sızma testi uzmanı veya hacker için bu durum sadece gülünç bir detaydır. Çünkü tarayıcıdaki o butonu gizlemek, arka plandaki
Bir sızma testi uzmanı veya hacker için bu durum sadece gülünç bir detaydır. Çünkü tarayıcıdaki o butonu gizlemek, arka plandaki
/admin/delete_all URL'sini korumaz. HTTP istekleri tarayıcıya mahkum değildir; Burp Suite, Postman veya cURL kullanarak sunucuya dilediğiniz isteği milisaniyeler içinde atabilirsiniz. Bu durum yetki yükseltme (Privilege Escalation) açıklarını doğurur:
A. Dikey Yetki Yükseltme (Vertical Privilege Escalation - Privilege Elevation)
Standart bir kullanıcının (örneğin
role=user), sistemde daha yüksek yetkilere sahip bir rolün (örneğin role=admin veya moderator) fonksiyonlarına veya sayfalarına doğrudan erişmesidir.
- Canlı Senaryo: Bir firma içi yönetim panelinde, normal bir çalışan şifre sıfırlama veya kullanıcı onaylama ekranına erişmek ister. Arayüzde bu buton normal üyede görünmez. Ancak geliştirici, arka plandaki
POST /api/admin/approve_userfonksiyonuna gelen isteklerde kullanıcının rolünü backend tarafında doğrulamayı unuttuysa, standart kullanıcı bu isteği doğrudan göndererek sistemi tamamen ele geçirebilir. Geliştirici sadece arayüzü gizlemiş, arka kapıyı kilitlemeyi unutmuştur.
B. Yatay Yetki Yükseltme (Horizontal Privilege Escalation - IDOR'un Kardeşi)
Aynı yetki seviyesindeki iki farklı kullanıcının birbirlerinin hassas verilerine erişmesidir. Yatay yetki yükseltme, genellikle IDOR (Insecure Direct Object Reference) zafiyetleri ile kol kola yürür.
- Canlı Senaryo: Ahmet ve Mehmet aynı yetki grubunda yer alan iki farklı müşteridir. Ahmet, e-ticaret sitesinde kendi sipariş detaylarını görmek için şu isteği atar:
GET /api/v1/orders/1054Ahmet, yazılımcının yetki kontrolü yazmadığını fark eder ve URL'deki1054rakamını1053yaparak isteği yollar. Sunucu, "Bu sipariş ID'si veritabanında var mı? Var." diyerek direkt Mehmet'in sipariş detaylarını, ev adresini, telefon numarasını ve kredi kartı maskelenmiş bilgilerini Ahmet'in ekranına basar. Geliştirici sadece kullanıcının "oturum açmış" olmasını yeterli saymış, "Bu sipariş gerçekten bu isteği atan kullanıcıya mı ait?" kontrolünü sorguya eklememiştir.
3. BÖLÜM: Kırık Oturum Yönetimi (Broken Authentication)
Bir uygulamanın kapıları ne kadar çelikten olursa olsun, oturum anahtarını (session token) paspasın altına saklıyorsanız o kale ilk rüzgârda yıkılmaya mahkûmdur. Kırık oturum yönetimi, kullanıcıların oturumlarının veya kimlik doğrulama token'larının zayıflıklar yüzünden ele geçirilmesi durumudur.
A. Zayıf ve Tahmin Edilebilir Oturum ID'leri (Session Tokens)
Eğer sistem oturum çerezlerini (
PHPSESSID, JSESSIONID vb.) üretirken kriptografik olarak güvenli olmayan, zayıf rastgele sayı üreteçleri kullanıyorsa veya kullanıcı ID'lerini sıra numarasıyla (1, 2, 3...) artırarak veriyorsa felaket kaçınılmazdır.
- Saldırgan kendi hesabını açar, çerez değerinin
1504olduğunu görür. Birkaç denemeyle bu değerlerin ardışık gittiğini fark eder.1503,1502ve1501numaralı çerezleri kendi tarayıcısına enjekte ederek sistemdeki diğer rastgele kullanıcıların hesaplarına şifresiz bir şekilde giriş yapar (Session Hijacking).
B. URL İçinde Oturum Bilgisi Taşınması (Session ID in URL)
Bazı eski ya da hatalı tasarlanmış sistemler, oturum token'larını tarayıcı çerezlerinde saklamak yerine URL parametresi olarak taşır:
Bu durum; sunucu loglarında, proxy loglarında, tarayıcı geçmişinde, ortak kullanılan bilgisayarlarda ve dış sitelere giden
[https://sirket.com/dashboard?session_id=secret_token_x99a7b](https://sirket.com/dashboard?session_id=secret_token_x99a7b)Bu durum; sunucu loglarında, proxy loglarında, tarayıcı geçmişinde, ortak kullanılan bilgisayarlarda ve dış sitelere giden
Referer başlıklarında bu token'ların açıkça sızmasına yol açar. Ağ trafiğini dinleyen herhangi biri bu token'ı kopyalayarak kurbanın oturumunu tamamen devralabilir.
C. Eksik Zaman Aşımı ve Güvensiz Çıkış İşlemleri (Session Fixation & Timeout)
Kullanıcı arayüzde "Çıkış Yap" (Logout) butonuna bastığında tarayıcı sekmesi kapanır; ancak backend tarafındaki veritabanında
o oturum token'ı hâlâ
Saldırgan daha önce ele geçirdiği o eski token ile istek atmaya devam edebilir ve
sistem bunu geçerli bir oturum olarak kabul eder.
o oturum token'ı hâlâ
active olarak kalmaya devam ederse büyük bir açık doğar. Saldırgan daha önce ele geçirdiği o eski token ile istek atmaya devam edebilir ve
sistem bunu geçerli bir oturum olarak kabul eder.
4. BÖLÜM: Güvenli Mimari ve Yetkilendirme Nasıl Sağlanır? (Defansif Mimari)
Bu devasa mantıksal açıkları sistemden tamamen kazımak ve güvenli bir mimari inşa etmek için
yazılım geliştirme yaşam döngüsünde şu katı kuralların uygulanması şarttır:
yazılım geliştirme yaşam döngüsünde şu katı kuralların uygulanması şarttır:
- Merkezi Yetki Kontrolü (Centralized Access Control & Middleware): Her bir controller veya sayfa içerisine ayrı ayrı yetki kontrolü yazmak unutulmaya mahkûmdur. Bunun yerine, sisteme gelen her HTTP isteğini karşılayan merkezi bir süzgeç (Middleware / Interceptor) yazılmalıdır. İstek geldiği an kullanıcının rolü, yetki matrisi ve hedef kaynağa erişim hakkı merkezi olarak doğrulanmalıdır.
- BOLA / IDOR Karşıtı Veritabanı Doğrulaması: Her veri erişim veya güncelleme isteğinde, nesnenin ID'si ile isteği yapan kullanıcının ID'sinin uyuşup uyuşmadığı veritabanı seviyesinde sorgulanmalıdır. Örnek güvenli sorgu mantığı:
SELECT * FROM documents WHERE id = ? AND owner_user_id = ? - Güvenli Çerez ve Token Yapılandırmaları: Oturum çerezleri üretilirken kesinlikle kriptografik olarak güçlü kütüphaneler kullanılmalıdır. Çerezler tarayıcıda saklanırken mutlaka HttpOnly (JavaScript ile okunamaz), Secure (Sadece HTTPS üzerinden taşınır) ve
SameSite=Strictbayraklarıyla (flags) işaretlenmelidir. - Çok Faktörlü Kimlik Doğrulama (MFA / 2FA) Zorunluluğu: Şifrelerin sızma riskine karşı özellikle kritik rollerde, finansal işlemlerde ve yönetim panellerinde ikinci bir doğrulama katmanı (TOTP, donanım anahtarları) kesinlikle zorunlu kılınmalıdır.
ÖZET VE TOPARLAMA
Bugün uygulamanın kimlik, oturum ve yetki mekanizmalarının en derin katmanlarına indik:
- Kimlik doğrulama ile yetkilendirme arasındaki kritik farkları ve bu farkların güvenlik politikalarındaki yerini inceledik.
- Dikey yetki yükseltme ile standart kullanıcıların nasıl admin yetkilerine tırmandığını, yatay yetki yükseltme ile IDOR zafiyetlerinin verileri nasıl sızdırdığını ele aldık.
- Zayıf oturum çerezleri, URL içinde taşınan token'lar ve oturum yönetimi açıklarının doğurduğu riskleri masaya yatırdık.
- Merkezi middleware yapıları, güvenli çerez bayrakları ve sıkı veri doğrulama kuralları ile bu açıkların nasıl kökten çözüleceğini detaylıca işledik.
 Yasal ve Etik Kullanım UyarısıBu içerikte yer alan teknik bilgiler yalnızca eğitim, farkındalık ve yetkili güvenlik testleri amacıyla paylaşılmıştır. Anlatılan yöntemlerin yalnızca kendi sistemlerinizde veya açıkça izin verilmiş laboratuvar/test ortamlarında uygulanması tavsiye edilir. |
Siber güvenliğin en sinsi ve en çok hayat kurtaran mantıksal hatalarından biri olan bu konuları,
kendi laboratuvar ortamlarınızda bizzat test ederek pratik yapmanız vizyonunuzu tamamen tazeleyecektir.
Sırada bu muazzam serinin final partı ve yeni seri planlamalarımız var. Hazırlıklarınızı yapın.
Bu günkü konumuz bu kadardı.
Kodunuz bug'sız, kahveniz koyu olsun.
İyi Forumlar Dilerim.
kendi laboratuvar ortamlarınızda bizzat test ederek pratik yapmanız vizyonunuzu tamamen tazeleyecektir.
Sırada bu muazzam serinin final partı ve yeni seri planlamalarımız var. Hazırlıklarınızı yapın.
Bu günkü konumuz bu kadardı.
Kodunuz bug'sız, kahveniz koyu olsun.
İyi Forumlar Dilerim.