Lab: Method-based access control can be circumvented

Lab: Method-based access control can be circumvented

Bu yazıda PortSwigger Web Security Academy’deki bir laboratuvarın çözümünü ele alıyorum. Laboratuvarın temel konusu, uygulamanın erişim kontrolünü yalnızca belirli HTTP metodlarına göre kısıtlaması ve bunun nasıl kötüye kullanılabileceği.

Lab açıklaması özetle şöyle:

This lab implements access controls based partly on the HTTP method of requests. You can familiarize yourself with the admin panel by logging in using the credentials administrator:admin . To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.

Önce admin panelini anlamak için administrator:admin ile giriş yapıyoruz. Ardından wiener:peter hesabına geçip metod bazlı kontrol hatasını kullanarak kendi rolümüzü yükseltmemiz gerekiyor.

Uygulamada kullanıcı rollerinin değiştirilebildiği bir admin paneli bulunuyor ve bu işlemler /admin-roles endpoint’i üzerinden gerçekleşiyor. Sorun şu ki, uygulama bu endpoint’e erişimi yalnızca HTTP metoduna bakarak kontrol ediyor. Yani doğru HTTP metoduyla gönderilen bir istek, kullanıcı admin olmasa bile kabul edilebiliyor. Bu zafiyeti kullanarak normal kullanıcı hesabımızı admin seviyesine yükseltebiliyoruz.

Bu isteği Burp Repeater’a gönderip saklıyoruz. Buradan anladığımız şey şu: Rol değiştirme işlemi, POST metoduyla /admin-roles endpoint’ine yapılan bir istek üzerinden çalışıyor.Sonraki adımda, bu işlemi admin olmayan bir kullanıcıyla deniyoruz. Yeni bir gizli/özel tarayıcı penceresi açarak laboratuvarın verdiği normal kullanıcı bilgileriyle (örneğin wiener:peter ) giriş yapıyoruz. Bu oturumun session cookie değerini alıp Repeater’daki istekte admin cookie’si yerine koyuyoruz:,

Bu beklediğimiz bir durum: Normal bir kullanıcı, adminlere özel bir işlemi POST metoduyla çağırdığında yetki kontrolü devreye giriyor ve access control düzgün çalışıyor gibi görünüyor. Buradaki kritik nokta, yetki kontrolünün sadece POST metoduna mı bağlı olduğunu test etmek. Bunun için isteğin ilk satırını değiştiriyoruz. Örneğin, POST yerine geçersiz bir metod adı yazıyoruz:

Artık iki önemli davranışı görmüş oluyoruz:

- POST ile gönderdiğimizde: 401 Unauthorized

POST ile gönderdiğimizde: 401 Unauthorized

- POSTX (geçersiz başka bir metod adı) ile gönderdiğimizde: "Missing parameter 'username'"

Bu fark şunu gösteriyor:

Yetki kontrolü yalnızca request.method == "POST" durumunda çalışıyor. POST dışındaki metodlarda (örneğin POSTX, GET vb.) aynı kontrol uygulanmıyor.

Burp Repeater’da bu sefer isteği GET metoduna dönüştürüyoruz. Bunu manuel olarak yapabileceğimiz gibi, Repeater üzerinde sağ tıklayıp “Change request method” seçeneğini kullanarak da otomatik dönüştürebiliriz. Dönüştürüldükten sonra istek şu şekle geliyor:

Bu isteği normal kullanıcının oturumu ile gönderdiğimizde, uygulama bu sefer yetki hatası döndürmek yerine isteği kabul ediyor ve işlemi başarıyla gerçekleştiriyor.

Böylece şu sonucu elde etmiş oluyoruz:

- POST + normal kullanıcı → Unauthorized

- GET + normal kullanıcı → İşlem başarılı

Bu, yetki kontrolünün sadece POST metoduna uygulanması ve GET gibi diğer metodlarda tamamen atlanması nedeniyle oluşan klasik bir access control zafiyetidir.

ab senaryosuna göre asıl amacımız genelde hedef kullanıcıyı değil, kendi hesabımızı yükseltmek. Bu nedenle username parametresini değiştiriyoruz:

Bu isteği gönderdiğimizde, normal kullanıcı hesabı admin haklarına yükseltilmiş oluyor. Ardından tarayıcıya dönüp sayfayı yenilediğimizde, artık admin paneline erişebildiğimizi ve lab’ın bizden istediği son işlemi gerçekleştirebildiğimizi görüyoruz.

Bu lab aslında çok basit bir gerçeği gösteriyor: yetki kontrolünü sadece bir HTTP metoduna bağlamak ciddi bir güvenlik açığıdır. Sunucu sadece POST’u kontrol ettiğinde, biz de doğal olarak diğer metodları deniyoruz ve çoğu zaman bu kontroller tamamen atlanabiliyor.

Güvenli bir uygulamada erişim kontrolü, metoddan bağımsız olarak aynı şekilde uygulanmalı. Özellikle /admin-roles gibi kritik endpoint’lerin GET, POST, PUT fark etmeksizin aynı sıkılıkta doğrulanması gerekiyor.

Pentest yaparken sadece POST’u değil, GET, PUT, DELETE hatta geçersiz metodları bile denemek şart. Bu lab, method-based access control zafiyetinin ne kadar kolay istismar edilebildiğini pratik şekilde gösteriyor.🌸