Angelo on numara yazı olmuş. Teşekkürler.

Bu bağlamda benim kullandığım filtreleme şu şekildedir. Galiba aşağıda uyguladığım filtreleme yeterli oluyor. Angelo bu bağlamda da bir bakar ve evet yeterlidir veya değildir diye de yorumlarsa memnun olurum. PHP:

phpye başlayalı 2 ay fln oldu ve bir mp3 scripti yazdım ama güvenliğin 0 olduğunu düşünüyorum makaleler araştırıyorum inşallah bu güvenlik olayını çözerim

Sadece verileri filtrelemekten ziyade diğer bazı açıklarda ciddi zararlar verebiliyor. Durum böyle olunca 13 yaşındaki velet ben heckırım diye dolanıp gece gündüz emek harcayıp oluşturduğumuz siteye zarar verebiliyor. Benim de önerebileceğim diğer önlemler : 1- Verilerinizi kendi panelinizden silerken bile tek kullanımlık bir jeton oluşturmanız. CSRF açığını engellemiş olursunuz. Bu yöntemi get ve post yöntemlerinde uygulayınız. 2- Form action kısmında düz bir şekilde $_SERVER kullanmayınız. Bu da açığa sebep olur. 3- php. ini yapılandırmanızı sağlam hale getirmelisiniz. Özellikle disable_functions kısmına dikkat ediniz. 1. ve 2. maddeler için sitemde makale yazmıştım. Kısmetse 3. madde için de yazacağım... 1. maddenin makalesi : http://www.sametozden.com/PHP_ve_CSRF_acigi-18-sayfalar.html 2. maddenin makalesi : http://www.sametozden.com/Formlarda SERVERPHP_SELF_kullanimindaki_tehlike-23-sayfalar.html

1) Kullanıcı Input Kontrolü Web siteniz üzerine kullanıcıdan gelen her türlü veriyi mutlaka filtrelemeniz gerekir. $_POST, $_GET, $_COOKIE gibi kullanıcılardan gelebilecek veriler sistemde dosya açma, veri tabanı işlemlerinde kullanılıyorsa mutlaka kullanıldıkları alana uygunlukları kontrol edilmelidir. Örneğin navigasyonu, index. php?sayfa=XXXX şeklinde kurulmuş bir programın kodları aşağıdaki şekilde yazılırsa. PHP:

İkinci filtre için htmlspecialchars kullanılabilir. Bir de scripti komple değiştirmene gerek yok, mesela bir yorum formu ise bu, script kelimesi kullanılabilir bence kullanıcı tarafından. SQL komutlarında addslashes ya da real escape'e ek olarak, stringi doğrulamaya sokmak da gerekebilir çoğu zaman. Uygulamaya bağlı. Yani aslında genel bir koruma yok. Koda göre her türlü string doğrulamadan geçmeli. Dediğim gibi. Diğer türlü enjeksiyonlar için addslashes fonksiyonu ile tırnaklar escape edilmeli, her türlü form girdisi, programın beklediği özellikleri taşıyıp taşımadığına dair kontrol edilmelidir. Integer bekliyorsan, integer. 5 harfli string bekliyorsan 5 harfli string. Beklediğinden değişik birşey geliyorsa, %1 ihtimalle kod da kırıklık vardır, %99 ihtimalle biri birşeyler yapmaya çalışıyordur zaten. Tırnağa bağlı olmayan sorgu tipleri olabilir, onlara tırnak içermeyen bir SQL enjeksiyonu yapabilir. Örnek yazmıştım ama, gerek yok şimdi hek için yol öğretmek gibi olmasın diye sildim. mysql real escape string bir çok durumda kurtarır ancak kod yapısına bağlı. En güzeli, ID alıyorsan url'den integer olup olmadığını kontrol etmen. Veya başka türlü yapılar için ona göre kontroller.

GET ile aldiginiz bilgi sadace RAKAM ise asagidaki sekilde kullanin: $degisken= $_GET ;

inceleme sansimiz olursa bir kac sey onerebiliriz

Eline sağlık Angelo başlangıç için güzel bilgiler vermişsin.

ellerine sağlık çok güzel yazmışsın