PHP internette en çok kullanılan dillerden biridir. Bu nedenle geliştirici olarak bu dili bilmeniz size büyük avantajlar sağlar. PHP bazı bakımlardan C’ye ve Java’ya benzer, bu yüzden bu iki dili biliyorsanız PHP’de kolayca kendinizi geliştirebilirsiniz. Ancak, yeni bir dil öğrenirken muhtemelen bazı hatalar yapacaksınız. Aşağıda PHP geliştiricilerinin sık yaptığı hatalar ve bu hataları önlemek için yapılması gerekenler yer almakta.
- SQL Kodunu Sağlama Almamak
İnternette en sık yapılan siber saldırılardan biri SQL enjeksiyonlarıdır. SQL enjeksiyonu saldırılarında hackerlar veritabanınıza sizin yetki vermediğiniz bir SQL kodu yerleştirir, bu kodun çalıştırdığı komutlarla verilerinizi sızdırır, değiştirir veya silerler. Fakat bu saldırı riski daha iyi PHP programcılığıyla en aza indirilebilir.
PHP WordPress gibi çözümlerin omurgasını oluşturur. WordPress siteler için yeni uzantılar ve eklentiler yazan geliştiriciler çoğu zaman satır içi SQL ifadeleri oluştururlar. Bu ifadeler arka uçta oluşturulup SQL veritabanına geri gönderilir. Bu ifadeler yanlış oluşturulursa siteniz SQL enjeksiyonlarına açık hale gelebilir.
Bunu engellemenin iki yolu vardır. Birinci (ve en çok tercih edilen) yol hazır ifadeler kullanmaktır. İkinci yol ise parametreleştirilmiş sorgular kullanmaktır.
Aşağıdaki ifade kullanıcı girdisi üzerine inşa edilmiştir:
$stmt = (“SELECT * FROM users WHERE firstname = ‘”.$firstname.”‘;”);
Bu ifade sitenizi kırılgan bir hale getirir çünkü SQL enjeksiyonuna açıktır. Burada aşağıdaki gibi parametreleştirilmiş ve hazır ifadeler kullanmak daha güvenli olur:
$stmt = $dbConnection->prepare(‘SELECT * FROM users WHERE firstname = ?’);
$stmt->bind_param(‘s’,
$firstname); $stmt->execute();
Bunlar daha iyi yöntemlerdir çünkü SQL’de bir dize değerini açıp kapayan tick işareti bir açılış veya iptal karakteri değil, gerçek bir karakter olarak algılanır.
- Hataları Saklamak
PHP’de farklı hata seviyeleri vardır ama bu hataları kendiniz elle kodunuzun içine saklayabilirsiniz. Eğer bunlar kritik olmayan ve ciddi bir olumsuz etki yaratmayan hatalarsa bunu yapmak faydalıdır. Örneğin, PHP versiyonları hakkındaki uyarı mesajlarını saklayabilirsiniz.
“@” işareti hataları saklamak için kullanılır. Fakat bu özelliği dikkatli kullanın çünkü bazen bu öngörülemeyecek sorunlara neden olabilir. Diyelim ki bir uygulamayı çalıştırmak için gerekli olmayan bir include kodunuz var; bu kod tarayıcılarında yalnızca belirli bir bileşen olan kullanıcılar için opsiyonel olabilir. Bu durumda PHP dosyanızda aşağıdaki kodu kullanabilirsiniz:
(@include(“animation.php”))
Yukarıdaki kodda animation.php dosyasında hatalar olsa bile, bu hatalar gösterilmeyecek veya sistem günlüğüne girmeyecektir. Bu hata saklama yöntemi tutumlu ve temkinli bir şekilde kullanılmalıdır çünkü sistem günlüğüne girmeyen ve uygulamada kritik bir şey yaşanana kadar bulunamayacak bazı hatalar olabilir. Uzun vadede hataları saklamak yerine ele alıp düzeltmeye çalışmak daha iyidir.
- Veriyi Doğrudan Kullanıcı Girdisinden Yazdırmak
Bu hata biraz da yukarıdaki bir numaralı hatayla bağlantılıdır. İlk hata (SQL kodunu sağlama almamak) SQL enjeksiyonu güvenlik açıklarına yol açabilir. Bu hata geliştiricinin veriyi doğrudan bir kullanıcıdan yazdırdığı durumlarda ortaya çıkan çapraz site betik çalıştırma (XSS) güvenlik açıklarıyla bağlantılıdır.
Diyelim ki “isim” adında bir form girdisi metin kutunuz var. Betiğinizin kullanıcıya “Merhaba, $isim” yazmasını istiyorsunuz. Bunu aşağıdaki kodu kullanarak yapabilirsiniz:
Merhaba <?php echo $_POST[“isim”]; ?>
Peki, eğer kullanıcı “<script>alert(merhaba);</script>“ girerse ne olur? Bu kimsenin pek umursamayacağı ufak ve önemsiz bir pürüz gibi görünebilir ama sorun şu ki bu durumda JavaScript’in tarayıcıda rastgele çalışmasına izin vermiş olursunuz. JavaScript tarayıcıda kullanıcı girdisinden çalıştığında, saldırgan XSS kullanarak parolaları ve oturumları çalmak gibi birçok olay gerçekleştirebilir. Hackerlar betikler konusunda bazen çok yaratıcı olabiliyor ve oturum gaspı, phishing ve gizli yeniden yönlendirmeler gibi çok sayıda saldırı düzenleyebiliyorlar.
Kullanıcı girdisini yazdırmak yerine mutlaka çıktıdaki tüm HTML etiketlerini, özellikle de betik etiketlerini silin. Bu kötü amaçlı JavaScript kodunun kullanıcınızın bilgisayarında çalışmasını önler. Bu tip saldırılara XXS saldırısı adı verilir ve saldırganın tüm uygulamayı riske atabilecek bir JS kodu çalıştırmasını sağlar.
- Geliştirme Konfigürasyonlarını Kaldırmayı Unutmayın
Geliştiricilerin bir geliştirme ortamının, yani canlı koda ev sahipliği yapan ve üretim ortamını taklit eden bir staging ortamının olması gerekir. Geliştirici kimi zaman yaptığı işte zamana sıkışabilir ve geliştirme değişkenlerini ve konfigürasyonlarını kaldırmayı unutabilir, sonra da bunları yanlışlıkla üretim ortamına yükleyebilir. Bu da canlı bir uygulama için bir felaket olabilir.
Birçok yeni geliştirici staging ortamını atlayıp geliştirme aşamasından doğruca üretim aşamasına geçerek zamandan kazanmak ister. Bu bir hatadır çünkü staging geliştirme aşamasında fark etmemiş olabileceğiniz hataları tespit etmenizi sağlayabilir (unutmayın, staging üretimi taklit eder). Eğer yanlışlıkla konfigürasyonları kaldırmayı unutsanız veya staging aşamasına kadar hata bulamasanız da, bunları üretim ortamına varmadan yakalayabilmeniz mümkündür.
Mutlaka bir staging ortamınız olsun ve bunu yalnızca küçük değişiklikler yapıyor olsanız dahi kullanın. QA testerlarının kodu üretim aşamasına geçmeden, staging ortamında test etmesinde de fayda vardır.
- Bir Koşul Karşılaştırması Yerine Yanlışlıkla Atama Operatörünü Kullanmak
Durum ifadelerini yazarken yanlışlıkla yanlış operatörü kullanmak sık rastlanan bir durumdur. Sonuçta geliştiricilerin değişkenlere değer atama işlemi için saatlerce ekran başında oturduğu olur. Ancak, koşullu karşılaştırma yerine yanlışlıkla atama operatörünü kullanırsanız, hatalı kod yerleştirme riskini arttırırsınız.
Örneğin şu kodu ele alalım:
if ($condition = ‘value’)
//do something
Yukarıdaki kodda geliştirici yanlışlıkla ($condition) değişkenine “value” değerini atıyor. Bu durumda koşulun şöyle olması gerekir:
if ($condition == ‘value’)
//do something
Bu tip hataları yapmamak için bazı geliştiriciler “yoda sentaksını” kullanmayı tercih eder. Yoda sentaksı koşulun ve değerin sırasını değiştirir. Yoda sentaksında yukarıdaki kod şu şekilde olacaktır:
if (‘value’ == $condition)
//do something
Bu durumda, eğer yanlışlıkla karşılaştırma yerine atama operatörünü kullanırsanız, derleyici size hata verir ve siz de bu hatayı düzeltebilirsiniz.
- Yedekleme Yapmayı Unutmak
Bu basit bir aşama olarak görülebilir ama birçok geliştirici yedekleme yapma konusunda ihmalkardır. Her saat başı yedekleme yapmanıza gerek yoktur ama eğer bir projede önemli işler yaptıysanız her günün sonunda yedekleme almanız gerekir. Yedekleme yapmanın sizi olası aksaklıklar sonucunda veri kaybettiğiniz durumlarda saatlerce yeniden kod yazma zahmetinden kurtaracağını unutmayın.
Eğer kodunuzdaki sorunu tespit etmekte zorlanıyorsanız, sistemi yedekleyin ki çözümü kaybetmeyesiniz ve saatlerce uğraştığınız bir kodu sil baştan yazmak zorunda kalmayasınız.
Ayrıca müşterinizin kritik bir sorun yaşaması ve bir yedeğinin olmadığı nadir durumlar için de müşterileriniz için yedekleme yapmalısınız. Bu hem güzel bir jesttir hem de müşterinizi olası bir zor durumdan kurtaracaktır.
Sonuç
Geliştiricilerin çoğu PHP öğrenirken bu hataları sık sık yapar. Bu yeni bir dil öğrenme sürecinin bir parçasıdır. Her şeyde olduğu gibi, ne kadar çok pratik yapılırsa mükemmele o kadar yaklaşılır. Bir hata yaptığınızda o hatadan ders almalı ve aynı hatayı gelecekteki uygulamalarınızda tekrar etmemek için gerekli önlemleri almalısınız. Bu hataların bazıları önemli bazıları önemsiz olacaktır ama bu liste en sık yapılan hataların bazılarını yapmamanızı mutlaka sağlayacaktır.