Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Bir site “çalışıyor” diye güvenli sayılmaz. Özellikle hızlı geliştirilen veya yapay zekâ yardımıyla üretilen PHP projelerinde dosya yükleme, yetkilendirme, çıktı encode etme, prepared statement, CSRF, session ve gizli anahtar yönetimi gibi katmanlar atlanabilir. Bu rehber saldırı payloadı öğretmek yerine geliştirici ve site sahibinin hangi kontrolleri uygulaması gerektiğini, nedenini ve güvenli örnek yaklaşımı açıklar.
Kod üretim araçları geliştirmeyi hızlandırır fakat modelin ürettiği kod kullanılan framework sürümünü, deployment politikasını veya uygulamanın gerçek trust boundary’lerini her zaman bilmez. “Çalışan” bir upload endpoint’i authorization, MIME doğrulaması veya webroot dışı saklama olmadan da çalışabilir.
İncelemede yalnız tek dosya değil, route → middleware → controller → storage → database zinciri takip edilir. Authentication ve authorization ayrılır; kullanıcı giriş yapmış olsa bile başka kullanıcıya ait kaynaklara erişememesi gerekir.
OWASP File Upload Cheat Sheet; izin verilen uzantı listesi, Content-Type’a tek başına güvenmeme, dosya imzası kontrolü, uygulama tarafından üretilen dosya adı, boyut limiti, yalnız yetkili kullanıcılar ve mümkünse webroot dışı depolamayı birlikte önerir.
Sadece “.php yasak” blacklist yaklaşımı yeterli değildir. Çift uzantı, alternatif handler uzantıları, yanlış MIME kontrolü, dosya adındaki özel karakterler ve web sunucusunun upload klasöründe script çalıştırması ayrı ayrı değerlendirilir. Uygulama gerçekten sadece JPEG/WebP kabul ediyorsa allowlist’i iş ihtiyacına göre daraltmak gerekir.
XSS savunması girdiyi “bir kere temizlemekten” çok çıktının kullanıldığı bağlama göre encode edilmesine dayanır. HTML body, attribute, JavaScript, CSS ve URL bağlamları farklı kurallara sahiptir. HTML kabul edilen alanlarda güvenilir bir sanitization kütüphanesi gerekir.
Admin panelinde görünen müşteri adı, ürün açıklaması, yorum, arama kelimesi veya log viewer içeriği stored/reflected XSS yüzeyi olabilir. CSP yararlı ek katmandır fakat güvenli output encoding’in yerine geçmez.
PDO ile sorgu kurmak güvenli olmanın garantisi değildir; kullanıcı girdisi hâlâ string birleştirme ile SQL’e eklenebilir. OWASP birincil savunma olarak parameterized queries / prepared statements kullanımını önerir.
ORDER BY, tablo/kolon adı gibi parametreleştirilemeyen dinamik parçalar allowlist ile seçilmelidir. Veritabanı hesabına uygulamanın ihtiyacı olmayan DROP/FILE gibi yüksek yetkileri vermemek etkiyi azaltır.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
$sorgu = $pdo->prepare("SELECT id, ad FROM kullanicilar WHERE email = :email LIMIT 1");
$sorgu->execute([':email' => $email]);shell_exec, system, exec, passthru, proc_open gibi fonksiyonlar doğrudan kullanıcı girdisiyle birleşiyorsa risk çok yüksektir. OWASP mümkünse işletim sistemi komutu çağırmak yerine dil veya kütüphane API’lerinin kullanılmasını önerir.
Komut gerçekten zorunluysa sabit executable, sabit argüman şeması, allowlist, düşük yetkili servis hesabı ve timeout gibi ek kontroller gerekir. “escapeshellarg ekledim bitti” yaklaşımı iş mantığı ve argüman enjeksiyonu risklerini tek başına çözmez.
Authentication kullanıcının kim olduğunu, authorization ise o kaynağa erişme hakkını doğrular. Bir endpoint yalnız session var mı diye bakıp id parametresini doğrudan sorguluyorsa yatay yetki aşımı oluşabilir.
Her kaynak sorgusu mümkünse mevcut kullanıcı/tenant kapsamına bağlanmalıdır. Admin işlemleri role/permission kontrolleriyle ayrılmalı; yalnız butonu arayüzden gizlemek güvenlik değildir.
Oturum cookie’si tarayıcı tarafından otomatik gönderildiği için kritik state-changing işlemler CSRF korumasına ihtiyaç duyabilir. Token doğrulaması, SameSite cookie ve Origin/Referer politikaları uygulama yapısına göre birlikte ele alınır.
Silme, e-posta değiştirme, ödeme hesabı güncelleme, admin rol verme ve dosya yükleme gibi işlemler özellikle kontrol edilir. GET isteğiyle veri değiştiren endpoint’lerden kaçınılmalıdır.
Session cookie’lerinde Secure, HttpOnly ve uygun SameSite ayarı; login sonrası session ID yenileme; logout’ta session invalidation; brute-force/rate limit ve MFA kritik yönetici hesaplarında temel kontrollerdir.
Parolalar password_hash/password_verify ile modern algoritmalar kullanılarak saklanmalı; düz metin, MD5 veya SHA1 parola saklama tercih edilmemelidir. Reset token’ları tek kullanımlık, süreli ve tahmin edilemez olmalıdır.
.env, .git, SQL dump, .zip backup, log dosyaları ve debug stack trace public webroot altında erişilebilir olmamalıdır. API key ve database parolaları repository içine hard-code edilmemeli, production secret yönetimi ayrı tutulmalıdır.
Hata mesajında absolute path, SQL, token veya framework debug toolbar görünmesi saldırgana gereksiz bağlam verir. Production’da debug kapalı, loglar ise ziyaretçiye kapalı fakat teknik ekibin erişebileceği şekilde tutulmalıdır.
PHP’nin güncel resmi destek tablosuna göre Ağustos 2026 itibarıyla 8.2 güvenlik desteğinde; 8.3, 8.4 ve 8.5 desteklenen dallardır. PHP 8.1 ise Aralık 2025’te kullanım ömrünü tamamladı. Uygulama uyumluluğu test edilmeden körlemesine sürüm yükseltmek yerine staging üzerinde migration testi yapılmalıdır.
Eski PHP tek başına sitenin hacklendiğini göstermez fakat yeni güvenlik düzeltmelerini alamayan runtime uzun vadeli risk oluşturur. Framework, Composer paketleri ve eklentiler de ayrı EOL/CVE takibine ihtiyaç duyar.
Uygulama kullanıcısına yalnız gerekli yazma dizinleri açılmalı; tüm proje 777 yapılmamalıdır. Upload ve cache gibi yazılabilir dizinlerde PHP/script execution mümkün olduğunca kapatılmalıdır.
Web server, PHP-FPM pool ve deployment kullanıcısı ayrıştırılabiliyorsa saldırı etkisi azalır. Admin panel, database yönetimi ve SSH erişimi doğrudan internete açık bırakılmamalı; firewall/VPN veya IP policy seçenekleri değerlendirilmelidir.
Kod tabanı ve deployment bilgisi alınır; authentication/authorization, upload, input/output, database, dosya sistemi, command execution, secrets, dependency ve server config katmanları risk bazlı incelenir. Statik bulgular çalışma akışıyla doğrulanır.
Yetkilendirilmiş staging kopyasında kontrollü negatif testler yapılabilir. Amaç zararlı payload dağıtmak değil, kontrollerin beklenen hatalı girdiyi güvenli biçimde reddettiğini kanıtlamaktır. Teslimatta kritik/yüksek/orta/düşük bulgular, etkilenen dosya/endpoint, düzeltme önerisi ve tekrar test sonucu yer alır.
Ağustos 2026 resmî PHP destek takvimine göre genel durum. Dağıtım sağlayıcınız backport uyguluyorsa ayrıca sağlayıcı politikasını kontrol edin.
Standart vakalar ön inceleme sonrasında genellikle 24–72 saatlik analiz planına alınır. Süre; dosya sayısı, log erişimi, zararlı kodun yayılımı ve uygulamanın yapısına göre değişebilir.
Önemli not: Yalnız size ait veya açıkça yetkilendirildiğiniz sistemlerde test yapın.
Hayır. Ancak üretim öncesi aynı secure code review ve test disiplininden geçmelidir.
Hayır. Allowlist, MIME/signature, filename, storage, auth ve execution policy gibi katmanlar birlikte gerekir.
Prepared statement doğru kullanılırsa güçlü savunmadır; string birleştirme devam ediyorsa risk kalabilir.
Hayır. Defense-in-depth katmanıdır; bağlama uygun output encoding ve sanitization yine gerekir.
PHP resmi tablosuna göre 8.1, 18 Aralık 2025’te EOL oldu.
Dış yüzey kontrolü yapılabilir fakat kaynak kod güvenlik analizi için kod tabanı veya yetkili erişim çok daha fazla doğruluk sağlar.