Evet Arkadaşlar Tutulmaz Gene Süper Bir Konuya İmza Attı..
Olası Hacklenme Nedenler :
- Forum Gibi Dosyaların İçindeki Açıklar.
- Market Gibi Dosyaların İçindeki Açıklar.
- Ticket Sistemi Gibi Dosyaların İçindeki Açıklar.
- Site Panellerinin İçine Koyulan Açıklar.
Server Değil Host Hacklenir!
Host Hacklendiğinde sizin site bilgilerinize ulaşılabilir. Burdanda Config Dosyaları Açılır ve navicat hacklendir.
Site Üzerinden Putty Hacklenmez.
Evet Siteniz hacklendiğinde bi bakmışsınız putty duruyor. Çünkü Config dosyalarınızda sadece navicat var.
Sitem Sürekli Hackleniyor Ne Yapmalıyım ?
Siteniz Hackleniyorsa. Market - Forum ve Ticket'ı silin. Hala hackleniyorsa yeni bir panel bulun.
Herşeyi Yaptım %100 oyunumu koruyacak bişey yok mu ?
İşte Konunumn en mükemmel yerine geldik. Config dosyanizi görünmez kodlamak Onun için
Linkleri sadece kayıtlı üyeler görebilir. Linkleri görebilmek için Üye Girişi yapın veya ücretsiz olarak Kayıt Olun
Config Dosyanızı içindekileri Burdaki alana yapıştırın. Ve Encode diyin. Böylece Config Dosyası Kodlanmış oldu. Hostunuz hacklense bile config i açınca saçma kodlar görücekler ve oyununuza dokunamayacaklar.
Css / Xss Açıkları Nasıl Kapatılır Alınacak Yöntemler Nelerdir ?
Söz edeceğimiz açık 2000 senesinden beri bilinen ama nedense hala web programcıları tarafından göz ardı edilen bir açıktır.
XSS Kullanıcının girdi sağlayacağı sayfalarda kullanıcı tarafından girdiye script’ler gömülerek yapılan saldırılardır. Bu bazen direkt kullanıcının (lamer) kendisi tarafından ya da onu başka bir isteye yönlendirmek isteyen bir lamer tarafından yapılıyor olabilir.
“Genelde cross site scripting açıkları saldırganın sistemi deneme-yanılma yaparak bulması ile ortaya çıkar. Açığın bulunması ile saldırgan başka bir domainden açığın bulunduğu domain ve sayfanın bilgilerini session bilgilerini ve diğer obje değerlerini çalmasına olağan sağlar.
"Cross-site scripting (XSS) güvenlik açıkları e-posta listelerinde en çok rastlanan güvenlik açıkları arasında yer almaktadır. Bunun başlıca nedeni ise bu açığa bir çok web uygulamasında rastlanması ve ücretsiz güvenlik açığı tarama yazılımları ile kolayca keşfedilmesidir..."
Çözüm:
Aslında çözüm yazılan kodlamanın düzeltilmesindedir.
Programın kullanıcıdan aldığı girdiler her zaman kontrolden geçirilmelidir. Bu aynı zamanda "Sql injection" "Buffer Overflow" gibi saldırıları da engelleyecektir.
Eğer belirli bir tür veri (numerik alfanümerik) bekleniyorsa ve belirli bir boyutta ( 8 karakter maksimum 20 karakter gibi) olması bekleniyorsa girilen verinin bu şartlara uyduğunun sağlanması gerekmektedir. Girdilerden metakarakter’ler mutlaka filtrelenmelidir. Bu birçok saldırıyı engelleyecektir. Örneğin ...
< > " ’ % ; ) ( & + -
karakterleri kullanıcı girdisinden temizlenmelidir. Aslında ne tür verinin beklendiği belirtildiği durumlarda bu tür filtreleme de otomatikman gerçekleşecektir.Bu tür karakterlerin gerektiği ortamlarda girilen verinin encode edilmesi gerekebilir.Bu önlemler birçok XSS saldırısını engelleyecektir.Web üzerinden yazılım geliştirenlerin Cert’in referansında yazılı olanlara dikkat etmesi ve kodlamalarında dökümanda belirtilen kurallara uyması gerekmektedir.
Ağda kurulacak bir sistemle bu saldırıların engellenmesinin sağlanması ise ancak sunucuları bir "proxy" veya IPS arkasına koyup her türlü data verisinin kontrolü ve düzeltilmesi ile sağlanabilir. Bu süreçte ise idari ve teknik çeşitli problemler yaşanabilecektir.
En etkin yol dökümanda belirtildiği üzere sunuculardaki kodun tekrar elden geçirilmesidir. Eğer kodu yazan ortalıklarda gözükmüyorsa ya o kod kaldırılmalı ya da ağ tabanlı bir çözüme gidilmelidir.
Sql Injection nedir? Nasil sitemi ona karsi koruyabiliriz?
"Web uygulamalarinda bir cok islem icin kullanicidan alinan veri ile dinamik SQL cumlecikleri olusturulur. Mesela "SELECT * FROM Products" ornek SQL cumlecigi basit sekilde veritabanindan web uygulamasina tum urunleri dondurecektir. Bu SQL cumlecikleri olusturulurken araya sikistirilan herhangi bir meta-karakter SQL Injection’ a neden olabilir."
Gunumuz web uygulamalarinin cogu dinamik bir yapi olmasi, daha hizli guncellemek, data (veri) ile interface (arayuzu) birbirinden ayirmak icin database (veri tabani) kullanir. Databaseden veri cekmek icin Sql komutlar uygulanir. Sitelerde dinamik bir yapi nedeniyle, parametre gonderme islemleri olmaktadir. Bu parametre islemleri POST ve GET yolu ile olmaktadir. Siz egerki bu parametreye metakarakterler kullanarakdan sitedeki kod icindeki sql komuta mudahale edebilmis olacaksiniz. Boylece parametre uzerinden Sql komuta mudahale etmis, istedigimiz sekilde degistirip, database uzerinde veri silme, guncelleme, ekleme gibi basit; server da cmd calistirma, oturum kulanicisi ekleme, serverin file (dosya) sistemine erisme gibi komplex islemler mumkun kilinabilinmektedir. Sizlere bu konuda sadece nasil yapildigi degil nasil korunacagindan bahsedecegim.
Oncelikle kullaniciya hic bir zaman guvenmiyeceksiniz. Disardan gelen tum parametreleri kontrol etmemiz gerek. Bunlar request.form("") ve request("") seklinde gelen tum veriler. (Ben size ASP web programlama dilinde anlatacam cozumu. )
<%
’************************************************* ***************
’******* Ejder ’s SQL INJECTION SECURITY SYSTEM
’************************************************* ***************
Function Sql*****er(ejder)
’ ejder parametresi ile gelen bilgi, Sql ve Xss icin filtrelenmektedir.
ejder = Replace(ejder, "<", "<")
ejder = Replace(ejder, ">", ">")
ejder = Replace(ejder, "<br>", "<br>")
ejder = Replace(ejder, "[", "&?")
ejder = Replace(ejder, "]", "&?")
ejder = Replace(ejder, """", "", 1, -1, 1)
ejder = Replace(ejder, "=", "&?", 1, -1, 1)
ejder = Replace(ejder, "’", "’’", 1, -1, 1)
ejder = Replace(ejder, "select", "sel&?ct", 1, -1, 1)
ejder = Replace(ejder, "convert", "conver_t", 1, -1, 1)
ejder = Replace(ejder, "cast", "cas_t", 1, -1, 1)
ejder = Replace(ejder, "join", "jo&?n", 1, -1, 1)
ejder = Replace(ejder, "union", "un&?on", 1, -1, 1)
ejder = Replace(ejder, "where", "wh&?re", 1, -1, 1)
ejder = Replace(ejder, "insert", "ins&?rt", 1, -1, 1)
ejder = Replace(ejder, "delete", "del&?te", 1, -1, 1)
ejder = Replace(ejder, "update", "up&?ate", 1, -1, 1)
ejder = Replace(ejder, "like", "lik&?", 1, -1, 1)
ejder = Replace(ejder, "drop", "dro&?", 1, -1, 1)
’ejder degiskeni filtrelendi, return icin Sql*****er a yukleniyor.
Sql*****er = ejder
End Function
%>
ASP icin hazirlanmis kodumuz budur. Disardan gelen veriyi Sql*****er() seklinde almamiz gerek.
Sql*****er(request.form("id"))
Bu sayede meta-karakter lere izin verilmicek. Sql sorgumuza mudahale edilmemis olacak. Edilse bile islememis olacak. Bunu biraz daha gelistirebiliriz. Yukardaki ilk 8 durumdan birini icerirse, banlist e ekleme yada hata verip , response.end ile sayfanin geri kalan kisminin islemesini engelleyebiliriz. Bu onlemleri aldiginiz taktirde Sql injectiondan korkmayin. ( Sql*****er() fonksiyonu ayni zamanda, Xss acigini engellemek icinde kullanabiliriz. Her iki ozellik dusunerekden tum onlemler alindi. ). Yapmamiz gereken diger ekstra onlemler ise;
- Veritabanimiza kisitli erisim hakki sagliyarakda, korumada saglanir. Mesela site uzerinden database e erisim yetkileri kisitli yapip, sadece okuma verilebilinir.
- Dinamik sql sorgularindan uzak duralim. Parametre gondererek yada stored procedureler kullanilmasi daha guvenlidir.
- Veritabanimizdaki onemli verileri, sifreleme algoritmasi kullnarak islem yapilmasi gerekir.
- Sitemizde parametre yolu ile hata cikmasini en aza indirmemiz gerekir.
Bazi saldiri yazilimlarindan sitemizi nasil koruyabiliriz?
Sitenize surekli saldiri yapiliyor, servis disi kaliyor. Ilk adim, bu saldirinin turunu ve nereye yapildigini ogrenmek. Evet ana sayfamiza surekli binlerce request yani istekde bulunulmus. Dogal olarakda sitemiz cevap veremez duruma gelmis. Bu durumda browser bilgilerine bakacaz loglardan. Hangi programla yapilmis ve normal kullanicidan farkli bir durum ariyacaz.
Ben bu tur saldirilarla karsilastigim icin. Onceden onlem aldim. Mesela *Lamer Program Adı Yasaktır* diye bir yazilim vardir. Surekli connection acar durur. Kapatmazda , server kisa sure sonra cevap veremez duruma gelir. Peki bu durumda nasil engelleriz derseniz. Bizim Web programciligi adina yapmamiz gereken cozumlerden biri, browser bilgisini filtrelemektir. Mesela *Lamer Program Adı Yasaktır* ile kendi ozel siteme degisik tarzda saldirilar yaptim. Teslerim sonucu sunu gozlemledim. Her sitemize requestde bulundugunda kullanilan browser bilgisi farkli idi. Yani Browser bilgisi "*Lamer Program Adı Yasaktır*" kelimesini icermekteydi. Buda bize onu filtreleyebilme sansi verdi. Vede asagidaki kodu yazdim.
<%
’************************************************* ***************
’******* Tutulmaz ’s *Lamer Program Adı Yasaktır* Protecter SYSTEM
’************************************************* ***************
Dim BrowseVar
’Siteye giren kisinin browser bilgisi.
BrowserVar = Trim(Request.ServerVariables("HTTP_USER_AGENT"))
If BrowseVar <> "" Then
’icinde *Lamer Program Adı Yasaktır* geciyorsa , banlama sistemine gonder.
If Instr(BrowseVar, "*Lamer Program Adı Yasaktır*") <> 0 Then
response.end
else If Instr(UCASE(BrowseVar), "*Lamer Program Adı Yasaktır*") <> 0 Then
response.end
else If Instr(UCASE(BrowseVar), "*Lamer Program Adı Yasaktır*") <> 0 Then
response.end
end if
end if
end if
end if
%>
Testlerimde cok basarili oldu. Cok etkili bir sekilde saldirinin yukunu azaltiyor. Burda saldiri programi yazan kisi icin dikkat edilmemis bir ayrinti idi. Ama bizim isimize yaradi bu ayrinti. Biz *Lamer Program Adı Yasaktır* saldirisini ? yapilip yapilmadgini anliyabilecegiz artik..
Mesela bir baska saldiri programlarindan , POST saldirisi yapan denyo yaziliminin browser bilgisinde de "holyone" icermekteydi. Boylece onuda filtreleyebildik.
<%
’************************************************* ***************
’******* Tutulmaz ’s DENYO Protecter SYSTEM
’************************************************* ***************
Dim BrowserVar
’Gelen kisinin Browser bilgisini aliyoz
BrowserVar = Trim(Request.ServerVariables("HTTP_USER_AGENT"))
If BrowseVar <> "" Then
If Instr(BrowseVar, "Denyo") > 1 Then
response.end
else If Instr(UCASE(BrowseVar), "HOLYONE") > 1 Then
response.end
else If Instr(BrowseVar, "HolyOne") > 1 Then
response.end
else If Instr(BrowseVar, "Nightmare") > 1 Then
response.end
else If Instr(UCASE(BrowseVar), "NIGHTMARE") > 1 Then
response.end
end if
end if
end if
end if
end if
end if
End Sub
%>
Sonuc olarak ciddi cozum bulduk. Sitemizdeki kodlarin hepsi islemeden hatta veritabani ile iletisim kurmadan bu tur kontrol yaptigimizda, ciddi anlamda saldiriyi etkisiz hale getirmis oluyoruz.
Bu tur programlarin ne tur bilgi gonderdini ogrenmek icin illa sitenizde denemeniz gerekmez. Bir tane Paket izleme yani sniffer yazilimi kulanarakdan, gonderdigi request bilgisinden ne tur browser bilgisi gonderdigini, turunu , nereye saldirdigini ogrenebilirsiniz. Vede o yonde sitenizde onlemler kod bazli alabilirsiniz.
Her saldiriyi bu sekilde asamayiz tabikide. Yeterlide olmiyacaktir. Sadece web programlaa dili adina nasil kendimizi maximum koruyabileceigimizden bahsetmeteyim. Tabikide mumkun oldugunca optimum kod yamamiz, az kaynak harcama ve veritabanina minimum erisimler saglamamiz ? bu tur saldilarin etkisini azaltacaktir..
Sizlere ornek bir POST paket gostereyim.
POST /fight-club/fight.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
x-flash-version: 9,0,47,0
Content-Type: application/x-www-form-urlencoded
Content-Length: 39
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Host: apps.facebook.com
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: Cookie: __utma=456546497.1131734494.1190402303.114568562.1 194561491.150; __utmz=252321497.1194011491.150.125.utmccn=(referr al)|utmcsr=facebook.com|utmcct=/profile.php|utmcmd=referral; __utmb=456546597; __utmc=456456497; ABT=5967c5ab4b4d56560d393b4a820d67e%36594082139%3A A%235967c5ab4b4d2f4170d393b4a820d67e15656A11940821 39%3AA%23558501336a9f79e16394d2e3b8d24d4f1st%3A119 4609ggg17%3AA; login_x=xxxxxx%40hotmail.com; xs=327ff8e565f318a94f35add51f056b5c; c_user=4565469422; sid=2
uid=4565434445&comp=true&fight=Fight+Opponent
Bu paketde, sizin browser bilginiz, cookie degeriniz, post degeri, islemcinizi gorebilirsiniz. Bu normal bir webbrowser ile gonderilen POST verisidir.
Upload, resim aciklari nelerdir?
Bu dokumanimdaki son kismi buna ayirdim. Sizlere Asp ve Php icin bahsedecegim. Sitelerimizde resim yukletmek, yada dosya yukletme gereksinimi cok duyariz. Mesela sizlere direk buyuk bir sirketin aspx le yazdigi bir sitenin acigindan bahsedeyim.
Argesoft yazilimi olan, argesoft, logosoft, boyner, argenet gibi sirketlerin kullandigi bir aspx tabanli site. Admin panelinein userlist kismina sifresiz, cookie kontrolsuz girdim. Evet garip ama gercek. Google ada o kisim referans gitmis. Her neyse. Ben admin paneline girdim, sifreleri degistirdim. Shell yuklemem gerekiyordu. Orda dikkatimi ceken bir kisim vardi. Resim upload kismi. Sadece jpg,gif yuklenebiliyormus yazdigina gore. Peki? Neye gore kontrol ediiyor. Eger yuklenen dosyanin icinde jpg ? kelimesi var yok ona goremi, yoksa duzgunce filtreleyip, resim oldugunu anliyacak bir cozum uretmislermiydi? Ne yazikki adamlar icinde jpg, gif kelimeleri geciyorsa izin veriiyormus. Bende efso.jpg.asp (asp shell) diye dosyami bir guzel upload edip, server a sizmistim. Vede site yazilimlarini kendime yedeklemistim. Gordugunuz gibi cok komik bir durum. Bu tur sorun bir cok asp tabanli sitelerde vardir. Dosya icinde aramak degilde, dosya adinda, noktadan sonraki terime bakilmasi gerekmektedir.
Simdi sizlere PHp den bahsedeyim. Once Linux hakkinda bilgi verem. Linuxda dosyalarin uzantilari onemsizdir. Yani uzantiya hic bakmaz. Dosyanin icindeki tagladan ne oldugunu anlar. Simdi baska bir basima gelen olaydan bahsedeyim. Php tabanli resim upload edilen bir site vardi. Sadece resim dosyasi kabul ediyordu. Peki uzanti onemsizse, resim oldugunu icindeki taglardan anliyordu. Bende phpde hazirlanis shell dosyam, shell.php yi yuklettim. Fakat resim olmadigi icin kabul etmedi. Bunun uzeirne shell.php nin ilk satirina, GIF89a; yazdim. Ve tekrar denedim. Ve bu seferinde, sistem kabul etti, yukledi bir guzel ve bana linkinide verdi. Boylece server a ulasmis oldum. Bir baska olay ise, php tabanli sitelerde, avatar yukleme olayi vardir. Onda ise gif resmi notepad2 ile acip, sonuna php kod yazip, yukleyip , calistirtmaktaydik. Boylece gif icindeki kodumuz, sorunsuz execute etmekte idi.
Bu sekilde bir cok olay yasadim. O yuzden upload sistemini tasarlarken, bu soylediklerimi unutmamaniz gerek. Ona gore onlem anlmaniz gerekir. Unutmayinki kullanicilara guven olmaz
Geldiiik Programlara
Anti Trojan Elite(ATE) bir malware silicidir. Sisteminizdeki malware’leri bulur ve siler. Anti Trojan Elite gerçek zamanlı bir malware firewall duvarı olarak da iş görmektedir. Öncelikle bir trojan veya keylogger yüklenirse bunu ATE ile kolay bir şekilde tespit edebilirsiniz. Ve ATE bu zararlı dosyayı anında engeller ve size zaman içinde bu dosyayı silme imkanı verir. 35 binden fazla trojan’ı tespit edebilir, solucanları, keylogger’ları tespit edebilir ve silebilir.
TCP bağlantısını da koruyarak buradan gelebilecek her türlü tehlikeye karşı sizi uyarır. Güncellemeleri ile de her daim tetikte durur.
Trojan kütüphanesi yeni versiyon ile birlikte güncellenmiştir.
Linkleri sadece kayıtlı üyeler görebilir. Linkleri görebilmek için Üye Girişi yapın veya ücretsiz olarak Kayıt Olun
SQL Injection Açığı İle İlgili Bilgiler
SQL Injection Nedir?
SQL Injection saldırganların veri çalma/değiştirmede kullandıkları web saldırı metodlarından biridir. Belkide günümüzde en çok kullanılan uygulama seviyesi tekniklerden biridir. Web uygulamasındaki güvensiz kodlamalardan yararlanarak login formu gibi kullanıcı girişlerinin SQL sorgusunda kullanıldığı yerlerde SQL komutları eklenmesi ile veritabanına yetkisiz erişim sağlar.
SQL Injection: Detaylı Açıklama
Web uygulamaları web sitesini ziyaret eden kullanıcıların web tarayıcıları ile bir veritabanından veri görüntüleyebilmelerini sağlarlar. Veritabanları çoğu web sitesinde kullanılır ve ziyaretçilere spesifik bilgilerin sunulması için veri depolama amaçlı kullanılırlar. Kullanıcı bilgiler, finansal ve ödeme bilgileri, firma istatistikleri bir veritabanında bulunabilir ve hazır veya özel yazılmış uygulamalar ile erişilebilirler.
SQL Injection, bir web uygulaması üzerinden arka plandaki veritabanında çalıştırılması için SQL komutlarının gönderilmesidir. Eğer web uygulamasında kullanıcı tarafından gelen tüm parametreler doğru olarak filtrelenmemişse saldırganlar tüm veritabanı içeriğini görebilir veya silebilirler.
Login sayfaları, destek veya ürün istek formlar, yorum/iletişim formları, arama sayfaları, alışveriş sepeti sayfaları dinamik içeriğin sunulduğu çeşitli sayfalardır ve modern iş dünyasında müşteriler ile veya kullanıcılar ile haberleşmede vazgeçilmezdir.
Bu tip web siteleri SQL Injection saldırılarından etkileniyor olabilir.
SQL Injection: Basit bir örnek
Normal bir kullanıcının kendi kullanıcı adı ve şifre kombinasyonu ile giriş yaptığı bir login sayfası düşünün.
Normal kullanıcı bilgilerini gönderdiğinde bu bilgilerden bir SQL sorgusu yaratılarak doğrulama için veritabanına gönderilir. Eğer geçerli ise kullanıcının erişimine izin verilir. Diğer bir deyişle login sayfasını kontrol eden web uygulaması kullanıcı adı şifre kombinasyonunu doğrulamak için planlanmış komutları kullanarak veritabanı ile haberleşir. Doğrulandığında da kullanıcının erişimine izin verilir.
SQL Enjeksiyon ile saldırganlar login formu engelini aşarak arkasındakileri görmek için özel olarak hazırlanmış SQL komutları girerler. Bu sadece eğer kullanıcı tarafından sağlanan girişler doğru olarak filtrelenmiyor ve direk olarak SQL sorgusu ile veritabanına gönderiliyorsa mümkün olabiliyor. SQL Enjeksiyon açıkları saldırganların direk olarak veritabanı ile haberleşmesini sağlarlar.
Bu tip saldırılardan etkilenen teknolojiler ASP, ASP.NET, PHP, JSP ve CGI gibi dinamik script dilleridir. SQL Enjeksiyon saldırısı yapacak olan bir saldırganın tek ihtiyacı olan bir web tarayıcısı, SQL sorguları hakkında bilgidir. SQL Enjeksiyonun basitliği onu popüler yapan en büyük etken.
Nasıl olurda bir güvenlik duvarı veya diğer güvenlik mekanizması arkasındaki bir veritabanına direk olarak SQL sorguları geçer?
Güvenlik duvarları ve benzer saldırı tespit mekanizmaları tam ölçekli bir SQL enjeksiyon web saldırısına karşı çok az hatta bazen hiç koruma sağlamazlar.
Web sitenizin herkese açık olması gerektiği için güvenlik mekanizmaları web uygulamanıza erişime (genelde port 80/443) izin verecektir. Ve web uygulamasının istenilen bilgileri gösterebilmesi için veritabanına erişim yapabilmesi gerekir.
SQL veya Structured Query Language verileri bir veritabanına depolamanızı, değiştirmenizi ve çağırabilmenizi sağlar. SQL, gerçekten de, bir web uygulamasının (ve kullanıcıların) veritabanı ile etkileşebilmeleri için tek yoldur. Veritabanlarına örnek olarak Oracle, Microsoft Access, MS SQL Server, MySQL ve Filermaker Pro verilebilir.
SQL komutları arasında belli başlı olarak SELECT, INSERT, DELETE ve DROP TABLE sayılabilir. DROP TABLE kelime anlamı olarak da görüleceği gibi belirli isimdeki bir tablonun silinmesini sağlar.
Yukarıdaki login sayfası örneğinde normal bir senaryoda web uygulaması için planlanan SQL komutları aşağıdaki gibi olabilir:
SELECT count(*)
FROM kullanici_listesi_tablosu
WHERE kullanici='KULLANICI_ALANI'
AND sifre='SIFRE_ALANI'
Bu SQL komutu veritabanı sunucusunda depolanan bilgi ile kullanıcının girdiğini eşleştirmeyi dener.
Çoğu web uygulamasının içine veritabanı ile haberleşebilmesi ve fonksiyonlarını gerçekleştirebilmesi için belirli bazı SQL sorguları gömülür. Eğer web uygulamasının herhangi bir giriş alanı doğru olarak filtrelenmez ise, bir saldırgan ek SQL komutları enjekte ederek web uygulamasının çalıştıracağı SQL komutlarını artırabilir, böylece orjinal dizayn ve fonksiyonun ötesine geçer.
Böylece saldırganların veritabanı ile arasında temiz bir haberleşme kanalı kurulacaktır.
Veritabanım SQL Enjeksiyon'dan etkileniyormu?
SQL Enjeksiyon şu an Internet'te kullanılan en genel uygulama katmanı saldırılarından biridir. SQL Enjeksiyon saldırılarına karşı korunmak kolay olsa da halen bu açıktan etkilenen çok sayıda web uygulaması var.
Web Uygulama Güvenliği Konsorsiyum'una (WASC) göre 27 Temmuz 2006 tarihine kadar medyada rapor edilen hack olaylarının %9'u SQL Enjeksiyon saldırılarından kaynaklanmıştı. Araştırmalarımızdan elde ettiğimiz daha güncel veriler web sitelerinin %50'sinin SQL Injection saldırılarından etkilendiğini ortaya koydu.
Eğer programcı değilseniz veya web uygulamanızı siz kodlamadıysanız web sitenizin ve uygulamanızın SQL Enjeksiyondan etkilenip etkilenmediği sorusunu cevaplamak biraz zor olabilir.
Bir saldırganın veritabanında depolanmış olan verilerinizi görüp göremeyeceği web sitenizin nasıl kodlandığına bağlı. Kesin olan şey saldırganların etkilenen sistemlerde, sistemi ele geçirmek için veya bilgi edinmek için, istedikleri SQL komutlarını çalıştırabileceğidir.
Eğer düzgün kodlanmadıysa müşteri veya firma verilerinizin ele geçirilmesi riski söz konusudur.
Bir saldırganın nelere erişebileceği de veritabanında ayarlanmış olan güvenlik seviyesine bağlıdır. Veritabanı sadece belirli bazı komutların çalıştırılmasına izin veriyor olabilir. Normalde web uygulamaların ön yüzleri için sadece okuma izni verilir.
Saldırgan sistemde veya verilerde değişiklik yapamasada hala değerli bilgileri okuyabilir.
SQL Enjeksiyon'un etkileri nedir?
Bir saldırgan sistemin SQL Enjeksiyon saldırısından etkilendiğini tespit ettiğinde bir giriş alanından SQL sorgu ( komutlarını çalıştırmaya başlar. Bu veritabanınızı saldırganın eline verip istediği SQL komutlarını çalıştırmasına, istediği verileri silmesine ve değiştirebilmesine izin vermek gibidir.
Saldırganın istediği komutları çalıştırması veritabanı bütünlüğünün bozulmasına ve önemli bilgilerin görülmesi ile sonuçlanır. Arka planda kullanılan veritabanına bağlı olarak SQL enjeksiyon açıkları saldırgan için değişik seviyelerde veri/sistem erişimi sunar.
Bazı durumlarda dosyalardan okumak veya dosyalara yazmak, ya da işletim sisteminde komutlar çalıştırmak mümkün olabilir. Micorosft SQL sunucusu gibi bazı SQL sunucuları stored ve extended prosedürler (veritabanı sunucusu fonksiyonları) içerirler. Eğer bir saldırgan bu prosedürlere ulaşabilirse bu tam bir felaket olacaktır.
Maalesef SQL enjeksiyon etkileri sadece veri hırsızlığı veya hack sonrası farkediliyor.
Bir SQL Enjeksion saldırısı örneği
login ve şifre den oluşan iki giriş kabul eden basit bir HTML formunu inceleyelim:
<form method="post" action="http://testasp.acunetix.com/login.asp">
<input name="tfUName" type="text" id="tfUName">
<input name="tfUPass" type="password" id="tfUPass">
</form>
login.asp'nin en kolay çalışma şekli aşağıdaki gibi bir veritabanı sorgusu hazırlamakla olabilir:
SELECT id
FROM logins
WHERE username = '$username'
AND password = '$password’
Eğer $username ve $password değişkenleri kullanıcı girişinden direk olarak alınıp SQL sorgusunda kullanılıyorsa çok kolay bir şekilde hack edilebilir demektir. Kullanıcı adı olarak "Olympos" verdiğimizi ve şifre için de aşağıdakini yazdığımızı varsayalım:
falan' OR 'x'='x
SELECT id
FROM logins
WHERE username = 'Olympos'
AND password = 'falan' OR 'x'='x'
Web uygulamasında kullanıcı girişleri doğru olarak filtrelenmediği için, tek tırnak kullanımı WHERE sql komutunu iki-bileşenli bir sorguya dönüştürdü.
'x'='x' bölümü ilk bölüm ne olursa olsun şartın doğru olmasını garantiler.
Bu da saldırganın login form'unu geçerli bir kullanıcı / şifre kombinasyonu bilmesine gerek kalmadan aşabilmesini sağlar.
SQL Enjeksiyon saldırılarını nasıl engellerim?
Güvenlik duvarları ve benzer saldırı tespit mekanizmaları bu konuda tam bir koruma sağlamayabilir. Web sitenizin herkese açık olması gerektiği için güvenlik mekanizmaları web trafiğinin veritabanı sunucularınız ile web uygulaması aracılığı ile haberleşmesine izin verecektir. Zaten bunun için tasarlanmadılarmı?
Sunucularınızı, veritabanlarını, programlama dillerini ve işletim sistemlerinizi güncelleyip yamalarını geçmeniz kritik öneme sahip fakat SQL Enjeksiyon saldırılarını engellemede tam çözüm değildir.
Linkleri sadece kayıtlı üyeler görebilir. Linkleri görebilmek için Üye Girişi yapın veya ücretsiz olarak Kayıt Olun
SPAM Sitelerinden Kurtulmak
Bazı api vb.yöntemlerle arama sonuçlarına göre oluşturulan sayfalarda site linklerinizin sonuna ?ref=xsite.net gibi ekler getirilerek, google vb.arama motorlarında bu urller sitenize bağlı sayfaymış gibi görünür.
örnekle açıklayalım:
Linkleri sadece kayıtlı üyeler görebilir. Linkleri görebilmek için Üye Girişi yapın veya ücretsiz olarak Kayıt Olun
tahmini gerçek sayfa sayısı: 130
googleda indexli sayfa sayısı: 180
googleda indexli ?ref= li url sayısı: 80
yani, 80 tane benim yapmadığım ve orjinal sayfayla farkı olmayan sayfam indexlenmiş. peki sitemize ne zararı var; bilirsiniz spam sayfa oluşturmak sandbox veya ban sebebi birçok arama motorunda. örneğin,
Linkleri sadece kayıtlı üyeler görebilir. Linkleri görebilmek için Üye Girişi yapın veya ücretsiz olarak Kayıt Olun
Linkleri sadece kayıtlı üyeler görebilir. Linkleri görebilmek için Üye Girişi yapın veya ücretsiz olarak Kayıt Olun
çözümü bu linklerin orjinal url lere ama ?ref lerden arınmış şekilde yönlendirmesi olarak kabul ediliyor. htaccess yöntemini henüz bikaç gündür denedim. bunu sizle canlı paylaşmak istemem, hem spam sayfaları görmeniz, hem başarılı olursa önümüzdeki günlerde beraber paylaşmamız. kesin işe yarar diyemem. ama bunlardan kurtulmak için denemeye değer.
Moderatör tarafında düzenlendi:
