PORTSWIGGER WEB SECURITY - BROKEN ACCESS CONTROL LAB ÇÖZÜMLERİ
Access Control (Erişim Kontrolü) veya Authorization (Yetkilendirme), talep edilen eylemlere veya erişim kaynaklarına, kimin veya neyin erişim sağlayabilmesine ilişkin kısıtlamaların uygulanmasıdır. Web uygulamaları bağlamında erişim kontrolü, kimlik doğrulama ve oturum yönetimine bağlıdır. Broken Access Control (bozuk erişim denetimleri) zafiyeti sık karşılaşılan ve kritik seviye değerlendirilen bir güvenlik zafiyetidir. Kullanıcı bir kaynağa erişebildiğinde veya erişemeyeceği varsayılan bir eylemi gerçekleştirebildiğinde ortaya çıkmaktadır.
Bu laboratuvarda bahsedilen Broken Access Control zafiyeti için tüm laboratuvar çözümleri ele alınmıştır. Keyifli okumalar..
Lab 1: Unprotected admin functionality
Web sayfalarında erişim denetiminin yapılmadığı durumlarda, kullanıcılar hassas verilere veya istenmeyen kaynaklara erişim sağlayabilir. Bu laboratuvarda herhangi bir kullanıcı kimlik doğrulamadan URL üzerinden admin paneline erişebilmektedir.
Web sayfasında /robots.txt dosyasına açık bir şekilde erişim sağlanabilmektedir. Sayfa üzerinde /robots.txt dosyası görüntülendiğinde bir /administrator-panel dizinin varlığı keşfedilecektir.
URL üzerinde /robots.txt dosyasını /administrator-panel ile değiştirip Admin paneline gidildiğinde aktif kullanıcıları görüntülemiş olacağız. Laboratuvarın çözümü için carlos kullanıcısını delete ediyoruz.
Görüldüğü gibi hiçbir denetleme söz konusu değildir ve her kullanıcı erişebilir, istediği gibi işlem gerçekleştirebilir.
Congratulations, you solved the lab!
Lab 2: Unprotected admin functionality with unpredictable URL
Admin paneline her zaman erişim sağlanamayabilir yada farklı bir dizin adıyla görüntülenebilir. Kullanıcı bunu sadece tahmin edebilir, deneme yanılma yoluyla bulabilir. Ancak bazen admin paneli, web sayfasının kaynak kodunda veya farklı bir yerde tanımlanmış olabileceği için, kullanıcı dizini keşfettikten sonra erişim sağlayabilir.
Bu web sayfasının kaynağında admin panelini içerisinden barındıran bir yer javascript kodu yer almaktadır. Sayfanın kaynağını inceleyip admin panelini görüntüleyeceğiz.
Laboratuvara erişim sağladıktan sonra web sayfasının kaynak kodunu inceleyelim. Kaynak kodunda bir javascript kodu yer almaktadır ve bu kod içerisinde /admin-9sz31j başlıklı bir dizin tanımlanmıştır. Herhangi bir denetleme söz konusu olmadığı için, URL üzerinden /admin-9sz31j dizinine gittiğimizde admin panelini görüntülemiş olacağız.
Laboratuvarın çözümü için Admin panelinde carlos kullanıcısını delete etmemiz yeterli olacaktır.
Congratulations, you solved the lab!
Lab 3: User role controlled by request parameter
Bazı uygulamalar, oturum açma sırasında kullanıcının erişim haklarını veya rolünü belirler ve ardından bu bilgileri bir cookie ya da doğrulama bilgisiyle kullanıcı tarafından kontrol edilebilen bir yerde depolar. Uygulama, gönderilen istek üzerinde bir erişim kontrolü yaparak buna göre bir karar verir ve yanıt döndürür. Örneğin admin paneline erişim sağlamak istendiğinde ve https://insecure-website.com/login/home.jsp?admin=true şeklinde bir URL ile istek gönderildiğinde güvensiz bir yaklaşım söz konusu olacaktır. Burada kullanıcı admin değerini false iken true yapıp panele erişim sağlayabilmektedir.
Url üzerinden admin dizinine gittiğimizde, Admin paneline yalnızca administrator olarak giriş yapanların erişim sağlayabileceğini bildiren bir hata mesajı almaktayız.
Laboratuvarda login olabileceğimiz bir hesap (wiener:peter) tanımlanmıştır. Bu hesap bilgisiyle login olup isteği burp ile yakalayalım. Gönderilen istek ekrandaki gibidir.
İsteği forward ettiğimizde karşımıza gelen ikinci bir istek göreceğiz. Bu istek üzerinde admin doğrulaması yapılmaktadır.
Admin parametresinin değerini true olarak değişip isteği forward ettiğimizde sayfaya admin paneli eklenecektir.
Admin paneline gidildiğinde tekrardan aynı hata mesajını almaktayız. Bunun sebebi her adımda bir admin doğrulamasının yapılıyor olmasıdır.
Sayfayı yenileyerek isteği burp ile yakalayalım ve Admin değerini true olarak değişelim.
İsteği forward ettiğimizde admin panelini görüntülemiş olacağız. Laboratuvarın çözümü için carlos kullanıcısını delete etmemiz gerekmektedir ancak bu bu aşamada da admin doğrulaması yapılmaktadır. carlos - Delete seçeneğine tıklayalım ve isteği burp ile yakalayalım.
Admin değerini true olarak değişip isteği forward ettiğimizde carlos kullanıcısının hesabını silmiş olacağız.
NOT: Bazı aşamalarda istek forward edildiğinde yeni bir doğrulama isteği karşımıza çıkmaktadır. Her doğrulama aşamasında Admin değerini true olarak değişiyoruz ve isteği forward ediyoruz.
Congratulations, you solved the lab!
Lab 4: User role can be modified in user profile
Bu web sayfasının /admin dizininde bir yönetici paneli vardır ve bu yönetici paneline yalnızca roleid:2 kimliği ile oturum açan kullanıcılar erişebilmektedir. Laboratuvarda login olabileceğimiz bir hesap (wiener:peter) tanımlanmıştır. Bu hesap aracılığıyla admin panelini görüntüleyip carlos hesabını sileceğiz.
wiener:peter bilgisiyle login olduktan sonra karşımıza bir mail güncelleme paneli çıkmaktadır. Random bir mail adresi tanımlayarak Update email butonuna tıklayalım ve isteği burp aracıyla yakalayalım.
İsteği repeaterda send ettiğimizde response üzerinden dört parametre eşliğinde doğrulama yapıldığı görülecektir. Bunlardan bir tanesi roleid parametresidir. wiener kullanıcı için bu parametrenin değeri 1'dir.
Email parametresine ek olarak roleid parametresini tanımlayalım ve bu parametre değerini 2 olarak değişelim.
İsteği send ettikten sonra sayfa üzerinde admin panelinin eklendiği görülecektir. Admin panelinin eklenmesinin sebebi roleid değerini değişerek farklı bir kimlik ile isteği göndermemizdir. Admin paneline gidip carlos kullanıcısını delete ettikten sonra laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
Lab 5: URL-based access control can be circumvented
Bazı uygulamalar, kullanıcının yetkisine bağlı olarak belirli URL’lere ve HTTP yöntemlerine erişimi kısıtlayarak denetim yapmaktadır. Uygulamanın sadece front-end tarafında erişim denetimleri gerçekleştirmesi yeterli değildir çünkü istek üzerinde orjinal URL adresini geçersiz kılmak için X-Original-URL ve X-Rewrite-URL parametreleri kullanılabilir. Bu parametreler web uygulaması tarafından destekleniyorsa, saldırgan erişim denetimini kolayca bypass edebilir.
Bu web sayfasında front-end tarafında erişim denetimi yapıldığı için harici bir kaynaktan admin dizinine erişim engellenmektedir. Back-end tarafı X-Original-URL parametresini desteklediği için bu parametreyi kullanarak admin paneline erişim sağlayacağız.
Url üzerinden admin dizinine gittiğimizde Admin paneline erişimin reddedildiğini gözlemleyelim.
Admin paneline yaptığımız istek bu şekildedir. İsteği repeatera gönderelim.
Burada ilk olarak X-Original-URL parametresinin desteklenip desteklenmediğini test edeceğiz. Bunun için isteğin en alt satırına X-Original-URL parametresini değeri /invalid olacak şekilde ekleyelim ve istek başlığını GET / HTTP/1.1 olarak değişelim. İsteği send ettiğimizde not found hatası alacağız. Bu hata bize mesajı bize X-Original-URL parametresinin uygulama tarafından desteklendiğini göstermektedir.
X-Original-URL parametresinin desteklendiğini tespit ettiğimize göre bu değeri /admin olarak değişip isteği send edelim. Bir hata mesajı almıyoruz ve artık admin paneline erişebilmekteyiz.
Laboratuvarın çözümü için carlos kullanıcısını delete etmemiz gerekmektedir. Bunun için X-Original-URL parametresini /admin/delete olarak değişip istek başlığına sileceğimiz kullanıcının adını tanımlayacağız. Bu şekilde isteği send ettiğimizde carlos kullanıcısını delete etmiş olacağız.
Congratulations, you solved the lab!
Lab 6: Method-based access control can be circumvented
Uygulamaların sadece front-end tarafında denetleme yapmasının yetersiz olduğundan daha önce bahsetmiştik ve orjinal URL adresini geçersiz kılan bir parametre aracılığıyla erişim denetimini bypass etmiştik. Bu laboratuvarda alternatif bir yöntem deneyeceğiz. Erişim denetimi HTTP yöntemlerine göre yapıldığı için bunu bir parametre ekleyerek değil gönderilen istek yöntemini değişerek yapacağız.
Laboratuvarda login olabileceğimiz iki hesap (administrator:admin / wiener:peter) tanımlanmıştır. İlk olarak administrator hesabıyla login olalım ve admin panelini görüntüleyelim. Karşımıza gelen panelde kullanıcıyı upgrade edelim ve isteği burp ile yakalayalım.
Gönderilen isteği incelediğimizde Admin rolüne geçiş yapıldığı görülecektir. Bu isteği repeatera gönderelim.
Şimdi gizli bir tarayıcı penceresi açarak wiener:peter hesap bilgisiyle login olalım. Burada, aynı anda iki hesabında aktif olması için gizli sekmeyi kullanıyoruz. Login olduktan sonra sayfayı yenileyelim ve isteği burp ile yakalayalım. Gönderilen istek ekrandaki gibidir. Bu isteği de repeatera gönderelim.
Her iki isteği de repeatera gönderdik. Burada bazı işlemler gerçekleştireceğiz ve sayfanın nasıl yanıtlar döndürdüğünü gözlemleyeceğiz. Wiener hesabı için gönderilen istekte yer alan session bilgisini, carlos kullanıcısını yükseltmek için gönderilen istekteki session bilgisiyle değişelim. İsteği send ettiğimizde “Unauthorized” hata mesajını almaktayız.
Gönderilen istek metodu POST’tur. Metodu POSTX olarak değişip isteği send ettiğimizde “Missing parameter ‘username’” hata mesajını almaktayız. İsteğe sağ tıklayarak ‘Change request method’ seçeneğini seçerek isteği GET formatına dönüştürelim.
İsteği GET formatında send edeceğiz ama öncesinde carlos olan username değerini wiener olarak değişiyoruz. İsteği gönderdikten sonra laboratuvarı çözmüş olacağız.
NOT: Kullanıcı yükseltme ekranı sadece administrator hesabında mevcuttur. Biz wiener kullanıcısının session bilgisini, kullanıcı yükseltme aşamasında gönderilen istek üzerindeki session bilgisiyle değiştirdik. Bazı hatalar aldık ve bu hataları da istek formatını değiştirerek bypass ettik. Tüm bu işlemlerin sonucunda carlos için yapılan kullanıcı yükseltme işlemini wiener kullanıcısı için yapmış olduk.
Congratulations, you solved the lab!
Lab 7: User ID controlled by request parameter
Bir kullanıcının kendi hesabı yerine bir başkasının hesabına erişim sağlaması oldukça tehlikeli bir zafiyet oluşturmaktadır. Web uygulamaları kullanıcıları doğrulamak için user id parametreleri kullandığında ve yeterince denetlenmediğinde bir zafiyet meydana gelmektedir. Örneğin bir kullanıcı kendi hesabına erişim sağladığında https://insecure-website.com/myaccount?id=29 şeklinde bir istek gerçekleştiyse 29. kullanıcı olarak erişim sağlamıştır. Bu 29 değeri 28 olarak değiştirilip istek gönderildiğinde eğer 28. kullanıcının hesabına erişim sağlanıyorsa burada ciddi bir zafiyet söz konusu olmaktadır.
Bu laboratuvarda bahsedilen türde bir zafiyet mevcuttur. Bu zafiyeti kullanarak parolasını bilmediğimiz carlos kullanıcısının hesabına erişim sağlayacağız.
Tanımlanmış wiener:peter hesap bilgisiyle login olduğumuzda karşımıza bir mail güncelleme paneli çıkmaktadır. Ayrıca wiener kullanıcısına ait bir API KEY bilgisi verilmektedir.
Login sonrası sayfa üzerinde yer alan my-account bağlantısına tıklayıp gönderilen isteği Burp ile incelediğimizde id değeri wiener olarak bir istek gönderildiği görülecektir.
id değerini carlos olarak değişip isteği forward ettiğimizde carlos kullanıcısı olarak oturum açmış olacağız.
Uygulamada kullanıcıya ait bir erişim denetimi söz konusu olmadığı için parolasını bilmediğimiz carlos kullanıcısının hesabına erişim sağlamış olduk.
carlos kullanıcısı için verilen API KEY’i Submit solution sekmesinden doğrulattıktan sonra laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
Lab 8: User ID controlled by request parameter, with unpredictable user IDs
Bazı uygulamalar, kullanıcıları tanımlamak adına artan bir tamsayı yerine benzersiz tanımlayıcı değerleri (GUID’ler) kullanmaktadır. Örneğin bir kullanıcı 20 id’si ile değilde abcd580s-54wr-56rt-3spl-ke4tew67hn24 gibi bir GUID doğrulanabilir. Saldırganın böyle bir durumda başka bir kullanıcının tanımlayıcısını tahmin etmesi söz konusu olmadığı için başka kullanıcıların GUID değerini elde etmesi gerekmektedir.
Bu web sayfası kullanıcıları GUID değerleriyle tanımlamaktadır. Burp Suite aracıyla inceleme yapıldığı zaman wiener kullanıcısının GUID değeri görülmektedir. wiener kullanıcısının GUID değerine carlos kullanıcısının değerini GUID değerini tanımlayarak carlos kullanıcısının hesabına erişim sağlayacağız.
Sayfa üzerinde carlos tarafından oluşturulmuş bir blog yazısı mevcuttur.
Blog yazısını görüntüledikten sonra carlos bağlantısına tıkladığımız takdirde URL üzerinde userId parametresi ile bir tanımlayıcı GUID değeri görülecektir. Bu GUID değerini kopyalayalım. (daha sonra bu değeri kullanacağız)
Kullanıcılar GUID değerleriyle doğrulanmaktadır. Şimdi bize tanımlanan wiener:peter hesap bilgisi ile login olalım. Hesaba eriştikten sonra kullanıcıya ait bir API KEY bilgisi verilmektedir.
Login sonrası sayfa üzerinde yer alan my-account bağlantısına tıklayıp gönderilen isteği Burp ile incelediğimizde, id parametresinin 6bc0e6f2-d6ab-4dd1-a019–0f81a34b0964 şeklinde bir GUID değeriyle bir istek gönderildiği görülecektir.
carlos kullanıcısına ait kopyaladığımız GUID değerini istek üzerinde id parametresine tanımlayalım.
İsteği send ettiğimizde carlos kullanıcısının hesabına erişmiş ve API KEY bilgisini elde etmiş olacağız.
carlos kullanıcısı elde ettiğimiz API KEY’i Submit solution sekmesinden doğrulattıktan sonra laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
Lab 9: User ID controlled by request parameter with data leakage in redirect
Uygulamalar, bazı durumlarda kullanıcının kaynağa erişmesine izin verilmediğini algılar ve kullanıcıya oturum açma sayfasına yönlendirir. Fakat bu yönlendirilme sürecinde bazı hassas veriler kullanıcı tarafından görülebilir ve saldırı gerçekleştirilebilir.
Bu laboratuvarda, erişmek istediğimiz bir kaynağa izin verilmediği zaman oturum açma sayfasına yönlendirilmekteyiz. carlos kullanıcısına ait API KEY bilgisini elde etmemiz gerekmektedir. Bunu da Burp Suite aracıyla yönlendirilme isteğinin yanıtını inceleyerek tespit edeceğiz.
Tanımlanmış wiener:peter hesap bilgisiyle login olduğumuzda karşımıza bir mail güncelleme paneli çıkmaktadır. Ayrıca wiener kullanıcısına ait bir API KEY bilgisi verilmektedir.
Login sonrası sayfa üzerinde yer alan my-account bağlantısına tıklayıp gönderilen isteği Burp ile incelediğimizde id değeri wiener olarak bir istek gönderildiği görülecektir.
id değerini carlos olarak değişip isteği forward ettiğimizde uygulama tarafından oturum açma sayfasına yönlendirilmekteyiz.
Tekrardan my-account bağlantısına tıklayıp isteği burp aracıyla yakalayalım. Az önce yaptığımız işlemin repeaterda gerçekleştireceğiz. id değerini carlos olarak değişip isteği send ettiğimizde yanıtta API KEY bilgisini bize döndürecektir. carlos kullanıcısına ait bu API KEY’i Submit solution sekmesinden doğrulattıktan sonra laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
Lab 10: User ID controlled by request parameter with password disclosure
Bir kullanıcının kendi hesabı yerine bir başkasının hesabına erişim sağlamasının oldukça tehlikeli bir zafiyet oluşturduğundan bahsetmiştik. Web uygulamaları kullanıcıları doğrulamak için user id parametreleri kullandığında ve yeterince denetlenmediğinde ciddi bir zafiyet meydana gelmektedir. Örneğin bir kullanıcı kendi hesabına erişim sağladığında https://insecure-website.com/myaccount?id=wiener şeklinde bir istek gerçekleştiyse wiener kullanıcı olarak erişim sağlanmıştır. Bu wiener değeri administrator olarak değiştirilip istek gönderildiğinde eğer administrator kullanıcısının hesabına erişim sağlanıyorsa burada ciddi bir zafiyet söz konusu olmaktadır.
Bu laboratuvarda wiener:peter hesabını kullanarak administrator kullanıcısının parolasını elde edeceğiz.
Tanımlanmış wiener:peter hesap bilgisiyle login olduğumuzda karşımıza email ve password güncelleyebileceğimiz bir panel çıkmaktadır.
Login sonrası sayfa üzerinde yer alan my-account bağlantısına tıklayıp gönderilen isteği Burp ile incelediğimizde id değeri wiener olarak bir istek gönderildiği görülecektir. İsteği repeatera gönderelim.
id değerini administrator olarak değişip isteği send ettiğimizde yanıtta bize administrator kullanıcısına ait password bilgisi döndürülecektir.
administrator kullanıcısına ait bu parola bilgisiyle login olduktan sonra laboratuvarı çözmüş olacağız.
NOT: İsteği repeatera göndermemizin sebebi administrator kullanıcısına ait parola değerini görmekti. id değerini administrator olarak değiştirip isteği forward etseydik administrator hesabına direkt (oturum açmadan) erişim sağlamış olacaktık.
Congratulations, you solved the lab!
Lab 11: Insecure direct object references
Insecure direct object references (IDOR) zafiyeti, Broken Access Control güvenlik zafiyetlerinin bir alt kategorisi olarak nitelendirilmektedir. Saldırgan, uygulama üzerindeki bir nesneye (dosya, hesap vb.) doğrudan erişim sağladığında IDOR zafiyeti ortaya çıkmaktadır. Erişim kontrollerinin bypass edilmesine neden olabilecek birçok uygulama hatasının sadece bir örneği olmasına rağmen oldukça popüler ve kritik bir zafiyettir.
IDOR zafiyeti, genellikle sunucu tarafındaki hassas dosyalara (saldırganın işine yarar nitelikteki dosyalar) erişim sağlandığında meydana gelmektedir. Örneğin bir web sayfası, sohbet mesajı dökümlerini sunucuda kaydediyor olabilir. Eğer bir erişim denetimi söz konusu değilse, kullanıcıların https://insecure-website.com/static/12144.txt şeklinde bir URL aracılığıyla txt dosyası içinde barındırılan sohbet mesajlarını elde etmesine neden olabilir. Saldırgan txt dosyasını değiştirerek, istediği dosyayı görüntülemek adına bir istekte bulunabilir ve bu sayede birçok veriyi (kullanıcı kimlik bilgileri, ilgili dökümler ve erişmesi istenmeyecek birçok dosya) elde edebilir.
Bu laboratuvarda, bir erişim denetimi yapılmadığı için kullanıcı istediği txt dosyasına erişim sağlamakta ve görüntüleyebilmektedir.
İlk olarak laba erişim sağlayalım. Bir ‘Live chat’ sekmesinin mevcut olduğunu göreceğiz.
Live chat sayfasında canlı sohbet yapılabildiği gibi transkripti görüntüleyerek daha önceki mesajlar hakkında bilgi sahibi olabiliyoruz. View transcript butonuna tıklayarak gönderilen isteğe bir göz atalım.
İsteği ardı ardına forward edersek son aşamada 2.txt adlı bir dosyanın indirilmesine yönelik bir istek karşımıza çıkacaktır. Bu isteği de forward edersek 2.txt dosyasını indirebileceğimiz yada görüntüleyebileceğimiz bir panel ekrana gelecektir. Fakat IDOR zafiyetinin tespiti için farklı bir dosyayı görüntülemeye çalışacağız.
2.txt dosyasını 1.txt olarak değişip isteği forward edelim. Bir erişim denetimi söz konusu olmadığı için başarılı olacağız.
İsteği forward ettikten sonra ekrana gelen panelden dosyayı görüntüleme başlığını seçelim. 1.txt dosyasını görüntülediğimizde canlı sohbette yer alan bir takım sohbet mesajlarını ve bunların arasında carlos kullanıcısına ait bir parola bilgisinin yer aldığını tespi edeceğiz. carlos kullanıcısına ait bu parola bilgisiyle login olduktan sonra laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
Lab 12: Multi-step process with no access control on one step
Birçok web uygulaması, gerçekleştirilmesi önemli olan bazı eylemleri birkaç adım üzerinden uygulamaktadır. Bunu da kullanıcının sağlamak istediği erişimi denetlemek ve gözden geçirmek adına yapmaktadır. Ancak bazen, bu adımlardan herhangi birisinde bir açık söz konusu olabilir. Örneğin ilk adımlar üzerinde sıkı bir erişim denetlemesi yapan web uygulaması son adımı gözden kaçırıyor yada yeterince denetlemiyor olabilir. Bir web uygulamasının erişim denetleme aşamasında birinci ve ikinci adımları doğru şekilde kontrol ettiğini ancak üçüncü adımı eksik kontrol ettiğini varsayalım. Bu durumda saldırgan ilk iki adımı tamamladıktan sonra bir saldırı gerçekleştirebilir.
Bu web sayfasında admin paneline erişim sağlayabilmek için birkaç adımdan oluşan kontrol sürecini tamamlamak gerekmektedir. Ancak kontrolün yeterince yapılmadığı adımda saldırı gerçekleştirebiliriz.
Laboratuvarda login olabileceğimiz iki hesap (administrator:admin / wiener:peter) tanımlanmıştır. İlk olarak administrator hesabıyla login olalım ve admin panelini görüntüleyelim.
Admin panelinde kullanıcıyı yükseltmek istediğimizde (ilk adım) bize “Are you sure?” şeklinde bir soru (ikinci adım) yöneltilmektedir. Yes butonuna tıklayalım ve isteği burp ile yakalayalım.
Gönderilen isteği incelediğimizde üç parametre üzerinden Admin rolüne geçiş yapıldığı görülecektir. Bu isteği repeatera gönderelim.
Şimdi gizli bir tarayıcı penceresi açarak wiener:peter hesap bilgisiyle login olalım. Burada, aynı anda iki hesabında aktif olması için gizli sekmeyi kullanıyoruz. Login olduktan sonra sayfayı yenileyelim ve isteği burp ile yakalayalım. Gönderilen istek ekrandaki gibidir. Bu istekte yer alan session bilgisini diğer istekte ki session için tanımlayacağız. Bu nedenle session bilgisini kopyalayalım.
Şimdi repeatera gönderdiğimiz istek üzerinde bazı işlemler gerçekleştireceğiz ve sayfanın nasıl yanıtlar döndürdüğünü gözlemleyeceğiz. Wiener hesabı için gönderilen istekte yer alan (kopyaladığımız) session bilgisini, carlos kullanıcısını yükseltmek için gönderilen istekteki (repeatera gönderilen istek) session bilgisiyle değişelim. username parametresini de wiener olarak değişip isteği send ettiğimizde herhangi bir hata mesajı almayacağız ve laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
NOT: Bu laboratuvarda ilk adım kullanıcı yükseltme aşamasıdır. İkinci adım bize ‘Are you sure?’ şeklinde bir sorunun yöneltildiği aşamadır. Son aşama ise session bilgilerini değişerek kullanıcıyı yükseltmek için yaptığımız saldırı aşamasıdır.
Kullanıcı yükseltme ekranı sadece administrator hesabında mevcuttur. Biz wiener kullanıcısının session bilgisini, kullanıcı yükseltme aşamasında gönderilen istek üzerindeki session bilgisiyle değiştirdik ve hiçbir hata almadık. Bu işlemlerin sonucunda carlos için yapılan kullanıcı yükseltme işlemini wiener kullanıcısı için yapmış olduk.
Lab 13: Referer-based access control
Bazı web uygulamaları, erişim denetimlerini HTTP isteklerinde yer alan Referer parametresi üzerinden yapmaktadır. Referer bilgisi, genellikle bir isteğin başlatıldığı sayfayı belirtir ve tarayıcılar tarafından isteklere eklenmektedir. Örneğin, bir web uygulamasının /admin dizinindeki yönetici paneli için sıkı bir erişim denetimi yaptığını fakat /admin/deleteUser gibi alt dizinler için sadece Referer başlığını denetlediğini varsayalım. Referer başlığı /admin dizinini içeriyorsa gönderilen isteğe izin verilir. Bu durumda, Referer başlığı saldırgan tarafından kontrol edilebilir hale gelir. Bunun sonucunda saldırgan alt dizinlere istek gönderebilir ve çeşitli yöntemlerle yetkisiz erişim sağlayabilir.
Bu web sayfası, Referer başlığı üzerinden yönetici işlevlerine olan erişimi kontrol etmektedir. Bu bilgiler dahilinde laboratuvarı çözeceğiz.
Laboratuvarda login olabileceğimiz iki hesap (administrator:admin / wiener:peter) tanımlanmıştır. İlk olarak administrator hesabıyla login olalım ve admin panelini görüntüleyelim. Karşımıza gelen panelde kullanıcıyı upgrade edelim ve isteği burp ile yakalayalım.
Gönderilen isteği incelediğimizde bir GET isteği ile Admin rolüne geçişin yapıldığı görülecektir. Ayrıca Referer başlığında admin dizininin tanımlandığını gözlemliyoruz. Daha sonra işlem yapacağımız için bu isteği repeatera gönderelim.
Şimdi gizli bir tarayıcı penceresi açarak wiener:peter hesap bilgisiyle login olalım. Burada, aynı anda iki hesabında aktif olması için gizli sekmeyi kullanıyoruz. Login olduktan sonra sayfayı yenileyelim ve isteği burp ile yakalayalım. Gönderilen istek ekrandaki gibidir. Bu istekte yer alan session bilgisini diğer istekte ki session için tanımlayacağız. Bu nedenle session bilgisini kopyalayalım.
Şimdi repeatera gönderdiğimiz istek üzerinde bazı işlemler gerçekleştireceğiz ve sayfanın nasıl yanıtlar döndürdüğünü gözlemleyeceğiz. Wiener hesabı için gönderilen istekte yer alan (kopyaladığımız) session bilgisini, carlos kullanıcısını yükseltmek için gönderilen istekteki (repeatera gönderilen istek) session bilgisiyle değişelim. Şimdi ilk olarak isteği send edelim ve ardından follow redirection seçeneğine tıklayalım. Yönlendirilen yeni istek ekrandaki gibi olmaktadır. Bu istekte, üst başlıkta yer alan bilgiler eksik olduğu için, yanıtta yetkimizin olmadığına yönelik bir hata mesajı almaktayız.
carlos kullanıcısını yükseltmek için tekrar bir istekte bulunalım ve isteği repeatera gönderelim. Kopyaladığımız session bilgisini burada tekrar tanımlayalım ve username değerini carlos olarak değişelim. İsteği send ettiğimizde herhangi bir hata mesajı almayacağız ve son laboratuvarıda bu şekilde çözmüş olacağız.
Congratulations, you solved the lab!
NOT: Kullanıcı yükseltme ekranı sadece administrator hesabında mevcuttur. Biz wiener kullanıcısının session bilgisini, kullanıcı yükseltme aşamasında gönderilen istek üzerindeki session bilgisiyle değiştirdik. İstek başlığında yer alan bilgileri dahil etmeden bir istek gönderince unauthorized hatası alacağımızı gördük ve başlık üzerinden onay verildiğini doğruladık. Ardından istek başlığındaki bilgileri kullanarak ve username değerinide wiener olarak değişerek istek gönderdik. Tüm bu işlemlerin sonucunda carlos için yapılan kullanıcı yükseltme işlemini wiener kullanıcısı için yapmış olduk.
Çözümlemesi çok zor olmasa da aktarımı biraz karışık bir laboratuvar, umarım anlatabilmişimdir :)
