WK,QWHUQDWLRQDO&RQIHUHQFHRQ,QIRUPDWLRQ6HFXULW\DQG&U\SWRORJ\
8OXVODUDUDVÕ%LOJL*YHQOL÷LYH.ULSWRORML.RQIHUDQVÕ
JAVASCRİPT GÜVENLİK AÇIKLARI VE GÜNCEL ÇÖZÜM ÖNERİLERİ
,VWDQEXO7XUNH\7UNL\H
2FW(NLP
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
I. GİRİŞ
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.
H
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
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: [email protected]).
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).
,6&7XUNH\
3URFHHGLQJV%LOGLULOHU.LWDEÕ
Şekil 1. White Hat Security açıklık istatistikleri
252
WK,QWHUQDWLRQDO&RQIHUHQFHRQ,QIRUPDWLRQ6HFXULW\DQG&U\SWRORJ\
8OXVODUDUDVÕ%LOJL*YHQOL÷LYH.ULSWRORML.RQIHUDQVÕ
JAVASCRİPT GÜVENLİK AÇIKLARI VE GÜNCEL ÇÖZÜM ÖNERİLERİ
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:
x Zararlı içerik barındıran sitenin bilgisayarınıza erişmesini
engellemek
x 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.
,6&7XUNH\
3URFHHGLQJV%LOGLULOHU.LWDEÕ
,VWDQEXO7XUNH\7UNL\H
2FW(NLP
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
http://bilgiguvenligi.gov.tr/
http://
bilgiguvenligi.gov.tr/demos/basic.html
http://
bilgiguvenligi.gov.tr:8080/index.html
http://www2.bilgiguvenligi.gov.tr
/dir/page.html
http:// bilgimikoruyorum.org.tr/
ftp://bilgiguvenligi.gov.tr/
Domain/port/protokol
Kontrolü
Aynı domain, protokol,
port
Aynı domain, protokol,
port
Farklı port
E/H
E
E
H
Farklı domain
H
Farklı domain
H
H
Farklı protokol
253
WK,QWHUQDWLRQDO&RQIHUHQFHRQ,QIRUPDWLRQ6HFXULW\DQG&U\SWRORJ\
8OXVODUDUDVÕ%LOJL*YHQOL÷LYH.ULSWRORML.RQIHUDQVÕ
JAVASCRİPT GÜVENLİK AÇIKLARI VE GÜNCEL ÇÖZÜM ÖNERİLERİ
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ı;
x Script başlıkları içerisinde JavaScript
<script> alert(‘Tübitak Siber Güvenlik Enstitüsü-Kara Harp
Okulu’)</script>
,VWDQEXO7XUNH\7UNL\H
2FW(NLP
x DNS Atakları (DNS Atacks)
İstatistiklere göre bu saldırılar
karşılaşılanlar aşağıda açıklanmıştır.
arasından
en
çok
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)
sırayla
aşağıdaki
adımlar
uygulanarak
saldırıları
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.
x HTML başlıklarının içerisinde JavaScript
<a onclick="JavaScript _fonksiyon(this)"
href="http://bilgiguvenligi.gov.tr">Tıklayınız!</a>
x CSS içerisinde JavaScript
backgroundǦcolor: expression( (new Date()).getHours()%2?
"#B8D4FF" : "#F08A00" );
backgroundǦimage: 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;
x Siteler Arası Betik Çalıştırma (Cross-site scripting/XSS)
o Yansıtılan XSS (Reflected XSS)
o Depolanmış XSS (Stored XSS)
Talep
Sahteciliği (Cross-site
Request
x JSON Hırsızlığı (JavaScript Object Notation Hijacking)
x JavaScript + CSS
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.
o Dom Based XSS
x Siteler Arası
Forgery/CSRF)
Şekil 2. Yansıtılan XSS saldırı senaryosunu gösterir ekran görüntüsü
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.
x Sandbox Holes
,6&7XUNH\
3URFHHGLQJV%LOGLULOHU.LWDEÕ
254
WK,QWHUQDWLRQDO&RQIHUHQFHRQ,QIRUPDWLRQ6HFXULW\DQG&U\SWRORJ\
8OXVODUDUDVÕ%LOJL*YHQOL÷LYH.ULSWRORML.RQIHUDQVÕ
JAVASCRİPT GÜVENLİK AÇIKLARI VE GÜNCEL ÇÖZÜM ÖNERİLERİ
,VWDQEXO7XUNH\7UNL\H
2FW(NLP
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
,6&7XUNH\
3URFHHGLQJV%LOGLULOHU.LWDEÕ
Ş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
WK,QWHUQDWLRQDO&RQIHUHQFHRQ,QIRUPDWLRQ6HFXULW\DQG&U\SWRORJ\
8OXVODUDUDVÕ%LOJL*YHQOL÷LYH.ULSWRORML.RQIHUDQVÕ
JAVASCRİPT GÜVENLİK AÇIKLARI VE GÜNCEL ÇÖZÜM ÖNERİLERİ
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
,6&7XUNH\
3URFHHGLQJV%LOGLULOHU.LWDEÕ
,VWDQEXO7XUNH\7UNL\H
2FW(NLP
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. 188197, 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
WK,QWHUQDWLRQDO&RQIHUHQFHRQ,QIRUPDWLRQ6HFXULW\DQG&U\SWRORJ\
8OXVODUDUDVÕ%LOJL*YHQOL÷LYH.ULSWRORML.RQIHUDQVÕ
JAVASCRİPT GÜVENLİK AÇIKLARI VE GÜNCEL ÇÖZÜM ÖNERİLERİ
,VWDQEXO7XUNH\7UNL\H
2FW(NLP
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.
,6&7XUNH\
3URFHHGLQJV%LOGLULOHU.LWDEÕ
257
Download

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