• Bu site çerezler kullanır. Bu siteyi kullanmaya devam ederek çerez kullanımımızı kabul etmiş olursunuz. Daha fazla bilgi edin.

PHP de Güvenlik

Konuyu Okuyan Kişiler (0)

bykolcuoglu

webmaster.tc
Katılım
8 Ağu 2012
Mesajlar
144
Beğeniler
0
#1
PHP PHP script’lerinizin güvenli olduğundan emin olmanız için ilk olarak temel kuralları yerine getirmeniz gerekiyor: kullanıcı girdilerinin (input) filtrelenmesi ve çıktıların (output) kontrolü. Eğer bu ikisini doğru olarak yapmıyorsanız script’leriniz her zaman güvenlik problemleri ile karşı karşıya olacaktır. Bu makale’de bu iki işlem ile ilgili yapılması gerekenler anlatılıyor.

Bütün girdileri filtreleyin
Script’leriniz harici bir kaynaktan girdi okuduğunda, bu verinin tehlikeli olduğu varsayılmalı ve güvenilmemelidir. Güvenilmemesi gereken değişkenlerden bazıları: $_POST, $_GET, $_REQUEST ve hatta pek mümkün görünmese de önemli veriler içerebilecek olan $_SERVER .

Tehlikeli bir değişkenden gelen veriyi işlemlere tabi tutmadan önce ilk olarak önce onaylanamanız ve filtrelemeniz gerekmektedir. Onaylama işlemi ile sadece sizin istediğiniz verileri içerdiğinden emin olabilirsiniz. Örneğin bir eposta adresi bilgisi bekliyorsanız, onay fonksiyon’unuz girilen verinin doğru bir eposta adresi olup olmadığını kontrol etmeli.

Hemen basit bir örnekle açıklayalım. Aşağıdaki kodda ilk olarak $_POST değişkeninden e-posta adresini alıyorum ve sonra veriyi onaylama işlemine sokuyorum:

<?php
$eposta = $_POST['eposta']; # Burada veri hala TEHLİKELİ durumda
// Validate e-mail
if (valid_eposta($eposta) == false) {
// Geçerli bir adres değil
die('Geçerli bir eposta adresi değil!';
}
?>
Veriyi kontrol ederek script’imize tehlikeli verilerin eklenmesi riski büyük ölçüde azaltılmış oldu. valid_eposta() fonksiyon’u PHPit Code Snippet veritabanında da bulunabilecek olan standart bir onay işlemidir.

Verimiz daha güvenli olsa da işimiz daha bitmedi çünkü hala veriyi MySQL veritabanına yerleştirmek istiyoruz ve bu işlemden önce de bazı kontroller yapmamız gerekiyor. PHP tüm önemli karakterlerin escape edildiği mysql_real_escape_string() standart fonksiyon’unu sunar. Diğer bir yöntem ise SQL sorgusunda veriyi her zaman kesme imleri arasına yerleştirin.

Önceki örneğimize devam edelim:

<?php
$eposta = $_POST['eposta']; # Burada veri hala TEHLİKELİ durumda

// Validate e-mail
if (valid_eposta($eposta) == false) {
// Geçerli bir adres değil
die('Geçerli bir eposta adresi değil!';
}

// eposta'nın veritabanı için güvenli hale getirilmesi
$eposta = mysql_real_escape_string($eposta);

// Artık güvenli!
?>
Artık elimizdeki eposta verisi veritabanına güvenli bir şekilde işlenebilir. Hatalardan kaçınmak için tehlikeli değişkenlere bir ön ek verilebilir, örneğin:

<?php
$t_eposta = $_POST['eposta']; # Tehlikeli

// Onay işlemi

$g_eposta = mysql_real_escape_string($d_eposta);
?>
Bu şekilde tehlikeli bir veriyi işleme sokarken ön tarafındaki t_ eklentisi ile hemen farkına varabilirsiniz.

Çıktıların filtrelenmesi
Girdilerde olduğu gibi dışarıya sunulan tüm verilerin de (güvenli olarak filtreleyip veritabanına işlediğiniz verilerin dahi) filtrelenmesi gerekmektedir.

Filtrelenmesi gereken en önemli şey probleme yol açabilecek olan HTML tag’leridir. Bunu yapmanın en kolay yolu bütün HTML’i escape işlemine sokan htmlentities() fonksiyon’udur:

<?php
echo htmlentities($_GET['eposta']);
?>
Bu kod (saldırganın sayfalarınıza JavaScript kodları eklemesine ve diğer kullanıcıların cookie’lerini çalmasını sağlayan) muhtemel XSS (çapraz site betik çalıştırma - cross site scripting) saldırılarını kaldırır. Eğer mümkünse, htmlentities fonksiyon’unun üçüncü argümanı’nı (encoding/charset tipi) da kullanmalısınız. Google’da HTML’i escape işleminde düzgün encoding ayarı yapmadığı için XSS saldırısından etkileniyordu. Google bu açığı 1 aralık’ta kapattı. Basitçe, her zaman encoding tipini belirlemelisiniz:

<?php
echo htmlentities($_GET['eposta'], ENT_QUOTES, 'UTF-8';
?>
Eğer bütün HTML tag’lerini filtrelemek istemiyorsanız, bazı tag’lere izin vermek istiyorsanız strip_tags() fonksiyon’unu kullanabilirsiniz. Fakat bu, <script> tag’lerini filtreleseniz dahi Javascript ekleme açıklarına karşı bir güvenlik problemi içerebilir. ör ( <div onclick=”alert(’Hi!’;”> .

Diğer bir yöntem de sadece sizin istediklerinizi filtrelemenize yarayacak kendi fonksiyon’unuzu yazmanız (veya internet’teki yüzlerce hazır fonksiyon’dan birini kullanmanız). Bu bazen en iyi yöntem olabilir fakat herhangi bir şeyi unutmanız durumunda güvenlik problemlerine yol açabilir.
 

egebilisim

webmaster.tc
Katılım
9 Ağu 2012
Mesajlar
348
Beğeniler
0
Konum
Ege-Aydın
#5
Bu olayda aslında bazı sunucu ayarları düzenlenmiş durumda. Sunucu post - get fonksiyonlarını yeniden konfigure ederek sql inj. tarzı lamer işlevlerini bloke edebiliyor. Kolay bir işlem olmasına karşın rakip sınıfına giren bir forumun sunucularında bile bu yapılmamış.
 

proghammer

webmaster.tc
Katılım
6 Ağu 2012
Mesajlar
517
Beğeniler
0
Konum
WebMaster
#6
Bu olayda aslında bazı sunucu ayarları düzenlenmiş durumda. Sunucu post - get fonksiyonlarını yeniden konfigure ederek sql inj. tarzı lamer işlevlerini bloke edebiliyor. Kolay bir işlem olmasına karşın rakip sınıfına giren bir forumun sunucularında bile bu yapılmamış.
rakip sınıfına giren bir forum

Orada herşey para olduğu için böyle şeylere bakılmaz hocam :)

sql inj. ciddi bir olaydır çoğu forum ve sayfa sırf bu açık yüzünden tarih olmuştur :D

Php profesyonel anlamda bilmem ama açık ve kullanma dendiğinde üstüme yoktur :D

ahh eski günler geldi aklıma :D
 

NaMLu

webmaster.tc
Katılım
8 Ağu 2012
Mesajlar
171
Beğeniler
0
Konum
404 - Not Found
#7
Bu olayda aslında bazı sunucu ayarları düzenlenmiş durumda. Sunucu post - get fonksiyonlarını yeniden konfigure ederek sql inj. tarzı lamer işlevlerini bloke edebiliyor. Kolay bir işlem olmasına karşın rakip sınıfına giren bir forumun sunucularında bile bu yapılmamış.
Sanırsam magic_quotes_gpc ayarından bahsediyorsun. Otomatik olarak escape ediyor tırnakları SQL inj. açığını kapatmak için ancak PHP grubu 5.4 sürümüyle bunu kaldırdı.

PHP: PHP 5.4.0 Release Announcement

Bu arada o rakip sınıfına giren forum artık bitti :)