Kategori: Web App Hackers Book Notlar

1. Referer kullanımını nasıl test edersin? Önemli isteklerde referer kısmını silip ve değiştirip tekrar gönderilebilir. Eğer istek cevap veriyorsa uygun şekilde veya isteğin beklediği şekilde referer yazılabilir. Testleri önce yetkili bir kullanıcı ile sonra da yetkisiz bir kullanıcı ile yapmak gerekir. Eğer yetkisiz kullanıcı Referer’i yetkili kullanıcının kullandığı şekilde değiştirir de sonuç alırsa savunmasızdır.
2. Öncelikle aynı id ile benzer php dosyalarına erişmeyi deneyebiliriz.MyAccount değil de listAllUsers.php gibi common sayfaları deneyebilir. Veya adminPanel.php gibi noktaları deneyebiliriz. Daha sonra bu myAccount.php urlsine paramtere olarak admin=true gibi veriler ekleyip sonuçları gözlemlemeye çalışırız. Bu da işe yaramazsa  verdiğimiz id’yi değiştirip farklı sayılar girmeye çalışırız. Farklı id’leri arttırıp azaltarak başka kullanıcıların sayfasına girip giremediğimizi kontrol ederiz. Son olarak da bir hesabın id’sini kullanarak diğer hesaptan erişmeye çalışırız. Eğer erişebilirsek bu session bağlı değil demektir ve zayıflık gösterir.
3. Ip bakarak kısıtlamayı VPN ile aşabiliriz. Veya geçerli alandaki bir IP’ye sahip proxy veya cihaz ile de bağlantı sağlayabiliriz. Bu yüzden IP’ye bağlı erişim güvenli değildir.Başka bir kullanıcının IP adresini taklit etmek mümkündür, ancak pratikte bu çok zor olabilir. Daha da önemlisi, İnternet’teki farklı son kullanıcılar, aynı web proxy’si veya NAT-ting güvenlik duvarının arkasındaysa aynı IP adresini paylaşabilir. Bu durumda IP tabanlı erişim kontrollerinin etkili olabilmesinin bir yolu, yönetim işlevlerine erişmeye çalışan kullanıcıların kuruluşun iç ağında bulunmasını sağlamak için kapsamlı bir savunma önlemidir. Bu işlevler, elbette, sağlam kimlik doğrulama ve oturum işleme mekanizmalarıyla korunmalıdır.
4. Öncelikle alt katmanlarda güvenlik ve yetki kontrolleri sağlandıktan sonra uygulama katmanında veri girişi yapacak admin kullanıcısı için erişim yetkilendirmesi ve kontrolü yapılmalıdır. Bunun dışında kullanıcıların sayfaları ve bilgileri düzenlemesine sebep olabilecek url ve sayfaların erişim kontrolüne tabi tutulması ve admin session yapısı gibi güvenli bir giriş yapısı kurulması gerekir.Örneğin, kullanıcıların yalnızca verilere okuma erişimine ihtiyaç duyması nedeniyle, uygulama veritabanına yalnızca ilgili tablolara salt okunur izinlere sahip düşük ayrıcalıklı bir hesap kullanarak erişmelidir.
5. Çünkü yetkisiz erişimle ulaşılabilen sayfalar ve isimleri belli şablonlarla oluşturulmuş olabilir. Eğer bu şablonu anlayabilirsek sunucu tarafındaki bütün statik dosyalara erişim imkanımız olur.

Öncelikle şu hatalı varsayımlara dikkat edilmeli :

• Kullanıcıların url,id vs gibi bilgileri bilmemesine güvenmeyin. Uygulamanın kendi güvenlik mekanizmalarının olmasını ve kullanıcıların tüm bilgileri bildiğini varsayın
• Kullanıcının gönderidiği hiçbir parametreye güvenmeyin
• Kullanıcıların uygulama sayfalarına mutlaka belli bir sırayla erişeceklerini varsaymayın.
• Her aşamada her yeniden iletilen veriyi yeniden kontrol edin.

Uygulamalara güvenli bir erişim sistemi kurmak için :

• Her fonksiyonun erişimi için gerekli yetkiyi,rolü ve kısıtlamayı net bir şekilde belirleyin
• Tüm kararları kullanıcı oturumundan alın
• Tüm erişim kontrolleri için merkezi bir sistem kullanın
• Kullanıcıların isteklerini doğrulamak için bu sistemi kullanın
• Her sayfaya erişim için programatik bir çözümle test yapın
• Hassas kısımlara erişim için IP kısıtlaması da getirilebilir.
• Statik sayfalar için ya sunucu tarafından oluşturulan dinamik url’ler kullanın ya da sayfaları bir şekilde wrap edip yetki kontrolü yapın.
• Kullanıcı tarafından gelen verilerin tamamı güvenilmezdir. Bu yüzden sunucu tarafında doğrulanmadan işlem yapılmamalıdır.
• Aşırı hassas işlemler için her işlemde yeniden yetkilendirme yapılabilir veya yeniden session ayarlanabilir.
• Herşeyi loglayın

Çok Katmanlı Yetki Modeli

Bir uygulamanın tek bir katmanında güvenlik ve erişim kontrolleri yeterli değildir. Sunucu düzeyinde, veritabanı düzeyinde ve işletim sistemi düzeyinde de erişim kontrolleri bulunmalıdır. Uygulamalara çeşitli şekilde çok katmanlı erişim kontrolleri uygulanabilir :

• Sunucu URL erişimlerinin yetkilere bağlı olması üzerine kullanılabilir
• Farklı yetkilerdeki kullanıcılar için farklı veritabanları kullanılabilir.
• Ayrıcalıklı erişim veritabanı üzerinden kullanıcı rollerine göre bir table ile de belirlenebilir.
• Altyapıda her bileşeni çalıştırmak için kullanılan işletim sistemi hesapları, bileşenin gerçekten gerektirdiği en az güçlü ayrıcalıklarla sınırlandırılabilir.

Hack Adımları

Bu türden çok katmanlı bir ayrıcalık modeli kullanan bir uygulamaya saldırıyorsanız, erişim kontrollerini uygularken yaygın olarak yapılan en bariz hataların çoğuna karşı savunma yapılması muhtemeldir. Diğer katmanlardaki koruma nedeniyle, uygulama içinde uygulanan kontrolleri atlatmanın sizi çok uzağa götürmediğini fark edebilirsiniz. Bunu akılda tutarak, birkaç potansiyel saldırı hattı sizin için hala mevcuttur. En önemlisi, sunmadığı koruma açısından her bir denetim türünün sınırlamalarını anlamak, onu etkileme olasılığı en yüksek olan güvenlik açıklarını belirlemenize yardımcı olacaktır:

• Uygulama katmanındaki kontroller programatik injectionlara açık olabilir
• Sunucu katmanındaki rollerde eksiklikler olabilir
• Uygulama bileşenlerinin ayrıcalıklı olmayan işletim sistemi hesaplarını kullanarak çalıştığı yerlerde, genellikle ana bilgisayar dosya sistemi içindeki pek çok tür hassas veriyi okuyabilirler. Rasgele dosya erişimi sağlayan tüm güvenlik açıklarından, yalnızca hassas verileri okumak için bile olsa, yararlı bir şekilde yararlanılabilir.
• Uygulama sunucu yazılımındaki açıklardan faydalanılabilir.
• Tek bir yetki yükseltme açığı bir anda hiçbirşey yapmadan çok daha fazla açığı elde etmeyi sağlayabilir.

API erişimlerinde yetki kısıtlaması var mı yok mu denenmesi gerekir. Bunun dışında bilinen API isimleriyle de korumasız şekilde erişilebilir olup olmadığına bakmak gerekiyor.

Hack Adımları

1. Belli adlandırma kurallarını kabul eden tüm parametreleri tanımlayın (add,get,remove vs)
2. Varsa kullanılabilir API arayüzlerini gönderen listeyelen bir metot arayın. Yoksa diğer çağrıları tahmin etmeye çalışın.
3. Arama motoru vs araştırmasıyla bulunan bütün çağrı yöntemlerini farklı kullanıcı yetkileriyle erişmeye çalışın.
4. Eğer gerekli parametreleri bilmiyorsanız daha az parametre alan getAllUsersInRoles. gibi metotlara erişmeye çalışın.

Bazı durumlarda statik dosyalara doğrudan erişim sağlanabilir bunların da tespit edilmesi gerekir.

Hack Adımları

1. Normal bir şekilde tüm URL’leri gezip bulabildiğiniz tüm statik urlleri toplamaya çalışın.
2. Daha az yetki sahibi bir kullanıcıyla bu kaynaklara erişmeye çalışın.
3. Eğer erişim varsa bu kaynakların isimlendirmesindeki şablonları tespit etmeye çalışın ve bu şablonlarla diğer kaynaklara da erişmeye çalışın.

HTTP yöntemleri üzerine testler yapmak için :

Hack Adımları

1. Yüksek ayrıcalıklı bir hesap kullanarak, yeni bir kullanıcı eklemek veya bir kullanıcının güvenlik rolünü değiştirmek gibi hassas eylemler gerçekleştiren bazı ayrıcalıklı istekleri belirleyin
2. Eğer bir AntiCSRF koruması yoksa farklı HTTP metotları göndererek işlemin yapılıp yapılmadığını test edin.
3. POST,GET,HEAD ve diğer metotları deneyin
4. Uygulama diğer istek türlerine cevap veriyorsa düşük ayrıcalıklı kullanıcılarla tekrar deneyip cevap verip vermediğini test edin.

 

Uygulamaya kısıtlı bir erişimimiz olduğunda test etmek daha fazla iş gerektirir. Örnek olarak eski ve zayıf bir fonksiyon kaldırılmış ve arayüzde herhangi bir yerden erişilemez olabilir.Bunun bulunması gerekebilir.

Hack Adımları

1. Dördüncü bölümdeki tekniklerle uygulamanın fonksiyonel bütün bölümlerini keşfedin. Normal düzey bir kullanıcı ile gerçekleştirilebilecek bütün kısımların enumaration yapılması önemlidir.
2. Farklı kullanıcı türlerinin ortak kullanması muhtemel olan kısımları, POST requestlere vs url’ye veya body’e admin=true gibi değişkenler ekleyip deneyin.
3. Uygulamanın güvenli olmayan bir şekilde Referer başlığına güvenip güvenmediğini test edin.
4. Bütün HTML ve Js dosyalarını gözden geçirip bir fonksiyona erişim imkanı var mı gözden geçirin. Bir url veya bir admin yöntemi bilgisi bulunuyor olabilir.

Erişilebilir tüm işlevler enumarate edildiğinde, kaynaklara erişimin kullanıcı bazında ayrıştırılmasının doğru bir şekilde uygulanıp uygulanmadığını test etmeniz gerekir. Uygulamanın kullanıcılara aynı türden daha geniş bir kaynak yelpazesinin bir alt kümesine (belgeler, siparişler, e-postalar ve kişisel ayrıntılar gibi) erişim izni verdiği her durumda, bir kullanıcının yetkisiz erişim elde etme fırsatları olabilir. diğer kaynaklar.

Hack Adımları

1. Uygulamanın bir sayfaya erişmek için kullanıcıdan bir bilgi (id, sayfa id, kullanıcı id, mail adresi vs) beklediği yerlerde farklı id’leri vs keşfetmeye çalışın.
2.  Eğer çoklu denemelerle bu tokeni oluşturmak mümkünse başkasının tokenini oluşturmayı deneyin
3. Tahmin edilebilir bir diziyse tahmine etmeye çalışın. GUID ise tahmin etmek oldukça zordur.
4. Eğer kırılabilir bir diziyse otomatik saldırılar yapılabilir

Böyle bir açık bulunduğunda ilk amaç yönetici olarak giriş yapmaya çalışmaktır. Hızlıca kullanıcılar taranıp yönetici bulunabilir. Genelde en düşük id sahip kullanıcı yöneticidir.

 

Çok aşamalı süreçlerde bütün sitemap’a tekrar request atmak aynı sonucu getirmeyebilir. Burada belli aşamaların belli sırayla tekrarlanması gerekebilir. Örnek yeni kullanıcı kayıt edilmesi esnasında kullanıcı bilgilerinin alınmasıyla başlayan birkaç aşama olabilir ve arada sunucu taraflı isteklerle birlikte birkaç farklı tekrar edilemeyen istek oluşabilir. Bu durumda her aşamanın güvenliği ayrı ayrı test edilmelidir.

Hack Steps

1. Aşamalı bir request durumu varsa öncelikle her işlemi ayrı ayrı test edip bütün parametreleriyle iyice incelenmeli
2. Eğer varsa bu aşamaların herhangi birinde, o aşamaya başarıyla geldiğinizi varsayıp kontrol yapılmayan bir nokta bulmaya çalışın ve düşük ayrıcalıklı bir hesapla oraya ulaşmaya çalışın.
3. Bu testi yapmanın bir yöntemi de yüksek yetkili bir hesapla düşük yetkili bir hesabın session tokenini kullanarak yüksek yetkili yerlere giriş yapmaya çalışmaktır.
4. Bu aşamalar burp suite’in request in browser özelliğiyle kolayca gözlemlenebilir takip edilip test edilebilir.

Burp kullanılarak hem cookieler hem de cookie’ler sabit kalırken session token’ler değiştirilerek test yapılabilir. Ayrıca bazen süreçleri farklı kullanıcılarla eşzamanlı olarak takip etmek faydalı olabilir. Bu durumlar için farklı browserlarda burp proxy kurulup context menu den sadece seçtiğimiz proxy’den gelen istekleri inceleyebiliriz.

Uygulamanın erişim kontrollerini test etmenin en verimli yolu farklı kullanıcılarla giriş yapıp bunları test etmektir.

Hack Adımları

1. Eğer mümkünse yüksek ayrıcalıklı bir hesap aç. Daha sonra da düşük ayırcalıklı yetkili bir hesap açık dikey yükseltmeyi dene
2. İki farklı aynı düzey kullanıcı farklı verilere ulaşmak için farklı URL’ler kullanıyorsa birinden diğerinin eriştiği belgeye erişmeyi dene. Örnek olarak aynı URL’ye kendi cookie ve session bilgisiyle erişmeyi dene.

Burp suit aynı sayfaya iki farklı kullanıcı ile erişmeye izin verir. Böylece farklılıkların nerede oluştuğunu görmek mümkündür.

Hack Adımları

1. Burp Intercept kapalı şekilde mümkün olduğunca üst düzey bir kullanıcıyla sayfaları gezin.
2. Her yeri maplediğinizden emin olduktan sonra context menu’den compare site maps kısmını seçin
3. Daha sonra bu compare işlemini yapmak için kolayca daha önceden kayıt ettiğimiz bir site-map’i kullanabiliriz ya da başka bir kullanıcıyla yeniden gezip yeni bir sitemap oluşturup onu kayıt edebiliriz
4. Bunun için burp’e yeni bir kullanıcı sessionu ve cookie’si verebiliriz. Ayrıca herhangi bir logout işlemine tıklamayacağından da emin olmalıyız.

Bu karşılaştırmayı inceleyip arasındaki farkları gözlemleyebilir. Çıkan kısımda kaç fark olduğu ve bu farkların nerelerde olduğu görünüyor.

Örnek olarak burada admin yetkileriyle admin sayfalarına erişen birisi, kullanıcı yetkileriyle bu sayfalara erişmek istediğinde hata alabilir ama bu sayfaları admin olarak kayıt ettiğimiz için kullanıcı olarak gezerken güvenlik mekanizması olmayan bir sayfa bulabiliriz.

Öncelikle bölüm 4 teki gibi uygulamanın erişim kontrol mekanizmasının değerlendirilmesi ve anlaşılması gerekiyor.

Hack Adımları

Öncelikle şu soruların cevaplarının aranarak tespit yapılır :

1.  Uygulama, kullanıcılara kendilerine ait bir veriye erişim imkanı sağlıyor mu?
2. Farklı kullanıcı seviyeleri var mı? Farklı seviyelere karar veren admin gibi kullanıcı türleri var mı?
3. Yöneticiler, yapılandırmak ve izlemek için aynı uygulamada yerleşik olan işlevleri kullanıyor mu?
4. Yetki yükseltmeye sebep olabilecek hangi url’ler kaynaklar vs tanımlanabilir?
5. Erişim düzeyi herhangi bir şekilde (cookie,html,POST url …) ile iletiliyor mu?

Öncelikle bunlar tespit edilip bunlara göre bir yol haritası çizilebilir.

 

Erişim kontrolleri üç kategoriye ayrılır: Dikey, Yatay ve context-dependent(içeriğe bağlı). Dikey demek belli içeriklere erişimin belli yetkilerce kısıtlandırılmasıdır. En güzel örneği kullanıcı-admin örneğidir.

Yatay erişim de aynı tür kullanıcıların aynı tür içerikleri kendi alanlarında incelemesini kapar. Örnek mail uygulaması kendi maillerimizi görmemize izin verirken başkasının maillerini görmemize izin vermez.

İçeriğe bağlı da örnek olarak kullanıcı aşama aşama görüntüleme yapıyorsa diğer aşamaları görmesinin engellenmesidir.

Access Control saldırılarında 3 tür vardır :

1. Dikey erişim : Örnek olarak normal bir kullanıcının admin işlevlerini gerçekleştirmesi
2. Yatay erişim : Bir kullanıcının başka bir kullanıcının yapabileceği işlevleri yapması bilgileri görmesi
3. Business Logic : Örnek olarak kullanın ödeme esnasında bir aşamayı atlaması vs. İş akışındaki hatalar.

Saldırılar Ve Dikkat Edilmesi Gerekenler :

 

Korunmayan Güvenlik Mekanizması 

Bazı durumlarda daha yüksek yetki seviyesine erişim sağlayan sayfalar URL ‘ler herhangi bir kontrol olmadan erişilebilir durumdadır. Örnek olarak sadece adminlerin https://wahh-app.com/admin/ böyle bir sayfayı görmesi güvenli değildir. Normal bir kullanıcı bu sayfaya gitmek istediğinde başka kontroller de yapılmalıdır. Bu urlyi bilen birisi doğrudan bu sayfaya erişememelidir.

URL ‘ler kullanıcıların ekranlarında görünür, proxy ile iletilir, browserda kaydedilir. Bu yüzden bilinmeyen veya güvenilir bir url diye birşey geçerli değildir.

Bazı durumlarda yönetici URL leri javascript içindeki koda kullanıcıyı tanımlayan bayraklarla gizlenmiş olabilir. Saldırgan bunları inceleyerek url’yi bulabilir.

 Direkt Erişim Yöntemleri

Bazı durumlarda Java API tarafından çağırılan kodların, browsera taşınması veya browserdan çağırılması sonucu doğrudan erişim elde edilebilir. Bunun dışında da bazı doğrudan erişimler URL de standart java isimlendirmesinin kullanılmasından kaynaklı gerçekleşebilir (getBalance, isExpired gibi)

Genellikle API çağrılarında güvenli iletişim ve erişim sağlanmalıdır. Ama bazen çağrılar herhangi bir input değişikliğinde güvenlik önlemi almadan işlemi yapıyor olabilir veya API çağrılarına erişim için bir güvenlik önlemine gerek olmuyor olabilir.

Örnek olarak http://wahh-app.com/public/securityCheck/getCurrentUserRoles bu linke ulaşırsak  getAllUserRoles, getAllRoles, getAllUsers, ve
getCurrentUserPermissions gibi değerleri de url de deneyip erişim yapmaya çalışabiliriz.

Bir diğer direkt erişim yönteminde de belli bir noktaya erişim için URL’de veya post requestde belli unique bir parametrenin gönderilmesiyle gerçekleşir. Örnek olarak https://wahh-app.com/ViewDocument.php?docid=1280149120 bu adresteki bilgiyi bu id ile ilişkilendirilmiş kişi görebilir. Ancak bazı durumlarda bu güvenli bir şekilde sağlanmıyor olabilir. Burada saldırgan hem ViewDocument.php sayfasını bilmeli hem de id’yi bilmelidir. Ama yine de güvenli olmaz çünkü bir şekilde loglara erişebilir ve oradan görebilir veya id sıralı şekildeyse tahmin edebilir.

TIP : Genellikle bu tarz açıklar genellikle server ile arayüzün farklı teknolojilerle geliştirildiği durumlarda gerçekleşir. Farklı teknolojiler arasında session odaklı bir güvenlik mekanizması oturmak zor olabilir.Ayrıca böyle id gibi verilere bağlı url’leri görmek için loglara erişim çok iyi bir kaynaktır. Loga erişen birisi ciddi anlamda hedefle ilgili bilgi edinebilir.

Multistage Functions

Birçok uygulamada işlemler farklı aşamalardan geçerek gerçekleşir. Örnek olarak kullanıcının kayıt olması aşaması adım adım gerçekleşir. Eğer geliştiriciler her aşamada, bir önceki aşamanın başarılı şekilde gerçekleştiğini varsayarsa saldırgan sonraki aşamalara atlayıp kendisini admin olarak ekleyebilir.

Bazen bu aşamalar gerçekleştirilirken bir önceki aşama doğrulanmış olduğu varsayılarak geçilen aşamalar arasında bir kontrol gerçekleştirilmez ve bir önceki aşamadan gelen veriler HTML içine gizlenmiş olabilir. Eğer son POST gönderiminde buna dikkat edilmezse saldırgan kolayca verileri değiştirip kendisine ait değil de başkasına ait bir hesaptan para transferi yapılmasını sağlayabilir.

Static Files

Çoğu uygulamada istekler dinamik dosyalara yönlendirilir ve dinamik sayfalar çalıştırılır. Bu sayfalara erişim güvenlik önlemleriyle olur ama örnek olarak kitap indirme siteisinde kullanıcı satın alma yaptıktan sonra, hiçbir kontrolün olmadığı bir url’den dosyayı indirebilir. Bu noktada o url’yi bilen saldırgan statik dosyayı doğrudan indirebilir. Eğer url’de tahmin edilebilir kitap kodu vs varsa bütün statik dosyaları indirebilir.

Platform Misconfiguration

Platform konfigürasyonları düzeyinde yapılan yanlışlıklar yetkisiz erişime sebep olabilir. Yetkilendirme aşamaları genellikle  :

• Request Yöntemi (GET,POST,HEAD …)
• URL path
• Kullanıcı Rolü

Dikkate alarak tasarlanır. Doğru HTTP metotları doğru URL’ler ile doğru şekilde işlenmelidir. Yoksa metotların değiştirilmesiyle zayıflıklar ortaya çıkabilir.

Örnek olarak bazı uygulamalar POST metodu alan bir url’ye GET metodu gönderildiğinde bunu doğru işlemeyebilir ve saldırganın yetkisiz işlem yapmasına sebep olabilir. Veya bazı uygulamalar HEAD metodunu işleyebilmek için önce GET metodunu işler ve daha sonra bunun başlıklarını döndürür. Eğer bir sayfa GET ve POST metotlarına göre kısıtlanmışsa bile HEAD isteği atmak saldırganın GET işlemini yapmasını sağlayabilir. POST bekleyen bir sayfaya HEAD isteği atmak da bu şekilde kırılmalara sebep olabilir.

Insecure Access Control Methods

Bazı uygulamalarda erişim kontrolü kullanıcının inputlarına veya saldırganın kontrol edebileceği parametrelere bağlı olabilir.

Parametre Tabanlı Erişim

Bu türlü güvenli olmayan erişim metotlarında kullanıcı login yaptığında, kullanıcın rolü belirlenir ve bu gizli HTML yoluyla veya cookie yoluyle veya url parametreleri yoluyla tüm sayfalara iletilir. Bu da kullanıcı tarafında olduğu için kolayca manipüle edilebilir. URL ile iletiliyorsa tespiti zor olsa bile bir şekilde farkedilip değiştirilerek yetkisiz erişime sebep olabilir

Referer Tabanlı Erişim

Bu türde güvensiz erişim için uygulama Header’lar arasında Referer kısmını kontrol ediyor olabilir. Örnek olarak admin yetkisindeki bir sayfaya erişmek için admin panelini sayfasını kaynak olarak Refererde kontrol ediyor olabilir. Bu şekilde bir varsayım kullanıcı kontrolünde referer parametresiyle bir zaafiyete dönüşebilir.

Location Tabanlı Erişim

Bazı durumlarda erişim için uygulamalar IP’den aldıkları coğrafi veriyi kullanır. Bu da VPN veya Proxy gibi veya Client-side verilerin değiştirilmesiyle exploit edilebilir.