Hala uzmansorusu.com‘da sorulan soruların ciddiye alınacak bir kısmında, üniversiteye gelen stajerlerde, hatta çalışma fırsatım olan arkadaşlarda bu konuda bir bilgisizlik var…

Aslında bu blog’a başlarken ileri düzey konulara, framework’lere falan değineyim istemiştim ama pes ediyorum artık. Şuraya yazayım da en azından lazım olduğunda al oku işte diye adresini veririm :)

SQL Injection Nedir?

Türkçeye çevirirsek SQL’in içine zehir enjekte edilmesidir diyebiliriz. Örnek vermek gerekirse elimizde bir kullanici_detay.php dosyası olsun:

$query = mysql_query("select * from users where id=".$_GET['id']);

satırını ele aldığımızda, $_GET['id']‘nin bir sayı olduğunu farz ederiz ve kod düzgün çalışır. Bu sayfanın adresi de şöyle birşeydir

http://www.huysuzadam.com/kullanici_detay.php?id=5

Peki ben uyanıklık yapıp adres satırını şöyle değiştirirsem:

http://www.huysuzadam.com/kullanici_detay.php?id=1 or 1=1

Bu durumda sql cümlesi şöyle birşeye dönüşmüş olur:

SELECT * FROM users WHERE id=1 OR 1=1

1=1 önergesi her zaman doğru döndüreceği için tüm kullanıcıları listeletebilirim bu durumda…

Ne Zararı Olur?

Tüm kullanıcıları görse nee, görmese ne diyebilirsiniz. Peki bu güvenlik açığı ile neler yapılabilir?

Az önceki örneği değiştiriyorum, bu sefer biraz daha karışık işlere girelim:

$username = $_POST['username'];
$passwd = $_POST['passwd'];
 
$query = mysql_query("select * from users where username='$username' and passwd='$passwd' ");

Bu sefer bir hacker olarak $_POST['username'] değişkenini yine uyanıklık yaparak aynen şöyle gönderiyorum:

a' or 1=1 or 'b

yerine koyduğumuzda sql’imiz şu hale gelmiş oluyor:

SELECT * FROM users WHERE username='a' OR 1=1 OR 'b' AND passwd='asdf'

Gördüğünüz gibi OR’lar sayesinden herhangi bir kullanıcı olarak girebiliriz. SQL’in son hali kolay okunsun diye ben böyle girdim ama biraz yaratıcılık kullanılarak daha kısa ya da daha farklı yaramazlıklar yapılabilir.

Nasıl Önlememelisiniz : magic_quotes_gpc

PHP’nin eski versiyonlarında magic quotes gibi bir ayarla SQL injection’a çözüm ürettiğini zannetti Zend firması. Aslında bu daha sonra çok baş ağrısı yaratacak bir karardı ve o yüzden de PHP6′da yanılmıyorsam tamamen kaldırılacak bu özellik.

Magic Quotes şu şekilde çalışır:

php.ini’den magic_quotes_gpc aktif edilirse PHP otomatik olarak tüm $_GET, $_POST ve $_COOKIE değişkenlerinin içindeki tırnak işaretlerini \’ ve \” ile değiştirir. Bu durumda ikinci örneği ele alırsak sql şu hale gelmiş olur:

SELECT * FROM users WHERE username='a\' or 1=1 or \'b' AND passwd='asdf'

Bu durumda \ işareti yanındaki karakteri “escape” eder, yani tek tırnak işaretinin tırnağı kapama görevine son verir. Böylece veritabanı hakkaten de adı a\’ or 1=1 or \’b olan bir marslıyı (!) bulmaya çalışır.

Kırma girişimi başarısızlıkla sonuçlanır, dünya kurtulur.

Burada dikkat edilmesi gereken tek nokta, yazının başında verdiğimiz örnekteki gibi sayıları kontrol ederken de tırnak işareti kullanmamız gerekir.

Yani;

$query = mysql_query("select * from users where id=".$_GET['id']);

yerine

$query = mysql_query("select * from users where id='".$_GET['id']."'");

yazmamız gerekir.

Ancak sakın magic_quotes_gpc yönetimini kullanmayın!

Çünkü bu konuda iki büyük sorun var: Birincisi psikolojik olarak buna o kadar alışıyorsunuz ki sanki bu magic_quotes_gpc açıksa bir daha asla SQL injection yemezmişsiniz gibi geliyor. Sonra da biri gelip bu sefer de /* */ kullanarak SQL injection yapıyor. Ya da görünmez ASCII karakterleri ya da diğer muhtelif yöntemler.

(Not: Bu muhtelif yöntemleri burada tek tek yazmayacağım ki bu doküman bir “hacker’ın el kitabı”na dönüşmesin ;) )

İkinci büyük sorun da, hiç başınıza gelmeyecek zannetseniz de hosting değiştirme problemi. magic_quotes_gpc’ye güvenirken, bir anda bu ayarın kapalı duruma geldiğini düşünebiliyor musunuz? Kolay gerçekleşecek bir senaryo değil gibi gözükse de gayet olasıdır, tecrübeyle de sabittir!

3. daha önemsiz sorun ise, “Ozan’ın kalemi” gibi bir cümledeki tırnak işaretini de escape etmesi. Bu durumda veritabanına yazmadığınız durumlarda “strip_slashes” gibi bir işlem yapmanız gerekiyor ki bu da bazen inanılmaz can sıkıcı olabiliyor.

SQL Injection Nasıl Önlenir?

Gelelim sadede. Bunu yapmanın birkaç yöntemi var. Bana en makul gelenleri:

mysql_real_escape_string

Bu fonksiyon, değişkenlerin içindeki tüm zararlı karakterleri “escape” eder, yani güvenli hale getirir.

$_POST['username'] = mysql_real_escape_string($_POST['username']);
$_POST['passwd'] = mysql_real_escape_string($_POST['passwd']);

şeklinde kullanılır.

Avantajları:

1. Ekstra bir kütüphaneye falan gerek yok, doğrudan kullanılabilir.

Dezavantajları:

1. Yazması çok sıkıcı
2. MySQL’den başka veritabanı kullanırsanız ne olacak?

Bind etme yöntemi

Aslında bunu mysql konutları ile yapmak da mümkün, ama zahmetli olduğu için bir database wrapper kullanarak yapılışını anlatacağım.

Bir database wrapper ya da PDO kullanılır. Örneğin Zend_Db kullanalım:

require_once '/var/lib/ZendFramework/Zend/Db.php';
$db = Zend_Db::factory('Mysqli', array(
    'username' => 'myuser',
    'password' => 'mypass',
    'dbname' => 'mydbname',
    'driver_options' => array(MYSQLI_INIT_COMMAND => 'SET NAMES UTF8;')
));
 
$user = $db->fetchRow("select * from users where id=?", $_GET['id']);

Avantajları:

1. Soru işaretinin yerine değişkenimiz güvenli bir şekilde yerleştirildi.
2. “fetchRow” metodu sayesinde sadece 1 satır çekilip $user’a eşitlendi. Dolayısıyla mysql_fetch_row vs. yazmanıza da gerek kalmadı.
3. MySQL sorguyu cache’leyebildi. Direkt değişkeni yazdığınızda veritabanı onu cache’leyemez.

Dezavantajı:

1. Yeni birşey öğrenmek ve uygulamak gerekiyor. Bu da aslında dezavantaj değil avantaj aslında ama anlayana ;)

1. SQL Injection
   SQL cümlesi içerisine parametre olarak gönderilen değişkenin saldırgan tarafından değiştirilerek gönderilmesiyle oluşan açıktır.
2. Session Fixation
   O an siteye giriş yapmış ziyaretçinin session id’sini bir şekilde alarak ziyaretçinin aktif session’ından yararlanma felsefesine dayalı bir güvenlik açığıdır.
3. Session Poisoning
   Programcının gönderilen parametreleri kontrolsüz bir şekilde session değişkenlerine ataması nedeniyle oluşan açıktır.
4. XSS (Cross Site Scripting)
   Saldırganın sayfaya bir açıktan yararlanarak javascript, css, html kodu yazabilmesi nedeniyle oluşan açıktır.
5. XSRF (Cross Site Request Forgery)
   Saldırganın o an siteye giriş yapmış ziyaretçiye farkında olmadan istediği aksiyonu yaptırması ile ilgili bir güvenlik açığıdır.
6. RFI (Remote File Inclusion) ve LFI (Local File Inclusion)
   Programcının gönderilen parametreleri kontrolsüz bir şekilde çalışan koda “include” etmesi nedeniyle oluşan bir güvenlik açığıdır.
7. Referrer Spoofing
   HTTP_REFERER ziyaretçinin bir önce ziyaret ettiği sayfayı tutan bir environment değişkenidir. Ancak bu değişken istemci tarafından gönderildiği için bu değişkene dayanarak yapılan güvenlik kontrolleri kolayca aşılabilir.