Bu hususların yokluğunda, sistemler etkisiz güvenlik kontrolleri ile güçlendirilebilir veya tamamen eksik olabilir. Bu, sürüm son tarihini karşılamak için acele eden ekiplere veya karşılaşabilecekleri güvenlik tehditlerinden habersiz olanlara atfedilebilir.
Bu tehdit modelleme ve en iyi uygulamalara ve ilkelere bağlılık eksikliği, bilgisayar korsanları olarak yararlanabileceğimiz şeydir.
Güvensiz bir tasarım güvenlik açığı olarak kabul edilen şey olarak görüldüğünü anlamak için, bazılarını değerlendirelim. Yaygın Zayıflık Nümerasyonları (Söndürme) bu sınıflandırmaya eşlenmiştir. Listenin tamamını buradan görüntüleyebilirsiniz.
CWE-602: Sunucu tarafı güvenliğinin istemci tarafı uygulaması
Bu tasarım zayıflığı, bir sunucu yalnızca güvenlik politikalarını uygulamak için istemci tarafı korumalarına dayandığında ortaya çıkar.
Birçok web uygulaması, kötü amaçlı yüklerin sunucu tarafından işlenmesini önlemek için giriş doğrulaması veya sterilizasyon uygular. Bu güvenlik önlemleri ayrıca, izin verilen veri türünü, minimum/maksimum uzunluk, format veya karakterleri düzenleyen kurallar gibi son kullanıcıların göndermelerine izin verildiği veri.
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 edilmezse, bu savunma önlemlerini bir Caido gibi http proxy aracı. Tarayıcı tarafından gönderildikten sonra bir isteği ele geçirerek, herhangi bir istemci tarafı kısıtlamalarını veya kontrollerini atlayarak gönderilen verileri değiştirmenize izin verebilirsiniz.
Örneğin, alanlara giriş sağlarken kullanıcıları alfasayısal 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ı:
Bu bir yükü engellerken Gönderilmekten, arka uç verileri tekrar doğrulamazsa, başlangıçta geçerli giriş sağlayabilir ve daha sonra durdurulan bir istekte değeri değiştirebilirsiniz:
| Post /Yorum HTTP /1.1 Host: Örnek.com Yorum =%3cimg%20SRC%3DX%20onerror%3Dalert ()%3e |
Benzer şekilde, sanitizasyon, komut dosyası etiketleri içeren verileri kaldırmak için kullanılıyor, ancak yalnızca ön uçta gerçekleştiriliyorsa, etiketi başka bir içine yerleştirerek bu kontrolü atlayabilirsiniz:
Gördüğünüz gibi, bu güvenlik açığı, arka uç tarafından ele alınacak keyfi veriler göndermenize izin verecektir – amaçlanmayan bir tasarım seçimi. Bu normal bir kullanıcı için yeterli olsa da, bir hata ödül avcısı olarak size karşı yetersiz olacaktır.
CWE-73: Dosya adının veya yolunun harici kontrolü
Dosyaları belirten parametreler ortaya çıktığında, uygun kısıtlamalar olmadan, rasgele dosyalara erişebilir, değiştirebilir veya yürütebilirsiniz. Bu, bu dizinler hassas sistem dosyaları içerdiğinden, web kökü dışındaki dosyalara ve dizinlere erişim mümkün olduğunda özellikle etkili olabilir.
Örneğin, bir uygulama bir web sayfasının bayrağı olarak kullanılacak bir resim 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 görüntü uzantısında bitmesini sağlamak gibi güvenlik kontrolleri uygulansa bile, bir null bayt kullanarak dosya yolunu sonlandırmak mümkün olabilir:
| Get /image?filename=../../../etc/passwd%00.jpg |
Traversal diziler eşleştiriliyor ve kaldırılıyorsa, daha önce bahsedilen aynı gömme tekniği bu dezenfektanlığı atladı:
| Get /image?filename=….//….////etc/passwd |
Web uygulaması dosya yükleme işlevselliği sunuyorsa, bu güvensiz tasarım özelliğinin varlığı kötü amaçlı dosyalar yükleme yeteneğine neden olabilir. Örneğin, bir sunucu PHP’yi arka uç dili olarak kullanıyorsa, kendi PHP dosyanızı aşağıdaki komut dosyasıyla yükleyerek potansiyel olarak uzaktan kod yürütme elde edebilirsiniz:
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 isteklerinin tutarsız yorumu
Bir sistemin mimarisindeki bazı güvensiz tasarım güvenlik açıkları, HTTP istek kaçakçılığı saldırıları yoluyla kullanılabilir.
İyi bilinmeyen ve böylece düşük trafik seviyeleri alan web uygulamaları için, tek bir sunucu büyük olasılıkla gelen tüm talepleri yerine getirecek kadar yeterlidir. Bununla birlikte, popüler uygulamalar solo bir sunucuyu ezecek – gecikme sorunlarına veya kesintilere yol açacak trafik seviyeleri alabilir. Sistem kesinti süresine karşı hafifletmek için ağ mühendisleri, iş yükünü hafifletmek için arka uç sunucularının önüne sunucuları (yük dengeleyicileri veya ters proxy) yerleştirebilir. Bu ön uç sunucuları, birden fazla isteği keser, bunları gruplandırır ve paketlenmiş istekleri hiç kimsenin arka uç sunucusunun bunalmış olmasını sağlayacak şekilde dağıtır. Bu paketteki her istek bir işlem kuyruğuna girecektir.
Bu paketlenmiş istekleri tanımlamak için, HTTP/1.1, bir isteğin nerede bittiğini belirtmek için iki istek başlığı kullanır ve diğeri başlar: içerik uzunluğu ve aktarma kodlama.
İçerik uzunluğu başlığının değeri, bir isteğin gövdesindeki bayt sayısını temsil eder. Örneğin:
| Post /Yorum HTTP /1.1 Host: Örnek.com İçerik uzunluğu: 28 İçerik Türü: Uygulama/X-WWW-Form-Urlence kodlu yorum = x & kullanıcı adı = ninjeeter |
Aktarım kodlama üstbilgisinin değeri yığın olarak ayarlanırsa, istek gövdesi verileri “parçalar” olarak adlandırılan bir veya daha fazla porsiyona ayrılır. Veriler de bayt cinsinden ölçülür, ancak onaltılık kodlamada temsil edilir. Bu üstbilgi ile, bir isteğinin sonu bir parça boyut 0 ile işaretlenmiştir. Örneğin:
| Post /Yorum HTTP /1.1 Host: Örnek.com Transfer kodlama: yığın İçerik Türü: Uygulama/X-WWW-Form-Urlence kodlu 1C |
Güvenlik açığı, başlığın kullanılacağı ön uç ve arka uç sunucusu arasında bir uyumsuzluk olduğunda ortaya çıkar. Her iki başlık ile bir istek göndererek, ön uç birden çok istek tek bir istek olduğunu düşünmek için 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 içerik uzunluğu başlığının değerini kullanıyorsa, ancak arka uç aktarım kodlama kullanıyor: Yığınlı-potansiyel olarak kısıtlı bir uç noktaya “kaçınabilir”:
| Post /Yorum HTTP /1.1 Host: Örnek.com Çerez: oturum = 123ABC İçerik uzunluğu: 138 İçerik Türü: Uygulama/X-WWW-Form-Urlence kodlu Transfer kodlama: yığın 0 Get/admin/sil? Name = diğer kullanıcı http/1.1 x = |
Bu istek ön uçtan biri olarak, arka uçla iki olarak görülecektir. Arka uç GET/Admin/Delete? Name = diğer kullanıcı HTTP/1.1 isteğine ulaştığında, eksik 49 bayt bekleyen işleme sırasında tutulacaktır. Boş parametre x = sonraki isteği yakalayacak ve ilk 49 baytı ondan alacaktır.
İçerik uzunluğu başlığının değerinin CRLF karakterlerini içerdiğini belirtmek önemlidir. Her \ r ve \ n, bir bayt olarak kabul edilir:
Hackerone platformunda güvenlik araştırmacıları tarafından gönderilen bazı HTTP isteği kaçakçılık raporları şunlardır:
CWE-840: İş mantığı hataları
İş mantığı güvenlik açıkları, kötü niyetli saldırganların istenmeyen sonuçlar elde etmek için bir uygulamanın meşru işleme akışından yararlanmasına izin verir. Bu sorunlar, öngörülemeyen kullanıcı davranışı ve tasarım seçeneklerinden kaynaklanmaktadır.
Çok aşamalı işleme akışlarında, geliştiriciler belirli parametrelerin kaldırıldığı, yeniden kullanıldığı veya değiştirildiği senaryoları öngörmeyebilir. Bu parametreler bir işlemin uygun sonucu için kritik olabilir. İş mantığı güvenlik açıkları için test edilmesi gereken veri akışları şunları içerir:
- Parola Sıfırlama İşlevselliği
- Kimlik doğrulama akışları
- Hesap bilgilerini güncelleme
- E-ticaret satın alma akışları
- İndirim Kodları Uygulama
Bazı önemli parametreler, değerleri yaygın olarak bilindiği için doğal olarak güvensiz olabilir. Örneğin, geliştiricilerin bir şifre sıfırlamasına izin vermeden önce bir güvenlik sorusuna cevap verilmesi gerekiyorsa, ancak soru çok genel, örneğin: “Hangi şehirde büyüdünüz?” – Doğru cevabı zorlamak için bu kelime listesini kullanabilirsiniz.
Bu güvenlik açıkları, bir web uygulamasının sunduğu işlevselliğin özel bağlamında ortaya çıktığından, bu güvensiz tasarım zayıflıkları derinlemesine kod incelemesi olmadan tespit edilmeyebilir. Bir uygulamada gezinirken, kullanıcı eylemlerinin amaçlanan akışına aşina olduğunuzdan emin olun ve daha sonra sürecin nasıl kullanılabileceğini beyin fırtınası yapabilirsiniz.
Çözüm
Güvensiz tasarım güvenlik açıkları genellikle bir uygulamaya güç veren belirli teknolojilere bağlıdır. Bu nedenle, potansiyel zayıflıkları aramadan önce kullanılan teknolojileri tanımlamak ve anlamak çok önemlidir. Bu, Whatruns veya Wappalizer gibi araçlar kullanılarak gerçekleştirilebilir. Uygulamanın nasıl çalıştığını derinlemesine anlamak da önemlidir, bu nedenle yeterli zaman tek bir hedefe yatırın. Nihayetinde, bir uygulamayı sıfırdan korumak, ayrıntılara dikkat edilmesini gerektirir ve herhangi bir gözetim sizin için bir ödül ödemesine neden olabilir.