Web Uygulama Sızma Testleri İçin Kontrol Listeleri - IV

Checklist for Web App Pentesting - IV

5. Yetkilendirme (Authorization) Testleri

5.1 Yetki Artırımı (Privilege Escalation)

• Yönetici yetkisi “admin=yes”, “true”, “1” gibi bir değişken (gizli bir alanda da olabilir); bu tür değişkenlerin varlığının test edilmesi gerekir.
• POST yada GET istekleri içinde kullanıcı ismi de parametre olarak gönderiliyor ise, bu isim yerine “admin” yada “yonetici” gibi değerlerin yerleştirilip test edilmesi gerekmektedir. Ayrıca “userid” gibi parametreler için de 0 değeri kullanılıp yönetici yetkileri test edilebilir. Benzer şekilde POST isteğinde “Session=A239ffade359fe&role=3” gibi bir veri tespit edilmişse, “role=0” ile daha yetkili haklara sahip olunup olunamayacağı denenmelidir.
• Yatay yetki artırımı için isteklerdeki numerik alanlara dikkat etmek gerekir; bunlar kullanıcı sıra numaraları olabilir.

5.2 Yetki Dışı İşlem

• Yetkilendirme gerektiren fonksiyonlar mutlaka kullanıcı yetki sorgusuna tabi tutulduktan sonra kullanılmalıdır.

5.3 Dizin Gezinimi (Path Traversal)

Dizin gezinimi, herhangi bir GET ya da POST parametresinin bir işletim sistemi dosyasını doğrudan dosya yolu kullanılarak okunması sonucu ortaya çıkar. Örneğin bir POST talebinde “page” isimli bir parametre değeri “header.html” değeri alıyor ise ve ilgili uygulama kodu da bu dosyayı /dosya/yolu/header.html şeklinde çağırıyor ise, “page=../../../../../etc/passwd” gibi bir çağrı ile kullanıcı ve yetki atamaları elde edilmeye çalışılabilir. Özellikle uygulama sunucularının konfigürasyon dosyaları ilginç dosyalar arasındadır.

• Null karakteri (%SıfırSıfır) ile deneme yapmak unutulmamalı. Uygulama, pathin sonuna ".html" vb koyuyor olabilir, bunu atlatmak için.
• Bazen null karakteri soyulup çıkarılıyor olabilir, bir de enter (%0a) göndermekte yarar var.
• Nokta (.) ve slash (/) karakterleri filtreleniyor olabilir, bu durumda bu karakterlerin URL encode değerleri denenebilir. Karakter ve URL kodlama (encoding) karma şekilde de denenmelidir.
• Hata mesajları mutlaka sınanmalıdır. Uygulama, olmayan bir file için (../../../../../blablabla) için "path not found" mesajı verirken var olan bir adres için (../../../../../Program%20Files/) için "permission denied" mesajı veriyor olabilir.

5.4 Yetki Kontrolü Atlatma (Bypassing Authorization)

• Kullanıcı, yetkisi dışında bulunan sayfalara erişebilir mi?  Örneğin AddUser.jsp sayfası sadece admin erişimi için öngörülmekle beraber, standart kullanıcı bu bağlantıyı çağırarak ne tür işlemler yapabilir?
• Yetkimiz olmayan bir işlemin gerçekleştirilmesi mümkün müdür?  Örneğin banka internet sitesi cep telefonu numara değişikliğini yasaklamış olabilir. Fakat uygun bir istek oluşturarak, bu kısıtlama aşılabilir mi?
• Uygulamalar yetki bazlı erişim kontrolünü dokümanlara erişimi denetlemek için kullanıyor olabilirler. Örneğin bütün kullanıcılara ait PDF dosyaları aynı klasörde tutuluyor olabilir. Başka kullanıcıların bilgilerine erişim test edilebilir.
• İsteklerdeki parametreler manipüle edilerek yetkisi olunmayan bilgilere (örneğin oturum açılan kullanıcı dışında başka bir kullanıcının bilgilerine) erişim sağlanabilir.

HE:WA-C5 Authorization Attack Case Studies-1

Authorization Attack Case Studies

Horizontal Privilege Escalation

Request içinden header'ları çıkararak gerekli olup olmadıkları anlaşılır.

Nümerik alanlara dikkat. Bunlar birer sıra numarası olabilir, manipüle edilerek başkalarının hesap bilgilerine ulaşılabilir. Misal, bir alışveriş sitesinde account bilgileri görüntüleme / değiştirme için yapılacak talepte cookie içindeki shopperID parametresini 1 azaltarak talebi gönderelim, işte bir başkasının account bilgileri, üzerinde değişiklik yapabilecek şekilde karşımızda.

Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;

ShopperID=193096346;

Tek yaptığımız shopperID'yi 1 azaltmak. Ve sonuçta başka bir kullanıcının hesap bilgileri!

Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;

ShopperID=193096345;

Vertical Privilege Escalation

Dikey hak yükseltmeyle sonuçlanabilecek 4 senaryo var:

1. User-modifiable Roles
   

Örnek1:

Cookie: Auth=

897ec5aef2914fd153091011a4f0f1ca8e64f98c33a303eddfbb7ea29d217b34; -

563131=Roles=End User; K=HomePageHits=True;ASP.NET_SessionId=

dbii2555qecqfimijxzfaf55

Buradaki "Roles=End User" parametresi iç gıcıklayıcı, manipüle edelim: "Roles=admin", "Roles=administrator"...

Örnek2:

Cookie: ASPSESSIONIDAACAACDA=AJBIGAJCKHPMDFLLMKNFLFME; rC=X=

C910805903&Y=1133214680303; role=ee11cbb19052e40b07aac0ca060c23ee

Açıkça görülüyor ki "role=ee..." parametresi üzerine eğileceğiz burada da. Ama anlamlı bir şey gibi gözükmüyor. Farklı bir kullanıcı ile talebi tekrar oluşturalım:

Cookie: ASPSESSIONIDAACAACDA=KPCIGAJCGBODNLNMBIPBOAHI; rC=C=0&T=

1133214613838&V=1133214702185; role=ee11cbb19052e40b07aac0ca060c23ee

Görünen o ki "role" parametresinin değeri değişken değil, statik!

İpucu: Stringin 32 karakter olması, rakamlar ve f'ye kadar harflerden oluşması, bizi bunun standart bir 128-bit MD5 hash kodunun hexadecimal gösterimi olduğu düşüncesine sevketti. Sonra "admin", "administrator", "root"... denemeye başlıyoruz.

İyisi mi bu işi otomatize edelim, payload oluşturup aracımıza yaptıralım bu denemeleri (Burp Suite'in intruder aracını hatırla!).

1. Using Hijacked Accounts
   

Yatay hak yükseltme saldırısını hatırlayalım. Artarak giden bir ID belirleniyorsa en düşük ID numarasının sıradan kullanıcılardan daha çok yetkiye sahip bir admin yada developer hesabı olması olmayacak şey değil! "AuthID=3289" parametresi yerine "AuthID=1" gönderelim, bakalım ne sonuç verecek...

1. Using Other Security Flaws
   

SQL injection yada buffer overflow gibi açıklıklar, istediğimiz yetkilere sahip olmak için yeterli olacaktır.

4: Hak Yükseltme Denetimi (Privilege Escalation)

• Kullanıcının yetkisi dışında olan hak ve rollere erişimi, hak yönetim açıklığıdır.
• Hak yükseltme çeşitleri:
• Çalışanım, başka bir çalışan olan Mehmet olarak iş yapabiliyorum => Yatay hal yükseltme.
• Çalışanım, yöneticim olarak işlem yapabiliyorum => Dikey hak yükseltme.
• Yatay hak yükseltme örneği: MySpace’de URL sonundaki BID değerini değiştirerek kendinize ait olmayan duyuruları okuyabilirsiniz.
• Dikey hak yükseltme örneği: Bir mail list’te toplu mail atabilme yetkisi, gizli parametre ile client tarafında tutulmaktadır! Parametre değerini F’den T’ye çekerek admin yetkisine sahip olduk.
• URL’de oynama yaparak çok ciddi açıklıklar bulunabilir