- Katılım
- 24 Tem 2009
- Konular
- 61
- Mesajlar
- 782
- Çözüm
- 5
- Reaksiyon Skoru
- 35
- Altın Konu
- 0
- TM Yaşı
- 16 Yıl 10 Ay 18 Gün
- Başarım Puanı
- 117
- Yaş
- 35
- MmoLira
- 112
- DevLira
- 3
ROHAN2 WORLD 1-120 TR TİPİ OFFICIAL YOHARA, BALATHOR VE AMON! 80. GÜNÜNDE! +10.000 ONLİNE! HİLE VE BOT %100 ENGELLİ HEMEN TIKLA!
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.
İşte Konunumn en
mükemmel yerine geldik.
Config dosyanizi görünmez
kodlamak Onun için BU
SİTE'yi kullanıcağız.
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. )
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.
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.
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.1194561491.150;
__utmz=252321497.1194011491.150.125.utmccn=
(referral)|
utmcsr=facebook.com|
utmcct=/profile.php|
utmcmd=referral;
__utmb=456546597;
__utmc=456456497;
ABT=5967c5ab4b4d56560d393b4a820d67e
%36594082139%3AA
%235967c5ab4b4d2f4170d393b4a820d67e15656A1194082139%3AA
%23558501336a9f79e16394d2e3b8d24d4f1st
%3A1194609ggg17%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.
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:
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.
Sql Açıkları Dökümanı İçin
Tıkla
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:
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,
iletisim.html ile http://
iletisim.htm....spamsite.info
arasında (sayfa içeriği
olarak) ne fark var. fark
yok. google ve bazı arama
motorları bunu sizin kopya
içerik olarak spam
niyetiyle yaptığınızı
sanabilir.
çö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.
.htaccess yöntemi
RewriteCond
%{THE_REQUEST} \?
(ref=.*)?\ HTTP [NC]
RewriteRule .? http://
%{REQUEST_URI}?
[R=301,L]
Php Yöntemi
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.
İşte Konunumn en
mükemmel yerine geldik.
Config dosyanizi görünmez
kodlamak Onun için BU
SİTE'yi kullanıcağız.
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. )
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.
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.
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.1194561491.150;
__utmz=252321497.1194011491.150.125.utmccn=
(referral)|
utmcsr=facebook.com|
utmcct=/profile.php|
utmcmd=referral;
__utmb=456546597;
__utmc=456456497;
ABT=5967c5ab4b4d56560d393b4a820d67e
%36594082139%3AA
%235967c5ab4b4d2f4170d393b4a820d67e15656A1194082139%3AA
%23558501336a9f79e16394d2e3b8d24d4f1st
%3A1194609ggg17%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.
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:
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.
Sql Açıkları Dökümanı İçin
Tıkla
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 görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
adresitahmini 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 görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
iletisim.html ile http://
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
iletisim.htm....spamsite.info
arasında (sayfa içeriği
olarak) ne fark var. fark
yok. google ve bazı arama
motorları bunu sizin kopya
içerik olarak spam
niyetiyle yaptığınızı
sanabilir.
çö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.
.htaccess yöntemi
RewriteCond
%{THE_REQUEST} \?
(ref=.*)?\ HTTP [NC]
RewriteRule .? http://
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
%{REQUEST_URI}?
[R=301,L]
Php Yöntemi
PHP:
list($adres2) =
explode("?ref", $_SERVER
['REQUEST_URI']);
$adresim = "http://".
$_SERVER
['SERVER_NAME'].$adres2;
if (eregi('ref=', $_SERVER
['REQUEST_URI'])) {
header( "HTTP/1.1 301
Moved Permanently" );
header("Location: ".
$adresim);
}- Katılım
- 7 Kas 2011
- Konular
- 26
- Mesajlar
- 306
- Online süresi
- 1h 37m
- Reaksiyon Skoru
- 11
- Altın Konu
- 0
- TM Yaşı
- 14 Yıl 7 Ay 2 Gün
- Başarım Puanı
- 96
- MmoLira
- 11
- DevLira
- 0
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.
İşte Konunumn en
mükemmel yerine geldik.
Config dosyanizi görünmez
kodlamak Onun için BU
SİTE'yi kullanıcağız.
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. )
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.
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.
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.1194561491.150;
__utmz=252321497.1194011491.150.125.utmccn=
(referral)|
utmcsr=facebook.com|
utmcct=/profile.php|
utmcmd=referral;
__utmb=456546597;
__utmc=456456497;
ABT=5967c5ab4b4d56560d393b4a820d67e
%36594082139%3AA
%235967c5ab4b4d2f4170d393b4a820d67e15656A1194082139%3AA
%23558501336a9f79e16394d2e3b8d24d4f1st
%3A1194609ggg17%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.
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:
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.
Sql Açıkları Dökümanı İçin
Tıkla
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 görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.adresi
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 görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
iletisim.html ile http://
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
iletisim.htm....spamsite.info
arasında (sayfa içeriği
olarak) ne fark var. fark
yok. google ve bazı arama
motorları bunu sizin kopya
içerik olarak spam
niyetiyle yaptığınızı
sanabilir.
çö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.
.htaccess yöntemi
RewriteCond
%{THE_REQUEST} \?
(ref=.*)?\ HTTP [NC]
RewriteRule .? http://
Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.
%{REQUEST_URI}?
[R=301,L]
Php Yöntemi
PHP:list($adres2) = explode("?ref", $_SERVER ['REQUEST_URI']); $adresim = "http://". $_SERVER ['SERVER_NAME'].$adres2; if (eregi('ref=', $_SERVER ['REQUEST_URI'])) { header( "HTTP/1.1 301 Moved Permanently" ); header("Location: ". $adresim); }
çok uzun video çek xd
Konu Sahibi
Konu Sahibi
- Katılım
- 24 Tem 2009
- Konular
- 61
- Mesajlar
- 782
- Çözüm
- 5
- Reaksiyon Skoru
- 35
- Altın Konu
- 0
- TM Yaşı
- 16 Yıl 10 Ay 18 Gün
- Başarım Puanı
- 117
- Yaş
- 35
- MmoLira
- 112
- DevLira
- 3
Öneriniz için teşekkürler
