Denetime başlamadan önce uygulama ve destekleyen altyapı hakkında bilgi toplamalıyız. Bu konularda yeterli bilgiyi toplamadan denetime başlarsak doğru planlama yapamama nedeniyle yüksek riskli alanlara yoğunlaşamama ve doğru denetim prosedürlerini uygulayamama, uygulamadaki mimari mantık hatalarını tespit edememe, uygulamanın açıkça görülmeyen yönetim veya diğer fonksiyonalitesini tahmin edememe sonuçlarıyla karşı karşıya kalırız.
Web uygulamasını denetlemeye başlamadan önce aşağıdaki konuları açıklığa kavuşturmamız gereklidir:- Uygulama ve altyapı teknolojileri (sunucu ve istemci taraflarında, web sunucusunda ve veritabanı sunucusu gibi backend sunucularda)
- Kullanılan güvenlik yöntemleri
- Uygulamanın sağladığı fonksiyonalite, iş akışları, kullanıcı rolleri
- Uygulama kodlarının bulunduğu dizinler, dizinlerin, uygulama sayfalarının ve kullanılan parametrelerin isimlendirme yaklaşımı
- Uygulama üzerinden ulaşılabilen diğer ağ servisleri (ör: e-posta gönderebilme, başka kaynaklardan bilgi çekebilme)
- Uygulamanın önünde yer alan tersine proxy ve yük dengeleyiciler (yukarıda açıklandığı nedenle denetim aktivitelerimizi ve sonuçlarını etkileyebilirler)
Web uygulama servisi pek çok katmanda çalışan servislerin bir arada ürettiği bir servis olup, her katman farklı saldırı vektörlerine maruz kalabilir. Bu nedenle uygulamayı destekleyen teknoloji mimarisinin anlaşılması da önemlidir. Bu konuya ilişkin izlenmesi gereken prosedürler yukarıda açıklanmıştır.
Hemen tüm güvenlik denetim prosedürlerinde olduğu gibi uygulama haritasının çıkarılmasında da manuel ve otomatik metotlar birbirlerini destekleyici biçimde kullanılmalıdır.
Otomatik Web Spidering: Bu yöntem tıpkı bir web sitesinin indirilmesinde izlenen yöntem gibi kendine verilen bir URL’i çağırarak gelen sayfanın içindeki link’leri ayırıp bu linkleri çağırma ve link’ler yoluyla ulaşılabilecek tüm sayfaları belirleme şeklinde çalışır. Bu şekilde ulaşılabilecek sayfalar ve sayfalar çağrılırken kullanılabilecek parametreler link’lerde hazır olarak bulunan URL’ler ve bunların içeriğindeki parametrelerle sınırlıdır.
Daha gelişmiş web uygulama örümcekleri HTML formlarını da analiz ederek form sahalarına (drop down list gibi) önceden belirlenmiş parametreleri ve rastgele değerleri atayarak birden fazla aşamalı taramaları yapmaya çalışır. Bazı araçlar istemci tarafında çalışmak üzere gönderilen JavaScript kodlarını analiz ederek kod içinden referans verilen URL’leri de tespit edebilir.
Bazı web sitelerinin “root” dizininde “robots.txt” adlı bir dosya bulunur. Bu dosya google gibi web örümceklerinin taramasının istenmediği dizinleri / URL’leri içerir. Denetim amacıyla bir web sitesini taradığımızda bu dosyanın içeriğindeki URL’ler elbette bizim için ilgi çekici olacaktır. Bu nedenle web uygulama denetimi için geliştirilmiş olan araçlardan bazıları bu dosyanın içeriğindeki URL’leri de tararlar.
Aşağıdaki ücretsiz araçlar otomatik tarama konusunda yardımcı olabilir:
- Paros
- Burp Suite’in içinde yer alan Burp Spider
- WebScarab
Ücretli web uygulama güvenlik denetim araçları web uygulamasına giriş kullanıcı kodu ve parolalarını saklayarak logout olmaları durumunda tekrar login olabilecek script’ler yaratabilmektedir. Otomatik tarama yönteminin kısıtlarından bazıları şunlardır:
- Sıra dışı navigasyon yöntemleri (örneğin JavaScript kodu ile otomatik yaratılan menüler aracılığıyla) yakalanamayabilir.
- Çok detaylı girdi kontrolü yapılan birden fazla aşamalı işlemler akıllı olmayan tarayıcı tarafından tamamlanamayacağından ileri aşamaları gerçekleştiren sayfalar haritalanamayabilir.
- Otomatik örümcekler sonsuz döngülere girmemek için genellikle URL’leri daha önce taradıkları sayfaları belirlemek için kullanır. Ancak form temelli navigasyonla POST metoduyla çağrılan sayfaların URL’i aynıyken gönderilen parametreler farklı olabileceğinden farklı içerikler dönebilir. Otomatik tarayıcı URL’i aynı olduğu için istek göndermeyi reddederse bu bilgi edinilemeyecektir.
- Üstteki maddeye tezat olarak bazı uygulamalar URL’ler içine sürekli değişen parametre değerleri koyabilir (zaman bilgisi, oturum takibi için kullanılan başka bir parametre gibi), bu durumda aynı içeriği döndürdüğü halde otomatik tarayıcı sonsuza kadar URL’ler farklı olduğu için her birini çağırabilir.
- Kullanıcı tanılama kullanıldığı durumlarda otomatik tarayıcı oturum cookie’lerini kullanacak veya logout olduğu durumlarda tekrar authenticate olabilecek fonksiyonaliteye sahip olabilir. Ancak bu durumda bile gereksiz yere logout linkini çağırma, uygulama tarafından her sayfa için ayrı token kullanma, ve hassas bir girdi alanına rastgele bilgi girme sonucu sıklıkla uygulama tarafından oturumun sonlandırılması gibi sorunlar yaşanabilir.
Ek olarak otomatik araçlarla taramanın bazı tehlikeleri de vardır. Tarama aracı uygulama fonksiyonalitesinin farkında olmayacağından istenmeyen değişiklik, kayıt yaratma ve silme işlemleri gerçekleştirebilir.
Kullanıcı Tarafından Yönlendirilen Tarama: Yukarıda sayılan araçlar tarama işlemini otomatikleştirebildikleri gibi manuel tarama sırasında da proxy olarak kullanılabilir ve hem otomatik hem de manuel tarama kayıtlarını tutabilir. Bu sayede uygulama dizin ve sayfalarını hiyerarşik biçimde görebilirsiniz, ayrıca bu sayfaları çağırmak için kullanılan istekleri ve bu isteklere gelen yanıtları da daha sonra izleyebilirsiniz. Otomatik tarama yöntemine göre manuel taramanın faydaları şunlardır:
- Navigasyon için sıra dışı veya kompleks yöntemler kullanıldığında kullanıcı bu işlemleri gerçekleştirebilecek ve proxy bu isteklerin ve yanıtların kaydını tutacaktır.
- Kullanıcı girdileri kendisi gireceğinden girdi kontrollerine uygun değerler girebilecek, dolayısıyla uygulamanın sonraki aşamalarına geçebilecektir.
- Kullanıcı normal biçimde kullanıcı tanılama yapacak ve yanlışlıkla logout olmayacaktır.
- “deleteUser.jsp” gibi tehlikeli fonksiyonaliteye sahip sayfalar gelen yanıt içinde yer alacağından proxy tarafından haritalanacak , ancak kullanıcı bu fonksiyonları çağırmama özgürlüğüne sahip olacaktır.
Manuel taramayı JavaScript ve cookie’lerin enable ve disable olduğu durumlar için ayrı ayrı yapmakta fayda vardır. Bu şekilde normalde ulaşılması öngörülmeyen kaynaklara ulaşılabilir.
Saklı İçeriğe Ulaşma: Bazı sunucular üzerlerinde normal uygulama adımları veya web sayfalarında linkleri bulunmayan çalıştırılabilir veya statik sayfalar veya dosyalar barındırabilir. Bunlar şu tür içerikten oluşabilir:
- Gerçek ortam uygulamaları veya eski uygulamaların yedekleri. Bu yedeklerin bulunduğu dosya isimleri çalıştırılabilir kod uzantısından başka uzantılara çevrilmiş olabilir ve bu şekilde kaynak koda ulaşma imkanı doğabilir (çünkü web sunucusu bu sayfalar talep edildiğinde içeriğini yorumlamadan gösterecektir).
- Web uygulamasının kökünden itibaren tüm yapısını barındıran yedek arşivleri. Böyle bir arşivin ele geçirilmesi durumunda tüm uygulama kodları ve uygulama mimarisi bir arada görülebilecektir.
- Yeni geliştirilmiş fonksiyonaliteyi barındıran ancak uygulamaya linklenmemiş dosyalar.
- Eski ama web sunucusundan silinmemiş çalıştırılabilir sayfalar. Bu sayfalarda yer alan açıklıklar halen saldırıya açıktır.
- Konfigürasyon ve “include” dosyaları. Bu dosyalar içinde veritabanı erişim kullanıcı kodu ve password’ü gibi hassas bilgiler yer alabilir.
- Gerçek uygulamanın derlendiği kaynak kodlar.
- Log dosyaları. Bu dosyalar içinde geçerli kullanıcı kodları, password’leri oturum cookie’leri, çağrılan URL’ler ve dolayısıyla parametreler gibi hassas bilgiler bulunabilir.
Saklı içeriğe ulaşmak için şu yöntemler kullanılabilir:
- Kaba kuvvet saldırısı
- Yayınlanan içerikten faydalanarak tahmin etme
- Hali hazırda linklenmemiş ancak arama motorları tarafından daha önceden belirlenmiş içerik
i. Kaba Kuvvet Saldırısı
Web sunucuya yönelik olarak muhtemel dizin ve dosyalarını içeren bir veritabanı kullanarak yüksek sayıda istek yapılır ve olumlu dönen sonuçlardan yola çıkarak gizli içeriğe ulaşılır. Uygulamanın yapısına göre istekler farklı temel dizinler için yapılabilir, örneğin uygulamanın dil seçim imkanı varsa ve Türkçe versiyonunda sayfalar “abc.sirket.com/tr/” dizini altında İngilizce versiyonunda “abc.sirket.com/en/” dizini altındaysa veritabanındaki sayfa ve dizinler bu ana dizinler üzerinden yapılabilir. Bu test otomasyona açık bir test olduğundan “nikto” veya onun veritabanını kullanan “wikto” bu amaçla kullanılabilir.
Burada dikkat edilmesi gereken konulardan biri HTTP statü kodlarının yanıtın olumlu veya olumsuz olması konusunda yanıltıcı olabileceğidir, yani uygulama veya web sunucusu hata mesajlarını 200 OK statü koduyla ancak bir hata açıklamasıyla gönderebilir. Bu durumda hata mesajlarını olumlu yanıtlardan ayırmak için aşağıdaki yöntemler kullanılabilir:
- Yanıtın içinde hata mesajından belli bir ifade aranarak hata mesajının ayırd edilmesi
- Mesaj uzunluğuna bakarak hata mesajları ile diğer mesajların birbirinden ayırd edilmesi
Burp Suite bu iki metodu da desteklemektedir. Burp bu konuda özel bir uygulama kullanılırken (örneğin “wikto”) proxy görevi görüp incelememize yardımcı olabilir.
HTTP statü kodları baz alınarak sonuçların incelenmesinde sadece 200 OK yanıtı değil diğerleri de istenen kaynağın bulunduğu ancak ulaşmak için belli şartların yerine gelmesi gerektiği anlamına gelebilir:
- 302 Found – Redirect eden bu mesaj bir login sayfasına yönlendiriyorsa kullanıcı tanılaması gereken bir kaynak istemiş olabiliriz. Eğer bir hata sayfasına yönlendiriliyorsak istek parametrelerimizi gözden geçirmemiz gerekebilir.
- 401 Unauthorized ya da 403 Forbidden – Tanılama gerektiği, ya da hangi kullanıcı haklarına sahip olunursa olunsun ulaşılamayacak bir kaynak bulunduğu anlamına gelebilir. Genellikle dizinler talep edildiğinde bu sonuçlar alınabilir, ancak dizinin varlığı anlaşılabilir.
- 500 Internal Server Error – Uygulamanın belli parametreleri beklediği anlamına gelebilir, daha detaylı inceleme yapmak gerekir.
Web Server Fonksiyonalitesi Dolayısıyla Bulunan Dosyaları Bulmak: Wikto ile yapılan istekler sadece uygulama sayfaları veya dizinleri değil, uygulamayı destekleyen web sunucusu, uygulama sunucusu, içerik yönetim uygulamalarına ait kaynakları da tespit edebilir. Bu kaynaklardaki açıklıklar da uygulama güvenliğini doğrudan etkileyeceğinden bunlar da testin parçası olmalıdır.
ii. Yayınlanan İçerikten Faydalanarak Tahmin Etme
Web tarama ve kaba kuvvet tarama sonuçlarından yola çıkarak daha doğru tahminler yapılabilir. Örneğin:
- Uygulama geliştiricilerin dosya isimlendirme yaklaşımlarından yola çıkarak görünmeyen dosyaların isimleri tahmin edilebilir. Örneğin AddDocument.jsp ve ViewDocument.jsp dosyaları varsa EditDocument.jsp dosyasıda olabilir.
- Tarihli veya belli bir sıra takip eden isimlendirmeler varsa görünmeyen diğer doküman isimleri de tahmin edilebilir. Örneğin AnnualReport2004.pdf varsa 2003 ve 2005 yıllarına ait raporlar da mevcut olabilir.
- HTML ve JavaScript kodları sunucu tarafında bulunabilecek gizli içerik açısından incelenmelidir. Örneğin comment edilmiş kod parçaları, disable edilmiş Submit elementi olan formlar, geliştiricinin eklediği notlar gibi.
- Tespit edilen dosya isimlerinin takıları değiştirilerek yedek veya eski kopyalara, kaynak kodlara ulaşılabilir. Örneğin txt, bak, src, inc ve old ekleri denenebilir. Yine ulaşılan dosya isimlerinin ekleri .java, .cs ekleriyle değiştirilip derlenen kaynak kodlarına ulaşılabilir.
- Editörler tarafından yaratılan geçici dosyalar araştırılabilir. Örneğin file.php varsa file.php~1 dosyası aranabilir.
- Bu testleri yapmak için de otomasyondan faydalanılabilir, örneğin Addxxx.jsp aramasından xxx bölümü fuzz edilebilir.
iii. Hali Hazırda Linklenmemiş Ancak Arama Motorları Tarafından Daha Önceden Belirlenmiş İçerik
Arama motorları ve web arşivleri hedef hakkında bilgi toplamak için kullanılabilir. Hedef kurumda çalışan teknik personelin forumlara bıraktıkları notlar gözden geçirilerek hedef uygulama platformu, fonksiyonalitesi hakkında internet forumlarından bilgi toplanabilir.
URL ve Parametre Bazlı Fonksiyonalite: Yukarıda bahsettiğimiz haritalama yöntemi WWW’in ilk ortaya çıktığı dönemdeki gibi sayfa bazlı bir yaklaşım uygulanmış olması durumunda etkili olabilir. Ancak bazı uygulamalar fonksiyonalite dallanmalarını tek bir dosya üzerinden gelen sorgu parametrelerine dayanarak yapmaktadır. Örneği tüm istekler “/bank.jsp” dosyasına yönelik olup POST sorgu parametreleri içinde “servlet=TransferFunds&method=confirmTransfer&...” bilgilerine dayanarak farklı fonksiyonalite sunabilir.
Bu durumda yukarıda izlediğimiz URL bazlı yöntemden parametre bazlı yönteme geçmemiz gerekecektir. Ayrıca URL ağacı gibi bize fikir veren görsel bir fonksiyonalite haritası olmayacağından fonksiyonalite dallanmalarını elle dokümante etmekte fayda vardır. Fonksiyonaliteyi anlarsak mimari güvenlik hatalarını bulmak, uygulama geliştiricilerin yaptığı varsayımları tahmin ederek bunlara karşı yöntemler geliştirmek olası olacaktır.
Bu iki uç arasındaki bir alanda hem URL hem de parametre bilgilerinin önemli olduğu alandır. Özellikle “hidden” parametreler (örneğin debug=false) uygulamanın işleyişini etkileyebilir. Bu nedenle parametrelerin uygulama fonksiyonalitesi üzerine etkisi incelenmeli ve gerekirse parametreler üzerinde de gizli içeriği ortaya çıkarmak için çalışma yapılmalıdır.
Sonraki Bölüm>>
