Bu hususların yokluğunda, sistemler etkisiz güvenlik kontrolleriyle donatılabilir veya bunlardan tamamen yoksun olabilir. Bu, ekiplerin yayınlanma tarihini yakalamak için acele etmesinden veya karşılaşabilecekleri güvenlik tehditlerinden habersiz olmasından kaynaklanabilir.
Bu tehdit modelleme eksikliği ve en iyi uygulamalara ve ilkelere bağlılık, bilgisayar korsanları olarak bizim faydalanabileceğimiz şeydir.
Neyin güvenli olmayan tasarım güvenlik açığı olarak kabul edildiğini anlamak için, bazı güvenlik açıklarını değerlendirelim. Ortak Zayıflık Sayımları (CWE’ler) bu sınıflandırmaya eşlenmiştir. Listenin tamamını burada görebilirsiniz.
CWE-602: Sunucu Tarafı Güvenliğinin İstemci Tarafında Uygulanması
Bu tasarım zayıflığı, bir sunucunun güvenlik ilkelerini uygulamak için yalnızca istemci tarafı korumalarına dayanması durumunda ortaya çıkar.
Birçok web uygulaması, kötü amaçlı yüklerin sunucu tarafından işlenmesini önlemek için giriş doğrulama veya temizleme uygular. Bu güvenlik önlemleri aynı zamanda izin verilen veri türünü, minimum/maksimum uzunluğu, formatı veya karakterleri düzenleyen kurallar gibi son kullanıcıların göndermesine izin verilen verileri de kısıtlar.
Bu korumalar genellikle istemci tarafında gerçekleşir çünkü kontrollerin hızını artırır ve daha iyi bir kullanıcı deneyimi sağlar, ancak kullanıcı girişi sunucu tarafından da düzgün bir şekilde kontrol edilmiyorsa, bir güvenlik duvarı kullanarak bu savunma önlemlerini kolayca atlatabilirsiniz. Caido gibi HTTP proxy aracı. Bir isteği tarayıcı tarafından gönderildikten sonra durdurarak, istemci tarafı kısıtlamalarını veya kontrollerini atlayabilir ve gönderilen verileri değiştirmenize olanak tanıyabilirsiniz.
Örneğin, alanlara girdi sağlarken kullanıcıları alfanümerik karakterlerle sınırlayan bir form düşünün. Bunu başarmak için geliştiriciler Zod kütüphanesini kullanarak aşağıdaki doğrulama şemasını tanımladılar:
Bu, aşağıdaki gibi bir yükü engellerken Arka uç verileri tekrar doğrulamıyorsa, başlangıçta geçerli bir giriş sağlayabilir ve ardından ele geçirilen bir istekteki değeri değiştirebilirsiniz:
| POST /yorum HTTP/1.1 Ana bilgisayar: example.com comment=%3Cimg%20src%3Dx%20onerror%3Dalert()%3E |
Benzer şekilde, komut dosyası etiketleri içeren verileri kaldırmak için temizleme işlemi kullanılıyorsa ancak yalnızca ön uçta gerçekleştiriliyorsa, etiketi başka bir etiketin içine yerleştirerek bu kontrolü atlayabilirsiniz:
Gördüğünüz gibi bu güvenlik açığı, arka uç tarafından işlenecek rastgele veriler göndermenize olanak tanır; bu, amaçlanmayan bir tasarım seçimidir. Bu normal bir kullanıcı için yeterli olsa da, bir ödül avcısı olarak size karşı yetersiz kalacaktır.
CWE-73: Dosya Adının veya Yolunun Harici Kontrolü
Dosyaları belirten parametreler uygun kısıtlamalar olmadan açığa çıktığında, isteğe bağlı dosyalara erişebilir, bunları değiştirebilir veya çalıştırabilirsiniz. Bu dizinler hassas sistem dosyaları içerdiğinden, web kökü dışındaki dosya ve dizinlere erişim mümkün olduğunda bu özellikle etkili olabilir.
Örneğin, bir uygulama bir web sayfasının banner’ı olarak kullanmak üzere bir görüntü dosyası seçerse, diğer dosyalara erişmek için dizin geçiş tekniklerini kullanabilirsiniz:
| GET /image?filename=../../../etc/passwd |
Dosya adının bir resim uzantısıyla bitmesini sağlamak gibi güvenlik kontrolleri uygulansa bile, boş bayt kullanarak dosya yolunu sonlandırmak mümkün olabilir:
| GET /image?filename=../../../etc/passwd%00.jpg |
Geçiş dizileri eşleştirilip kaldırılıyorsa, daha önce bahsedilen aynı yerleştirme tekniği bu temizleme işlemini atlayabilir:
| GET /image?filename=….//….///….//etc/passwd |
Web uygulaması dosya yükleme işlevi sunuyorsa, bu güvenli olmayan tasarım özelliğinin varlığı, kötü amaçlı dosyaların karşıya yüklenebilmesiyle sonuçlanabilir. Örneğin, bir sunucu arka uç dili olarak PHP kullanıyorsa, aşağıdaki komut dosyasıyla kendi PHP dosyanızı yükleyerek potansiyel olarak uzaktan kod yürütmeyi gerçekleştirebilirsiniz:
Yüklenen dosyanın konumuna giderek ve komut parametresini sağlayarak sunucuda sistem komutlarını çalıştırabilirsiniz:
| GET /uploads/command.php?command=whoami |
CWE-444: HTTP İsteklerinin Tutarsız Yorumlanması
Bir sistemin mimarisindeki belirli güvenli olmayan tasarım açıkları, HTTP istek kaçakçılığı saldırıları yoluyla kullanılabilir.
İyi bilinmeyen ve dolayısıyla düşük düzeyde trafik alan web uygulamaları için, tek bir sunucu büyük olasılıkla gelen tüm istekleri karşılamaya yeterlidir. Ancak popüler uygulamalar, tek bir sunucuyu zorlayacak düzeyde trafik alabilir ve bu da gecikme sorunlarına veya kesintilere neden olabilir. Ağ mühendisleri, sistemin aksama süresini azaltmak için iş yükünü hafifletmek amacıyla sunucuları (yük dengeleyiciler veya ters proxy’ler) arka uç sunucuların önüne yerleştirebilir. Bu ön uç sunucuları birden fazla isteği yakalayacak, bunları gruplandıracak ve birleştirilmiş istekleri, hiçbir arka uç sunucusunun aşırı yük altında kalmamasını sağlayacak şekilde dağıtacaktır. Bu paketteki her istek bir işleme kuyruğuna girecektir.
Bu birleştirilmiş istekleri tanımlamak için HTTP/1.1, bir isteğin nerede bitip diğerinin nerede başladığını belirtmek için iki istek başlığı kullanır: İçerik Uzunluğu ve Aktarım Kodlaması.
Content-Length başlığının değeri, bir isteğin gövdesindeki bayt sayısını temsil eder. Örneğin:
| POST /yorum HTTP/1.1 Ana bilgisayar: example.com İçerik Uzunluğu: 28 İçerik Türü: application/x-www-form-urlencoded yorum=X&kullanıcı adı=ninjeeter |
Transfer Kodlama başlığının değeri parçalanmış olarak ayarlanmışsa, istek gövdesi verileri “parçalar” olarak adlandırılan bir veya daha fazla bölüme bölünür. Veriler ayrıca bayt cinsinden ölçülür ancak onaltılık kodlamayla temsil edilir. Bu başlıkla, bir isteğin sonu 0 yığın boyutuyla işaretlenir. Örneğin:
| POST /yorum HTTP/1.1 Ana bilgisayar: example.com Transfer Kodlaması: parçalanmış İçerik Türü: application/x-www-form-urlencoded 1c |
Güvenlik açığı, başlığın kullanılacağı ön uç ve arka uç sunucu arasında bir uyumsuzluk olduğunda ortaya çıkar. Her iki başlıkla bir istek gönderildiğinde ön uç, birden fazla isteğin tek bir istek olduğunu düşünerek kandırılır. Ancak arka uç bu “tek” isteği aldıktan sonra her birini ayrı ayrı işler.
Örneğin, ön uç sunucusu bir isteğin sonunu belirlemek için Content-Length başlığının değerini kullanıyorsa, ancak arka uç Transfer-Encoding: chunked kullanıyorsa, potansiyel olarak bir isteği sınırlı bir uç noktaya “kaçırabilirsiniz”:
| POST /yorum HTTP/1.1 Ana bilgisayar: example.com Çerez: oturum=123ABC İçerik Uzunluğu: 138 İçerik Türü: application/x-www-form-urlencoded Transfer Kodlaması: parçalanmış 0 GET /admin/delete?name=diğerkullanıcı HTTP/1.1 x= |
Bu istek ön uçta bir, arka uçta ise iki olarak görülecektir. Arka uç GET /admin/delete?name=otheruser HTTP/1.1 isteğine ulaştığında, eksik 49 baytı bekleyen işlem kuyruğunda tutulacaktır. Boş parametre x= sonraki isteği yakalayacak ve ondan ilk 49 baytı alacaktır.
Content-Length başlığının değerinin CRLF karakterlerini içerdiğine dikkat etmek önemlidir. Her \r ve \n bir bayt olarak kabul edilir:
HackerOne platformunda güvenlik araştırmacıları tarafından gönderilen, ifşa edilmiş bazı HTTP isteği kaçakçılığı raporları şunlardır:
CWE-840: İş Mantığı Hataları
İş mantığındaki güvenlik açıkları, kötü niyetli saldırganların, istenmeyen sonuçlara ulaşmak için bir uygulamanın meşru işlem akışından yararlanmasına olanak tanır. Bu sorunlar, öngörülemeyen kullanıcı davranışlarından ve geliştiricilerin uç durumları hesaba katmayan varsayımlara dayanan tasarım seçimlerinden kaynaklanmaktadır.
Çok adımlı işleme akışlarında geliştiriciler, belirli parametrelerin kaldırıldığı, yeniden kullanıldığı veya değiştirildiği senaryoları öngöremeyebilir. Bu parametreler bir operasyonun doğru sonucu açısından kritik öneme sahip olabilir. İş mantığındaki güvenlik açıklarına karşı test edilmesi gereken veri akışları şunları içerir:
- Şifre sıfırlama işlevi
- Kimlik doğrulama akışları
- Hesap bilgileri güncelleniyor
- E-ticaret satın alma akışları
- İndirim kodlarını uygulama
Bazı önemli parametreler, değerleri yaygın olarak bilindiği için doğası gereği güvensiz bile olabilir. Örneğin, geliştiriciler parola sıfırlamaya izin vermeden önce bir güvenlik sorusunun yanıtlanmasını gerektiriyorsa ancak soru çok genelse, örneğin: “Hangi şehirde büyüdünüz?” – doğru cevabı kaba kuvvetle bulmak için bu kelime listesini kullanabilirsiniz.
Bu güvenlik açıkları, bir web uygulamasının sunduğu işlevsellik bağlamında ortaya çıktığı için, bu güvenli olmayan tasarım zayıflıkları, derinlemesine kod incelemesi yapılmadan tespit edilemeyebilir. Bir uygulamada gezinirken, amaçlanan kullanıcı eylemleri akışına aşina olduğunuzdan emin olun ve ardından süreçten nasıl yararlanılabileceği konusunda beyin fırtınası yapabilirsiniz.
Çözüm
Güvenli olmayan tasarım açıkları genellikle bir uygulamaya güç veren belirli teknolojilerle bağlantılıdır. Bu nedenle, potansiyel zayıflıkları aramadan önce, kullanılan teknolojileri belirlemek ve anlamak çok önemlidir. Bu, WhatRuns veya Wappalyzer gibi araçlar kullanılarak gerçekleştirilebilir. Uygulamanın nasıl çalıştığına dair derinlemesine bir anlayış kazanmak da önemlidir, bu nedenle tek bir hedefe yeterince zaman ayırın. Sonuçta, bir başvuruyu sıfırdan güvence altına almak, ayrıntılara dikkat edilmesini gerektirir ve herhangi bir gözetim, sizin için bir ödül ödemesiyle sonuçlanabilir.