|
Web uygulamalarında bulunan güvenlik zafiyetlerinin taşıdığı riskler, bu açıklıkları, günümüz siber güvenlik anlayışının en önemli konularından biri (belki de en önemlisi) haline getirmiştir. İstatistiklere göre her 10 web sitesinden 9’unda ciddi seviyede bir açıklığın olmasının yanında siber saldırıların %60’ından fazlasının web teknolojilerine yönelik gerçekleştirilmesi bu önemin açık bir nedenidir [1].
İki bölümden oluşacak bu yazının ilk bölümü, otomatik web zafiyet tarayıcılarının genellikle ilk fazı olan girdi noktası bulma algoritmaları ve etkinlikleri üzerine olacaktır.
Web uygulamalarında bulunan açıklıklar; SQL enjeksiyonu, XSS, yetersiz hata yönetimi, CSRF gibi sadece yazılımsal veya standartlarda bulunan dizayn tabanlı hatalar olmayıp, yönetimsel ve mantıksal hataları da içermektedir.
Bu yazılımlardaki güvenlik problemlerinin bulunması, düzeltilmelerindeki en önemli adımdır. Bu adımı gerçeklemek adına üç önemli yöntem; elle yapılan testler, web uygulama açıklık tarayıcıları, statik/dinamik kod analiz araçlarıdır. Ancak bilinmelidir ki, yazılımlarda bulunan risk seviyesi yüksek zafiyetlerin açığa çıkarılması sadece tek bir yöntemle mümkün veya uygulanabilir değildir. Bu nedenle kapsamlı bir risk haritası için her üç yönetimin de elden geldiğince uygulanması gerekir.
Otomatik web açıklık tarayıcılarının (WAT) kapsayıcı ve zaman açısından etkin olmaları, web güvenlik risk haritasının çıkarılmasında çok önemlidir. WAT çalışma süreçlerinin birçok safhası vardır ama işleyişleri genel olarak ikiye ayrılır; girdi keşfi ve zafiyet analizi.
Girdi noktaları web uygulamalarının çalışma prensibinin en önemli parçalarıdır. Ne de olsa, interaktiflik bu etkileşim üzerine kurulmuştur; etki ve tepki, istek ve cevap. İşte bu nedenle birçok güvenlik problemi de bu modellemede girdi denetiminin yetersiz kalmasından kaynaklanmaktadır. Web uygulamalarında girdi noktaları HTTP protokolündeki istek mesajlarının her parçasından oluşabildiği gibi (URL, HTTP başlıkları, HTTP gövdesi, v.b.) farklı protokollerdeki (RMI, JNLP v.b.) veya alt-protokollerdeki (Flash Remoting, SOAP, v.b.) parçalar da bu kategoriye girmektedir.
Girdi keşfi sırasında WAT’lar, mümkün olabildiğince fazla girdi noktası bulmaya çalışırlar. Çünkü bu fazda ne kadar fazla girdi noktası bulunursa ikinci fazda (bu fazlar her zaman art arda işlemek zorunda değildir) bir o kadar zafiyet bulma şansı doğacaktır. WAT’lar genellikle “berbatometre” olarak adlandırılmaktadırlar; yani üzerinde analiz yaptıkları uygulamanın ne kadar kötü olduğunu söyleme yetisi. Çünkü WAT'ların bir uygulamanın güvenlik açısından ne kadar kaliteli yazıldığı sonucuna varabilmeleri, risk seviyesi yüksek açıkların oranı ve bu araçların kabiliyetleri düşünüldüğünde (en azından şimdilik) mümkün değildir. Örnek olarak; yapısal bir problem olan XSS açıklıklarını bulma konusunda iyi bir iş yapan WAT’lar, yetersiz yetkilendirme konusunda sınıfta kalmaktadırlar. Başarılı oldukları iş olan yapısal problemleri bulmak, dolayısıyla ilk faz (girdi noktası keşfi) yani saldırı yüzeyini arttırmak bu açıdan WAT’lar için hayati önem taşır.
2002 ve 2003 yıllarından başlamak suretiyle özellikle istemci tarafındaki teknoloji karmaşıklığının artması (Web 2.0) ile beraber ilk fazın kapsamlı olarak gerçeklenmesi büyük bir problem olarak karşımıza çıkmaktadır. Klasik HTML yapılarının (form, a, frame, iframe HTML elementleri) yanında ağır Javascript ve Flash gibi diğer standartların da kullanılması yaygınlaştıkça WAT statik parserların web sayfalarındaki girdi noktalarını bulmaları oldukça zorlaşmıştır. Bu konuda örnek vermek gerekirse, Web 1.0 veya 1.5 olarak adlandırılan web sayfalarında
…
<a href=”/satinal.do?deger=5&d=3453667&tür=cd”>satın al</a>
…
türünde yapılar bulmak yaygınken AJAX ve ağır Javascript kullanımıyla yukarıdaki örnek ile aynı işi yapan aşağıdaki yapılar görülmeye başlanmıştır.
…
<script type="text/javascript">
$("span#satinal").click(function(){SALELIB. doSale($('activeitem').id)});
</script>
…
…
<span id=”satinal”>satın al</span>
…
Bu örnek bile klasik bir parserın ilgili girdi noktasını (/satinal.do? deger=5&d=3453667&tür=cd) bulma becerisini sorgulamaya yetmektedir. Bu noktada yaygın olarak kullanılan WAT’lar statik parser anlayışından sıyrılmış dinamik bir duruşu uygulamaya koymuşlardır. Dinamik girdi noktası bulma işi, WAT parserının aynı bir tarayıcı (browser) gibi davranıp içinde bulunduğu kodu (Flash, Javascript) sanki normal bir kullanıcı kullanıyormuş gibi çalıştırmasından ibarettir. Tabi ki, diğer bazı kısa yollar (heuristics) da bu işin içindedir ancak çalıştırıp sonucunu yakalamak giderek karmaşıklaşan istemci taraflı kodlar için şimdilik en mantıklı ve kısa yol gibi durmaktadır.
Güvenlik testlerinin en önemli parçalarından biri (bulma, sınıflandırma, risk hesaplamasını yapma, yazılı hale getirme ve gidermenin yanında) ölçülebilir olmasıdır. Aynı şekilde teknolojilerin de kriterler ve standartlar yardımı ile karşılaştırmalarının yapılması ve kalitelerinin ölçülmesi gerekmektedir. Kalite kontrol ve temel bir PHP web uygulaması olan WIVET, WAT’ların faz 1 etkinliğini ölçmek amacı ile yazılmıştır. Bir çok girdi noktası sınıfından oluşan WIVET, üzerine koşulan WAT uygulamasının girdi noktalarını bulmasını bekler (Şekil 1).
Şekil 1 WAT girdi noktası bulma karşılaştırması için WIVET web arayüzü
Ayrıca bu bulma ve çıkarma işlemi sırasında ve sonucunda kapsama alanını (coverage) canlı bir şekilde gösterir (Şekil 2).
Şekil 2 WIVET kapsama alanı ve bulunan linklerin gösterilmesi
WIVET'in bazı açık kaynak kodlu ve ticari WAT'lara ve link çıkarıcılara uygulanması sonucu elde edilmiş matrix Şekil 3'te gösterilmektedir.
Şekil 3 WIVET karşılaştırma kısmi sonuçları
Genel olarak WAT'ların hangi noktalarda takıldığını belirtmek gerekirse;
1. javascript kullanarak a href /iframe oluşturma:
...
var container = document.getElementById("container");
var alink = document.createElement("a");
alink.href = "../innerpages/1_1.php";
alink.innerHTML = "click me";
container.appendChild(alink);
...
var diframe = createElement("iframe");
diframe.src = "../innerpages/12_3.php";
body.appendChild(diframe);
...
2. javascript onay:
…
function searchMe(){
alert("confirm?");
var searchcontainerifr = document.getElementById("searchcontainer");
var enginesel = document.getElementById("engine");
searchcontainerifr.src = enginesel.options[enginesel.selectedIndex].value;
}
…
3. meta refresh:
…
<meta http-equiv=Refresh content="5; URL=../innerpages/14_1.php">
…
4. HTTP 302 cevap içeriği:
HTTP/1.1 302 Found
Date: Sat, 06 Dec 2007 17:58:46 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Location: ../innerpages/16_1.php
Content-Length: 69
Content-Type: text/html
This page has moved to <a href="../innerpages/16_2.php">HERE :)</a>
5. XHR (AJAX) meşgul modu:
function doxhr(phpname){
if(!busy){
AjaxObject.startRequest(formURL(phpname));
busy = 1;
}
else
alert('not so fast, one request at a time old sport');
}
6. Linklenmeyen linkler ve (özellikle AS3 ile yazılan) SWF dosyaları içindeki linkler.
Sonuç
AJAX akımı ile beraber oluşturulan istemci taraflı kütüphaneler her ne kadar hem geliştirmeyi hem de kullanıcı kullanışlığını önemli ölçüde kolaylaştırsa ve eğlenceli hale getirse de, (HTTP) trafik karmaşıklığı ile hem manuel hem de otomatik testlerde işleri zorlaştırmıştır. Bu teknolojiler ile beraber açıklık tipleri çok değişmemiştir ama bu açıklıkları bulmak eskisinden kolay değildir. Otomatik web açıklık tarayıcılar (WAT) test yüzeylerini arttırabilmek için text tabanlı parserlar yerine artık istemci taraflı kodu koşarak (kullanıcıyı simule ederek) dinamik parserlar kullanmaya başlamışlardır. Her ne kadar dinamik tabanlı parserlar iyi iş çıkarsalar bile, çoğu durumda olduğu gibi girdi noktası bulmakta da elle yapılan testlerden iyi ve kapsamlı değildirler. Ancak WAT’lar zaman ve iş gücü değerlendirildiğinde bulunmaz yardımcılardır.
Referanslar
[1] http://www.whitehatsec.com/home/assets/presentations/PPTstats032608.pdf
 Favori olarak ekle (0) | Görüntüleme sayısı: 2699
Sadece kayıtlı kullanıcılar yorum yazabilir.
Lütfen sisteme giriş yapın veya kayıt olun. |
