JavaScript Güvenlik Açıkları ve Güncel Çözüm Önerileri

JavaScript Güvenlik Açıkları ve Güncel Çözüm Önerileri A. Özel, Ç. Kaya, S. Eken Özet İnternet teknolojileri ve bilgisayar kullanımının gelişmesi ile beraber web uygulamalarının sayısı da artmaktadır. İnternet kullanımındaki bu hızlı artışa paralel olarak bankacılık, sağlık, alışveriş gibi günlük hayatta ihtiyaç duyduğumuz birçok hizmet artık web ortamlarına taşınmaktadır. Ancak hayatımızı kolaylaştıran birçok uygulamanın web ortamına taşınması beraberinde web uygulamaları güvenliği sorununu ortaya çıkarmıştır. Bu çalışmada, web programcılarının güvenli web siteleri tasarlayabilmesine yardımcı olmak amacıyla JavaScript web programlama dilinin güvenlik açıklıklarından bahsedilip bu güvenlik açıklıklarına yeni çözüm önerileri sunulmuştur. Anahtar Kelimeler JavaScript, Web Programlama, Web uygulama güvenliği, HTML web programlama dili, Güvenli yazılım geliştirme Abstract Due to development of Internet technologies and computers, the number of web applications is also increasing. In parallel with the rapid increase in Internet usage; banking, health, shopping as well as many other services that we need in everyday life are now moved to the web environment. However, many applications those make our lives easier in the Internet environment reveals problem of web application security. In this study, in order to provide web programmer to design secure websites, security clearances of JavaScript web programming language are mentioned and new solutions to these security clearances are proposed. Index Terms JavaScript, Web Programming, Web application security, HTML web programming language, Secure software development H I. GİRİŞ TML web programlama dili, her ne kadar metin ve medya üzerinde düzenleme yapabilmeyi sağlasa da yetersiz kaldığı durumlar oldukça fazladır. Web uygulamaları üzerinde yapılan bir işleme daha hızlı cevap verilebilmesi veya fonksiyonel bir iş yaptırılması işlemlerinin HTML web programlama dili ile uygulanması daha çok performans gerektirir. Bu eksiklikleri gidermek için Netscape 1995 te, Internet tarayıcısında ilk olarak JavaScript betik dilini kullanmaya başladı. JavaScript dilinin internet sitelerinde kullanımı devrim niteliğinde değerlendirilebilir. Bu sayede daha kullanışlı, grafik efektleri yüksek ve çeşitli fonksiyonlara sahip web siteleri ortaya çıkmış ve aynı zamanda web sitelerinde sıklıkla kullanılan reklam sunucuları tarafından da reklamların gösterilmesi için JavaScript kullanımı artmıştır. Ancak JavaScript dilinin çok kullanılması ile getirdiği kolaylıkların yanında ciddi sonuçlar doğuran web açıklıkları ortaya çıkmıştır. JavaScript dili, yıllardır kullanılmasına ve birçok güncellemeden geçmiş olmasına rağmen günümüzde halen ciddi oranlarda açıklıklara sebebiyet vermekte ve sıklıkla karşılaşılmaktadır. Örneğin; web sayfası ile birlikte yüklenen reklamlar (Ads), bilgisayara casus bir yazılım yükleyebilir, tarayıcı zafiyetlerini kullanarak arka kapı (backdoor) bırakabilir, virüs indirip yükleyebilir (drive by download), verilere erişip silebilir ve hatta kullanıcı bilgisayarında daha fazlasını gerçekleştirebilir. Bütün bu saldırılar için alınmış birtakım önlemler bulunmaktadır. Buna rağmen zararlı JavaScript e karşı internet tarayıcılarının ve sunucuların almış olduğu önlemler bir şekilde atlatılarak sadece JavaScript in doğası gereği olan programlama gücü kullanılarak saldırılar yapılabilir. Bu sayede işletim sistemi üzerinde işlemler yapılabilir, tarayıcı çalışamaz hale (crash) getirilebilir ve kurbanın özel dosyalarına erişim sağlanabilir. Şekil 1 de White Hat Security nin 2013 web site güvenliği istatistik raporunda açıklanan web site açıklık oranları gösterilmiştir [1]. JavaScript ile gerçekleştirilen Siteler Arası Betik Çalıştırma (Cross-site Scripting, Şekil 1 de koyu mavi ile gösterilen kısım) açıklığının yıllardır bilinmesine rağmen ciddi bir oranda karşılaşıldığı tespit edilmiştir. Abdürrahim Özel, TÜBİTAK BİLGEM Siber Güvenlik Enstitüsü, Gebze, Kocaeli, 41470, TÜRKİYE (Telefon Nu: 0262 648 10 00; e-posta: abdurrahim.ozel@ tubitak.gov.tr). Çetin Kaya, KARA HARP OKULU Dekanlığı Bilgisayar Mühendisliği Bölümü, Çankaya, Ankara, 06654, TÜRKİYE (e-posta: ckaya@kho.edu.tr). Süleyman Eken, Kocaeli Üniversitesi, Bilgisayar Mühendisliği, İzmit, Kocaeli, 41380, TÜRKİYE (Telefon Nu: 0262 303 3592; e-posta: suleyman.eken@ kocaeli.edu.tr). Şekil 1. White Hat Security açıklık istatistikleri 252

Bu çalışmada, JavaScript dilinin güvenlik açıklıklarından bahsedilip bu güvenlik açıklıklarına yeni çözüm önerileri sunulmuştur. Bildirinin geri kalan kısmı şu şekilde özetlenebilir: II. bölüm, ilgili çalışmaları kapsamaktadır. III. bölümde JavaScript güvenlik modelleri ve endişeler, IV. bölümde JavaScript kullanılan yerler ve güvenlik açıkları sunulmuştur. V. bölümde, güvenlik açıklarına çözüm önerileri anlatılmıştır. VI. bölüm de ise yapılan çalışmanın sonuçları tartışılmış ve önerilere yer verilmiştir. II. İLGİLİ ÇALIŞMALAR Literatürde JavaScript güvenliğine yönelik birçok çalışma yer almaktadır. Meyerovich ve Livshits [2] Internet Explorer 8 üzerinde çalışan ConScript uygulamasını geliştirmişlerdir. Bu uygulama JavaScript kodlarından kaynaklanan güvenlik açıklarını test etmektedir. Ayrıca WebJail [3], Pung ve ark. [4] önerdiği sistem ve ZAC [5]; JavaScript erişim kontrolü açısından Aspect-Oriented Programlamanın uygunluğunu göstermektedir. Taly ve ark. [6] JavaScript kodlarının güvenliğini analiz edebilen bir araç geliştirmişlerdir. Bu araç daha önce keşfedilmemiş güvenlik açıklarını bulabilme yeteneğine sahiptir. Hallaraker ve Vigna [7] Mozilla Firefox üzerinde JavaScript güvenlik açıklarından faydalanmak amacıyla yapılan kötücül saldırıları tespit etmek amacıyla yeni bir öneri sunmuşlardır. Jiancheng ve ark. [8] JavaScript kod güvenliğini sağlamak için parhelion olarak adlandırdıkları polimorfik tabanlı yeni bir algoritma önermişlerdir. Wei ve ark. [9] kötücül JavaScript kodları ve iyi huylu JavaScript kodları arasındaki farkları ele almış ve yeni geliştirilecek olan saldırı algılama yaklaşımlarına yol göstermeyi hedeflemişlerdir. Barua ve ark. [10] JavaScript enjeksiyon saldırılarından tarayıcı uzantılarını korumak için gerçek zamanlı bir koruma mekanizması önermişleridir. Bu çalışma ise günümüzde var olan JavaScript açıklarına çözüm önerileri getirmekte ve JavaScript temelli uygulama geliştiren kod geliştiricilere yol göstermektedir. III. JAVASCRİPT GÜVENLİK MODELLERİ VE ENDİŞELER JavaScript dilinin sebep olduğu endişelerin başında şunlar olduğu söylenebilir: Zararlı içerik barındıran sitenin bilgisayarınıza erişmesini engellemek Zararlı içerik barındıran bir sitenin bir başka site ile iletişimini engellemek. Bu endişelerin giderilmesi adına günümüz internet tarayıcılarının almış olduğu önlemler bulunmaktadır. Ayrıca sonradan yüklenebilen eklentiler ile de yüklenen web sayfası içerisindeki zararlı JavaScript kodları engellenebilir. Bu tarz eklentilerin kullanımı her ziyaret edilen sayfa içerisindeki JavaScript kodlarının incelenmesi performans problemini doğurduğundan son kullanıcının web uygulamasını kullanılabilirliğini azaltır ve bu durum son kullanıcıyı sıkabilir. Bu endişelere karşı geliştirilen güvenlik modelleri aşağıdaki alt başlıklarda anlatılmaktadır. A. Same Origin Policy (Aynı Kaynak Politikası) JavaScript kodları sunucudan istemciye gönderilecek ve istemci tarafında çalışacak şekilde tasarlanmıştır; fakat Netscape deki geliştiriciler sunucudan tarayıcıya, istemci tarafında çalışacak kod göndermenin güvenlik riskleri yaratabileceğini öngörmüşlerdir. Bu nedenle geliştiriciler aynı etki alanlarından (aynı sunucudan) gelmeyen veya bulunduğu siteden başka bir siteyle iletişime geçmeye çalışan JavaScript betiklerini tarayıcılarda engellemeye başladılar. Buna alan kısıtlaması (Domain Restriction Policy) denmektedir. Örneğin; betiğimiz test1.com.tr adresinden yüklenmiş ise, test2.com.tr adresi ile yüklenen veriler ve fonksiyonlar, ilk yüklenen(test1.com.tr a ait JavaScript betiği) betiğimizin bellek alanına ve fonksiyonlarına erişemez. Alınan bu önlemler tarayıcıdan tarayıcıya farklılık gösterebilir. Bu aşamada bir tarayıcının güvendiği bir JavaScript koduna farklı bir tarayıcının güvenmemesi olasıdır. Bu yüzden her zaman güvenilir sitelerden güvenilir kaynaklardan yararlanılması önerilir. Same Origin Policy [11] temel olarak bir kaynaktan yüklenen script veya dokümanların diğer kaynaktan yüklenen dokümanların özelliklerini değiştirmesini engellemesidir. Same Origin Policy güvenlik mekanizması kullanılmamış olsaydı; örneğin daha önce yüklenmiş olan zararlı bir JavaScript kodu, internet bankacılığını ziyaret ettiğimiz sırada bastığımız tuşları hafızaya alarak saldırgana (hacker) gönderebilecek veya herhangi bir uygulama üzerindeki çerez (cookie) bilgilerimizi çalabilecek ve kullanabilecektir. B. Same Origin Check (Aynı Kaynak Kontrolü) Bir betik farklı bir penceredeki verilere veya fonksiyonlara erişmek istediği zaman tarayıcı tarafından kontrol işlemi gerçekleştirilir. Bu işlem sırasında betik aynı orijinde ise betiğin çalışmasına izin verilirken, kontrolün olumsuz olması durumunda işlem kısıtlanır. Kontrol işleminde betiklerin yüklendiği adreslerin aynı domain, port ve protokolü kullandığı onaylanmalıdır. Örneğin; Tablo 1 de verilen URL (Uniform Resource Locator/ Tekdüzen Kaynak Bulucu) lerin http://bilgiguvenligi.gov.tr/ ile aynı orijinde olup olmama durumu kontrol edilmiştir. Tablo 1. Same Origin Policy karşılaştırma sonuçları URL örnekleri Domain/port/protokol Kontrolü E/H http://bilgiguvenligi.gov.tr/ Aynı domain, protokol, port E http:// Aynı domain, protokol, bilgiguvenligi.gov.tr/demos/basic.html port E http:// Farklı port bilgiguvenligi.gov.tr:8080/index.html H http://www2.bilgiguvenligi.gov.tr Farklı domain /dir/page.html H http:// bilgimikoruyorum.org.tr/ Farklı domain H ftp://bilgiguvenligi.gov.tr/ Farklı protokol H 253

IV. JAVASCRİPT KULLANILAN YERLER VE SALDIRI ÇEŞİTLERİ Programcılar tarafından yapılan yanlış kodlamalar veya bilinçli olarak saldırı amaçlı yazılan kodlar tarayıcı tarafında ve üzerinde çalıştığı işletim sisteminde ciddi problemlere sebep olabilmektedir. Yanlış kodlama veya saldırı amaçlı yazılan JavaScript kodları ile tarayıcının veya üzerindeki eklentilerin barındırdığı zafiyetler sebebi ile işletim sistemi üzerinde port taraması yapılabilir, kurbanın ziyaret ettiği sitelere ait çerez bilgileri çekilebilir, bellek hafızası tüketilebilir ve iç dosya yollarına ulaşılabilir. Bu tarz saldırıları gerçekleştirebilme adına özelleşmiş araçlar geliştirilmiştir [12]. Ayrıca tarayıcının çalışamaz (crash) hale gelebilmesi için uygulanabilecek birçok yöntem vardır. Örneğin; bellek tüketimi için sonsuz değişken tanımlama ve katar ekleme, sonsuz döngü içerisinde çağırılan mesaj kutuları veya fonksiyonlar bu yöntemlerden bazılarıdır. Günümüz tarayıcılarının bazıları bu yanlış kodlamalara karşı önlem almıştır ve kullanıcıları uyarı niteliğinde bilgilendirmektedir. Ayrıca tarayıcılar uyguladıkları Same Origin Policy kurallarını kullanıcıya kısmen değiştirme hakkı tanırlar. JavaScript kullanım alanının geniş olması sebebi ile JavaScript her yerde demek abartılı bir söylem olmayacaktır.örnek kullanım alanları; Script başlıkları içerisinde JavaScript <script> alert( Tübitak Siber Güvenlik Enstitüsü-Kara Harp Okulu )</script> HTML başlıklarının içerisinde JavaScript DNS Atakları (DNS Atacks) İstatistiklere göre bu saldırılar arasından en çok karşılaşılanlar aşağıda açıklanmıştır. A. Siteler Arası Betik Çalıştırma Kullanıcıdan alınan girdinin herhangi bir denetimden geçirilmeden (ya da eksik girdi denetiminden geçirilerek) kullanıcıya gösterilecek sayfanın kaynak kodunun içerisinde yer alması ve bu sayede istemci tarafında betik çalıştırılması işlemidir. Bu sebeple XSS için HTML enjeksiyonu ya da betik enjeksiyonu tabirleri de kullanılabilir. Literatürde üç çeşit Siteler arası betik çalıştırma (XSS) türü vardır: Yansıtılan XSS (Reflected XSS) Yansıtılmış siteler arası betik çalıştırma (Reflected XSS) saldırıları sırayla aşağıdaki adımlar uygulanarak gerçekleştirilir. a) Saldırgan zararlı bir link hazırlar. b) Kurban kullanıcıyı bu linke tıklamaya ikna eder. c) Kurban kullanıcının tarayıcısından zararlı bir talep gönderilir. d) Linkteki zararlı HTML, web sayfası içerisine eklenerek kullanıcıya geri gönderilir. e) Kurban kullanıcının tarayıcısı zararlı HTML i çalıştırır. <a onclick="javascript _fonksiyon(this)" href="http://bilgiguvenligi.gov.tr">tıklayınız!</a> CSS içerisinde JavaScript backgroundcolor: expression( (new Date()).getHours()%2? "#B8D4FF" : "#F08A00" ); backgroundimage: url("javascript : testelement.style.color = '#00cc00';"); JavaScript in yaygın kullanım şekilleri ve popülerliğinden kaynaklanan bu kullanımına bağlı olarak ortaya çıkan birçok saldırı bulunmaktadır. Yapılabilecek saldırılara örnek olarak; Siteler Arası Betik Çalıştırma (Cross-site scripting/xss) o o o Yansıtılan XSS (Reflected XSS) Depolanmış XSS (Stored XSS) Dom Based XSS Siteler Arası Talep Sahteciliği (Cross-site Request Forgery/CSRF) JSON Hırsızlığı (JavaScript Object Notation Hijacking) JavaScript + CSS Sandbox Holes Şekil 2. Yansıtılan XSS saldırı senaryosunu gösterir ekran görüntüsü Depolanmış XSS (Stored XSS) Depolanmış XSS saldırı adımları aşağıda açıklandığı gibidir: a) Saldırgan, zararlı kodunu veri tabanı veya sunucuya enjekte eder. b) Sayfayı ziyaret eden tüm kullanıcıların tarayıcıları bu zararlı kodu çalıştırır. Dom Tabanlı XSS (Dom-based XSS) Dom tabanlı XSS saldırı adımları aşağıda açıklandığı gibidir. 254

a) Yansıtılan XSS e çok benzerdir tek farkı kullanıcıya gönderilen HTML zararlı bir kod içermez. b) Tarayıcı DOM objesini çağırır. c) DOM objesi zararlı kodu çalıştırır. Şekil 3. Depolanan XSS saldırı senaryosunu gösterir ekran görüntüsü Şekil 4.DOM tabanlı XSS saldırı senaryosunu gösterir ekran görüntüsü B. Siteler Arası Talep Sahteciliği-CSRF(Cross-site Request Forgery) Herhangi bir son kullanıcının, kullandığı uygulamada isteği dışında işlemler yaptırtılması şeklinde gerçekleştirilir. Siteler Arası Talep Sahteciliği saldırıları, Sleeping-giant yani uyuyan dev olarak adlandırılmaktadır. Çünkü İnternet'te bulunan birçok uygulamada bu saldırıya karşı alınmış herhangi bir güvenlik mekanizması bulunmamaktadır. Aynı zamanda bu açıklık kolay bir şekilde tespit edilebilir ve istismar edilmesi kolay bir açıklıktır. Sitelerdeki CSRF saldırısına neden olan zafiyetin temelinde geliştiricilerin uygulamayı geliştirme aşamasında, istemci tarafından gelen her isteğin gerçekten kullanıcıdan geldiğini düşünmeleridir. Saldırı şu şekilde gerçekleşir: a) Kurbana gönderilen link in tıklanması sağlanır. b) Kurbanın linki tıklaması sonucu zararlı kod barındıran sayfa ziyaret edilir ve kodlar çalıştırılır. c) Zararlı kod barındıran sayfa sunucuya kurbanın isteği dışında bazı taleplerde bulunur. Zararlı kodun sunucuya yapmış olduğu taleplerin geçerli olmasının sebebi, login olmuş olan kurbanın zararlı kod barındıran sayfayı ziyaret etmesi ile yollanan talep, tarayıcıda kayıtlı olan aynı oturum bilgisi ile otomatik olarak yollandığından o an sunucuda aktif olan oturum ile işlem yapılmasıdır. V. ALINABİLECEK ÖNLEMLER A. Girdi Denetimi Sitenizi ziyaret eden kullanıcı profili ne olursa olsun %100 güvenilir olmayan kaynaklardan gelen girdilerin denetime tabi tutulmadan sisteme sokulmaması gerekmektedir. Ayrıca form Şekil 5. CSRF saldırı senaryosunu gösterir ekran görüntüsü kontrollerinin sadece JavaScript ile yapılması yanlış bir yöntemdir. Sunucu tarafında gerçekleştirilmeyen girdi denetimleri Http trafiğinde araya girilerek (Man in The Middle) atlatılabileceği için yeterli değildir. Programcıların kullanmış olduğu iki yöntem bulunmaktadır. Bu yöntemler: (i) pozitif ve (ii) negatif girdi denetimidir. Pozitif girdi denetimi, sadece güvenilir olan girdilerin belirlenmesi ve belirlenen format dışındaki girdilerin tümünün işleme alınmaması şeklinde tanımlanabilir. Örneğin; bir arama işlemi yapılacak ise bu girdi alanına alfa-nümerik girdi dışında (JavaScript ve Html başlıkları vs.) bir girdinin kabul edilmemesi gerekir. Örnek bir PHP kod bloğu şu şekildedir: <?php $aranacak_kelime=$_post[ kelime ]; İf(!preg_match( [-_0-9A-Za-z],$aranacak_kelime)){ header( Location:error.php ); } else echo aranacak_kelime;?> Php kodunun yaptığı işlem, kullanıcıdan alınan girdi sadece alfa-nümerik karakter içeriyor ise işleme alınmasını sağlamaktır. Bu şekilde saldırganlar (hacker) tarafından enjekte edilmek istenen betik girdilerinden korunmuş olunacaktır. Negatif girdi denetimi ise; istenmeyen girdilerin ayrı ayrı belirlenmesi ve kontrol edilmesi şeklinde yapılan denetimdir. Örneğin; kullanıcı <script> başlığını girdiği durumda bunun işleme alınmaması ile ilgili programcı bir kontrol yapar ve ilgili girdiyi bertaraf eder. Fakat negatif girdi denetiminin kullanım problemleri vardır. Mesela kullanıcının yukarıda 255

bahsedilen kontrol için <ScrİpT> şeklindeki bir girdi yapması sonucunda bu kontrol atlatılabilir ve böylece yapılan kontrolün çokta bir önemi kalmayacaktır. Ayrıca sadece < sembolünün bile çok sayıda farklı kodlanmış yazım şekli bilindiğinden dolayı negatif girdi denetimi yapan programcının bu kodlama yöntemlerinden birini bile gözden kaçırması durumunda saldırıya maruz kalabileceği aşikârdır. Bu yüzden güvenilmeyen kaynaklardan gelen girdiler üzerinde pozitif güvenlik kontrolleri uygulanmalıdır. Negatif girdi denetimi yapılan bir kod bloğu aşağıdaki gibidir: <?php $aranacak_kelime=$_post[ kelime ]; $bypass=array( <script>, </script> ); $replace=array(, ); $aranacak_kelime=str_replace($bypass,$replace,$aranacak_ kelime); Echo aranacak_kelime;?> Yukarıda bahsedilen girdi denetimi yöntemlerinin sadece istemci tarafında betik dilleri (Ajax,Javascript,VbScript) ile yapılması yeterli bir güvenlik önlemi olmamaktadır; çünkü istemci taraflı kontrol edici (controller) araya girme saldırıları ile atlatılması oldukça kolay olmaktadır. Bu yüzden yapılacak olan girdi denetimi mutlaka sunucu tarafında da yapılmalıdır. Daha güvenli bir denetim için hem istemci taraflı hem sunucu taraflı girdi denetimi yapılması önerilmektedir. Çıktı Denetimi Web sayfalarında girdi alanlarına bazen Html, JavaScript başlık girişlerine de izin verilmek istenebilir. Bu gibi durumlarda izin verilen Html başlıklarının iyi kontrol edilmesi gerekmektedir. Örneğin; yazılımcıların kullandığı forum sayfalarında programcılar sorularını sorabilmeleri için kod parçalarını eklemek isteyebilirler. Yazılım geliştiriciler forum üzerinde zararlı kod paylaşımı da yapabilecekleri unutulmamalıdır. Bu gibi durumlarda da alınabilecek önlemlerden biride çıktı denetimidir. Çıktı denetimi kullanıcıya kaynağın gösterilmeden önce son bir denetleme yapılması işlemidir. XSS saldırılarına karşı alınan önlemlerden biridir. Bu işlem için HTML kodlama (HTML encoding) yöntemi tercih edilebilir. HTML kodlama yöntemi HTML varlıkları ile ASCII karakterlerinin değiştirilmesi işlemidir. Örnek olarak '<' karakteri sayfada gösterilirken '&lt' şeklinde bir kodlamaya gidilerek girdi saldırılarından korunmuş olunur. Tarayıcı '&lt' karakterlerini gödüğü alanda '<' karakterini gösterecek ve bunun çalıştırılabilir bir kod olmadını anlayacaktır. VI. SONUÇ VE ÖNERİLER JavaScript güvenlik modelleri sunucu tarafından gönderilen betiklerin kendi kum havuzu(sandbox) alanları ile çalışıp kullanıcı özel verilerine, kullanıcının bulunduğu ağ ile alakalı özel bilgilere ulaşmadan çalışmasını sağlamaktır. Tarayıcılar tarafından uygulanan Same Origin Policy güvenlik politikası ise bir web uygulaması tarafından yüklenen JavaScript kodlarının sadece kendi yüklendiği sitenin hakları ile çalışıp farklı domaindeki kaynaklara erişmesini engellemektir. Tüm bu önlemlerin tam anlamı ile JavaScript in sebep olabileceği zararlardan bir koruma sağladığı akıllara getirilmemelidir. Güvenilir siteler ziyaret edilmeli ve bu siteler üzerinde de çalışabilecek olan zararlı kodlar konusunda da önlemler alınmalıdır. Kimlik doğrulama işlemleri sırasında sadece çerez kullanımı yanlış bir uygulamadır. Siteler arası betik çalıştırma açıklığı ile saldırgan uygulamalara ait çerez bilgisini ele geçirebilir ve bunun sonucu olarak saldırgan sunucu üzerinde yetkisiz işlem yapabilecektir. Bu durumdan korunmanın yöntemlerinden biri çerez(cookie) içeriğine betik dilleri ile erişilmesini engelleyecek Http Only özelliğinin sunucu tarafında etkinleştirilmesi gerekmektedir. Web uygulamaları içerisinde bulunan zararlı betik içeriklerinden korunmak için tarayıcılar tarafında kullanılabilecek JavaScript denetleme eklentileri kullanılabilir. Bu sayede herhangi bir site ziyaret edilmek istendiği sırada herhangi bir JavaScript kodu yüklenmek istendiğinde kullanıcı uyarılır. Eklenti zararlı veya zararsız tüm JavaScript yüklemeleri için kullanıcıyı uyaracağından kullanıcı tarafında kullanım zorluğu oluşturabilir; fakat saldırı durumunda saldırının sebep olacağı zarardan daha fazla can sıkmayacaktır. KAYNAKLAR [1] [Çevrimiçi] WhiteHat Security, https://www.whitehatsec.com/assets/wpstatsreport_052013, [Erişme Tarihi: 28.05.2014]. [2] S. V. Acker, P. D. Ryck, L. Desmet, F. Piessens, W. Joosen, WebJail: least-privilege integration of third-party components in web mashups, 27th Annual Computer Security Applications Conference (ACSAC), pp. 307-316, 2011. [3] P. H. Phung, D. Sands, A. Chudnov, Lightweight self-protecting JavaScript, Proceedings of the 2009 ACM Symposium on Information, Computer and Communications Security (ASIACCS), pp. 47-60, 2009. [4] R. Toledo, É. Tanter, Access control in JavaScript, IEEE Software, 28(5):76-84, 2011. [5] L. A. Meyerovich, B. Livshits, CONSCRIPT: Specifying and Enforcing Fine-Grained Security Policies for JavaScript in the Browser, IEEE Symposium on Security and Privacy, pp. 481-496, 2010. [6] A. Taly, U. Erlingsson, J. C. Mitchell, M. S. Miller, J. Nagra, Automated Analysis of Security-Critical JavaScript APIs, IEEE Symposium on Security and Privacy, pp. 363-378, 2011. [7] O. Hallaraker, G. Vigna, Detecting Malicious JavaScript Code in Mozilla, Proceedings of the 10th IEEE International Conference on Engineering of Complex Computer Systems, pp. 85-94, 2005. [8] J. Qin, Z. Bai ve Y. Bai, Polymorphic Algorithm of JavaScript Code Protection, International Symposium on Computer Science and Computational Technology, pp. 451-454, 2008. [9] W. Xu, F. Zhang ve S. Zhu, The Power of Obfuscation Techniques in Malicious JavaScript Code: A Measurement Study, 7th International Conference on Malicious and Unwanted Software, pp. 9-16, 2012. [10] A. Barua, M. Zulkernine ve K. Weldem, Protecting Web Browser Extensions from JavaScript Injection Attacks, International Conference on Engineering of Complex Computer Systems, pp. 188-197, 2013. [11] M. Zalewski. Browser Security Handbook, part 2. Google, https://code.google.com/p/browsersec/wiki/part2, [Erişme Tarihi: 04 06 2014] [12] [Çevrimiçi] The Browser Exploitation Framework Project. http://beefproject.com/, [Erişme Tarihi: 04 06 2014] 256

A. Özel Siirt te 1989 yılında doğdu. 2007 yılında 14 Eylül Şeref Lisesinden mezun oldu. 2012 yılında Kocaeli Üniversitesi Bilgisayar Mühendisliği nde lisansını tamamladı. Halen İstanbul Şehir Üniversitesi Bilgi Güvenliği Mühendisliği nde yüksek lisansına devam etmektedir. Genel çalışma alanlarını; web uygulamaları güvenliği, veri tabanı güvenliği, güvenli yazılım geliştirme yaşam döngüleri, sanallaştırma güvenliği, sosyal mühendislik, web uygulamaları sızma testi yöntem ve araçlarını kapsamaktadır. Ç. Kaya Karabük te 1989 yılında doğdu. 2006 yılında Gelenbevi Anadolu Lisesi nden mezun oldu. 2012 yılında Kocaeli Üniversitesi Bilgisayar Mühendisliği nde lisansını tamamladı. Halen Gazi Üniversitesi Bilgisayar Mühendisliği nde yüksek lisansına devam etmektedir. Genel çalışma alanlarını; tıbbi veri madenciliği, tıbbi görüntü işleme, saldırı tespit sistemleri ve veri güvenliğini kapsamaktadır. S. Eken Konya da 1985 yılında doğdu. 2004 yılında Dumlupınar Lisesi nden mezun oldu. 2009 yılında Karadeniz Teknik Üniversitesi Bilgisayar Mühendisliği nde lisansını, 2012 yılında ise Kocaeli Üniversitesi Bilgisayar Mühendisliği nde yüksek lisansını tamamladı. Halen aynı üniversitede doktora programına devam etmektedir. Genel çalışma alanlarını; uzaysal veri tabanları ve zaman-mekânsal analizler, uydu görüntülerinin işlenmesi, CBS, suç analizini kapsamaktadır. 257