PHP/CGI Güvenlik açıkları ve kötüye kullanımıPHP genelde dinamik içeriği olan http sunucularında kullanılan bir script dili. PHP`nin C ve Perl`e pek çok benzerliği var ancak biraz daha basitleştirilmiş. Web sitesi geliştirmekle alakası olmayan şeyler kaldırıldığı için bu PHP`yi çalışılması gereken güzel bir dil yapıyor.
Bu yazıda bir PHP mesajlaşma listesi yaparken rastladığım bazı güvenlik konularına değineceğim. Konuştuğum çoğu insan güvenliğin bir konu olduğunu bile düşünmemişlerdi ve script`lerini nasıl yapılandırdıklarının sitelerinin güvenliğini nasıl değiştireceğini düşünmemişlerdi bile.
Ana problem değişkenlerin web browser`dan PHP`ye nasıl geçirildiği. Değişkenler ve değerleri URL`ye ekleniyor ve aşağıdaki gibi oluyor:
http://host/dir/script.php?değişken1=değerBu değişken isimleri ve değerleri adres çubuğuna düzyazı olarak geçtiğinden bu değerler bir son kullanıcı tarafından orjinal amacından farklı olarak değişik işlemler yapması için kolaylıkla değiştirilebilir.
Pek çok site karmaşık olduğundan ve tekrar kullanılan script`ler içerdiğinden genelde bu fonksiyonlar standart bir include dosyasına konur. Yani tüm sitede değişiklik için tek bir dosyayı değiştirmek yeterli olur. Kullanıcı kimlik tanılama işlemleri genelde bu kategoriye girer. Kullanıcı kimliği bir kez onaylanır ve sonrasında güvenli içeriğe erişilebileceğini belirten bir değer script`lere geçirilir. Fakat hem güvenli hem güvensiz bölümleri olan bir sitede kimlerin kimlik tanılaması yapılacağının belirlenmesi gerekir. Kolay bir çözüm linklenenin ne olduğuna bağlı olarak güvenli yada güvensiz modu belirleyen bir değişkenin geçirilmesidir. Aynı şeyler her iki modda da çalıştırılabilir fakat bu muhtemelen birşey farkettirmez. Eğer mod güvenli ise ve login başarısızlığa uğrarsa script buna göre davranır. Eğer mode güvensiz ise (yada login başarılı ise) aynı ana fonksiyonlar çalıştırılır. Problem tabiki, kullanıcının sitede bir süre gezindikten sonra mod değerini değiştirirek login olmadan sitede gezinebileceğini farketmesinde. Bunu yetki gerektirmeyen bir bölümde mod değerinin ne olduğuna bakarak görebilirler. Sonra tüm yapmaları gereken bir önceki sayfanın adres çubuğunda bunu değiştirip o şekilde açmalarıdır. Web sitesi yada mesajlaşma listesi için çok sayıda kullanıcısı olan firmalar için, herhangi birisi hiçbir araç kullanmadan ve az bilgiyle sitelerini değiştirebileceğinden, tehlikeli bir durum yaratabilir.
http://host/dir/page.php?var1=val1&var2=val2&mode=sec (kullanıcı login olmalı)
http://host/dir/page.php?var1=val1&var2=val2&mode=ins (kullanıcının login olması gerekmiyor)
Bu problem, kimlik tanılama ile ilgili kodların ayrı bir dosyaya taşınmasıyla çözülebilir. Güvenli olduğu düşünülen dokümanlarda standart include dosyası yerine bu kullanılır ve eğer login başarılı ise standart dosyada kullanılır. Bu bir mod değişkenine olan ihtiyacı kaldırır.
Bir diğer problem, kullanıcıların submit edilen dokümanlardaki değerleri değiştirebilmesi. Bir mesajlaşma listesi düşünün: Bir kullanıcı sayfayı ziyaret eder, formu doldurur, submit`e basar, hemen içinde link olan bir email alır, ona tıklar ve listeye eklenir. Eğer bu kullanıcı kötü niyetli ise, link`deki URL`yi değiştirebilir ve başkasını listeye ekleyebilir. Bu bir kere yapılırsa problem değil fakat eğer bu iş için küçük bir JavaScript yazarsa ve mesajlaşma listesi onay emailini yollamadan önce sadece kullanıcı isminin var olup olmadığını kontrol ediyorsa, birisini yüzlerce yada binlerce kez ekleyebilir. Onay kısmı, hemen mail gönderdiği için mail bombalama aracı olarakda kullanılabilir. Kendi yazdığım mesajlaşma listesini denerken, IE ile html/javascript kullanarak uzaktaki bir bilgisayardan üniversitedeki mesaj kutuma dakikada 500 mail atabildim. Bu şekilde açığı olan çeşitli siteler bulunursa, belli başlı sunuculara karşı yakalanma riski olmayan ciddi bir saldırı gerçekleştirilebilir.
Bu da kolayca düzeltilebilir. Onaylamadan önce ve eklemeden önce kullanıcının varlığı kontrol edilmeli. Ayrıca (kullanıcı üye olana kadar) geçici kullanıcılara ait bir veritabanı olmalı. Bu liste periyodik olarak silinebilir fakat süre en az bir hafta olmalı. Ayrıca email adreslerinden yaratılan indekslerin kendiside onay linkinde bulunmalı, böylece kullanıcı eklenmeden önce adres değişkeni ve indeks değişkeni birbirini tutmalı. Bu geçici bir veritabanı kullanımı ihtiyacını kaldırır fakat hala değişiklik yapılmasına izin verebilir. O yüzden ben kendi yazdığımda geçici bir veritabanı ekledim.
Bu probleme pek çok PHP tabanlı mesajlaşma listesinde rastladım. ASP ve Perl olanlarında da mevcut. Bu açıklardan etkilenebilecek listeleri bulmak için Yahoo da arama kutusuna 'mail list' yazıyorum ve bulduklarımda kendi test hesabıma birden fazla onay mesajı göndermeyi deniyorum. Bu testler hızlı serverlarda 15 dakikadan az sürüyor. Bu ve benzeri açıklar PHP geliştiricilerinin (ve CGI geliştiricilerinin) program yapısının nasıl güvenlik açığı oluşturabileceğini düşünmesi için güzel örnekler.
CronoS`tan not: Bazı sitelerde rastlayabileceğiniz gibi, file= değişkeni girişlerde (web dokümanları ana dizininin dışındaki bir dokümana erişmede kullanılabilecek, ör. '..' , security.someuniv.edu.tr/belge.php?dokuman=../ gibi
) belirli bazı karakterleri filtrelemiyorsa yada düzgün erişim kontrolü yoksa tehlikeli olabiliyor.
Ptsi Haz. 22, 2009 11:20 pm
