PHP açıkları, bir web sitesini yetkisiz erişime, veri hırsızlığına veya kesintiye maruz bırakabilen PHP çalışma zamanı, uygulama kodu, üçüncü taraf paketleri veya sunucu yapılandırmasındaki zayıflıklardır. Yaygın örnekler arasında SQL enjeksiyonu, siteler arası betik çalıştırma, güvensiz dosya yüklemeleri ve bozuk erişim kontrolleri bulunur.
Fark, önemlidir çünkü düzeltmeler farklıdır. Çalışma zamanı güvenlik açığı, yamalanmış bir PHP derlemesi gerektirir. Yetkilendirme hatası, kod veya politika değişikliği gerektirir. PHP'yi güncellemek esastır, ancak üzerinde oluşturulmuş bir web sitesindeki her zayıflığı otomatik olarak onarmaz.
Kripto hizmetleri için riskler arasında para çekme kontrolleri, API kimlik bilgileri ve cüzdan kullanıcılarına gösterilen işlem ayrıntıları yer alabilir. Ele geçirilmiş bir web sitesi, Bitcoin'in mutabakat kurallarının veya bir blok zincirinin kriptografisinin bozulduğu anlamına gelmez.
Desteklenen, Yamalanmış Yazılımlarla Başlayın
Güvenlik güncellemesi, 22 Ekim 2026: PHP'nin 21 Ekim tarihli uyarısı, iki kritik uzaktan kod yürütme açığını, CVE-2026-109618 ve CVE-2026-109619'u belirledi. Desteklenen dallar için düzeltilmiş sürümler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 idi. PHP ekibi kullanıcılara güncelleme yapmaları konusunda çağrıda bulundu; geçici azaltmalar yamalamanın tam bir ikamesi değildir. resmi güvenlik duyurusunu ve barındırma sağlayıcınızın rehberliğini kontrol edin.
Uygulanabilir düzeltilmiş sürümü veya daha sonraki yamalanmış kararlı bir sürümü kullanın. Dağıtım satıcıları güvenlik düzeltmelerini geriye dönük olarak uygulayabilir, bu nedenle yalnızca sürüm dizesine göre değil, paketin uyarı durumunu doğrulayın. Web sunucusu çalışma zamanının (sadece komut satırı PHP'nin değil) güncellendiğini ve ilgili işçilerin yeniden başlatıldığını onaylayın.
Ayrıca bir yükseltme planı sürdürün. PHP 8.2'nin ana destek güvenlik desteği 31 Aralık 2026'da sona eriyor; bu özel yamayı almak, normal destek yaşam döngüsünü uzatmaz.
SQL Enjeksiyonu: Sorgu Yapısından Veri Çıkarın
SQL enjeksiyonu, güvenilmeyen girdinin bir veritabanı komutunun parçası haline geldiğinde meydana gelir. Birincil düzeltme, kullanıcı girdisini SQL dizelerine eklemek yerine hazırlanan ifadeler aracılığıyla veri değerlerini bağlamaktır. PHP'nin PDO belgeleri ayrımı açıklar.
Örneğin, özel bir makale araması, doğrulanmış bir makale kimliğini ve kimliği doğrulanmış kullanıcının sunucu tarafı kimliğini bağlayabilir:
$stmt = $pdo->prepare(
'SELECT id, title FROM articles
WHERE id = :id AND owner_id = :owner'
);
$stmt->execute([
'id' => $articleId,
'owner' => $authenticatedUserId,
]);Yer tutucular veri değerlerini korur, keyfi tablo adlarını, sütun adlarını veya sıralama yönlerini değil. Bu seçimleri sabit, izin verilen değerlere eşleyin. Veritabanı ayrıcalıklarını da sınırlı tutun: uygulamanın genellikle tüm veritabanını yönetebilecek bir hesaba ihtiyacı yoktur.
Siteler Arası Betik Çalıştırma: Çıktı Bağlamı İçin Kodlayın
Siteler arası betik çalıştırma veya XSS, güvenilmeyen içeriğin yürütülebilir tarayıcı içeriği olarak yorumlandığında meydana gelir. Bir yorum, profil alanı veya içe aktarılan bir belge, bir sayfa bunu yanlış işlediğinde tehlikeli hale gelebilir.
Çerçevenizin otomatik kaçışını kullanın ve güvenilmeyen verileri yürütülebilir bağlamlardan uzak tutun. Sıradan HTML etiketleri arasına yerleştirilen düz metin için, PHP'nin htmlspecialchars() fonksiyonu açık UTF-8 kullanımıyla uygun bir araçtır. JavaScript, CSS veya URL'ler için evrensel bir çözüm değildir.
Kullanıcıların zengin HTML göndermesi gerekiyorsa, tüm girdiyi güvenilir olarak kabul etmek yerine, bakımı yapılan, izin listesi tabanlı bir HTML temizleyici kullanın. Bir İçerik Güvenlik Politikası başka bir katman ekler; içeriğin doğru şekilde işlenmesinin yerini tutmaz. Bu ayrımlar OWASP'ın XSS önleme rehberinde ele alınmaktadır.
Yüklemeler ve Dosya İşleme: Sunucunun Neleri Kabul Ettiğini Kontrol Edin
Bir yükleme özelliği, bir kullanıcının sunucuda hangi yürütülebilir dosyanın görüneceğine karar vermesine izin vermemelidir. Yalnızca ürünün ihtiyaç duyduğu dosya türlerine izin verin, tarayıcının beyan ettiği MIME türüne güvenmek yerine içeriği kontrol edin, boyut sınırları belirleyin ve sunucu tarafı dosya adları oluşturun.
Güvenilmeyen yüklemeleri web kökünün dışında veya ayrı depolamada, kontrollü erişimle saklayın. Sunma yapılandırmasının yüklenen içeriği yürütemediğinden emin olun. Kimlik doğrulama, yetkilendirme ve uygun kötü amaçlı yazılım veya içerik denetimi ek güvenlik önlemleri sağlar. OWASP'ın dosya yükleme rehberi bu kontrolleri birleştirmeyi önerir.
Aynı disiplini dosya yolları ve içe aktarmalar için de uygulayın. Kullanıcıya dönük belge kimliklerini, ham istek değerlerini dosya ekleme işlevlerine geçirmek yerine onaylanmış sunucu tarafı dosyalara eşleyin. Güvenilmeyen girdiyi kabuk komutlarına, veya PHP nesne serbest bırakma işlemine beslemekten kaçının. Daha güvenli API'ler ve doğrulanmış veri formatları bu tehlikeli işlemlerin ihtiyacını azaltır.
Kimlik Doğrulama, Oturumlar ve CSRF Ayrı Kontroller Gerektirir
Kimlik doğrulama, bir kullanıcının kim olduğunu belirler; yetkilendirme, o kullanıcının ne yapabileceğine karar verir. Çalışan bir giriş sayfası, hesap kayıtlarının, indirmelerin veya yönetimsel eylemlerin korunduğunu kanıtlamaz. Her hassas işlem ve nesne için sunucuda izinleri kontrol edin.
password_hash() ve password_verify() gibi yerleşik parola işleme işlevlerini kullanın, MFA ile ayrıcalıklı hesapları koruyun ve kötü niyetli oturum açma girişimlerini sınırlayın. Oturumlar için HTTPS'yi zorunlu kılın, uygun Güvenli, HttpOnly ve SameSite çerez özniteliklerini yapılandırın, kimlik doğrulama veya ayrıcalık değişikliklerinden sonra oturum tanımlayıcılarını yenileyin ve oturum kapatıldığında oturumları geçersiz kılın. Özel bir oturum şeması icat etmek yerine OWASP'ın oturum yönetimi rehberini izleyin.
Çerez tabanlı kimlik doğrulamasıyla yapılan, durumu değiştiren istekler ayrıca CSRF koruması gerektirir. Mümkün olduğunda sunucu tarafı belirteç doğrulaması dahil olmak üzere çerçevenin bakımı yapılan uygulamasını tercih edin. SameSite çerezleri, derinlemesine savunma için kullanışlıdır, ancak her dağıtımı veya istek akışını koruduğu varsayılmamalıdır. Hassas durum değişiklikleri yapmak için GET isteklerini kullanmayın.
Yapılandırma ve Bağımlılıklar Uygulamanın Parçasıdır
İyi yazılmış bir denetleyici bile güvensiz bir dağıtımın içinde yer alabilir. Kimlik bilgilerini, özel anahtarları, yapılandırma sırlarını ve yedekleri genel dizinlerden uzak tutun. Üretimde ayrıntılı hata görüntülemeyi devre dışı bırakın, ancak gereksiz sırları toplamadan hataları araştırmaya yardımcı olan erişim kontrollü günlükleri saklayın.
Tam bağımlılık envanterini gözden geçirin: PHP çalışma zamanı, uzantılar, çerçeve, CMS, eklentiler ve Composer paketleri. Composer'ın audit komutu, bağımlılıklardaki bildirilen güvenlik sorunlarını belirleyebilir, ancak özel uygulama mantığının güvenli olduğunu onaylayamaz.
Güncellemeleri uygulamaya karşı test edin ve incelenmiş bağımlılık sürümlerinden tekrarlanabilir şekilde dağıtın. Kullanılmayan bileşenleri sonsuza kadar maruz bırakmak yerine kaldırın. Bir uygulama işleminin sunucudaki her şeyi yeniden yazmasını önleyecek şekilde dosya sistemi izinlerini kısıtlayın ve geliştirme araçlarını üretimden ayırın.
PHP Açıkları Kripto Web Sitelerini Nasıl Etkileyebilir?
Bir kripto web sitesinin uygulama katmanı, bağlandığı blok zincirinden ayrı olarak saldırıya uğrayabilir. Aşağıdakiler, adlandırılmış bir borsa veya cüzdan hakkındaki bulgular değil, mimari risk senaryolarıdır.
| Kripto riski | Ne yanlış gidebilir | Pratik kontrol |
|---|---|---|
| Saklama hesabı veya para çekme suistimali | Ele geçirilmiş oturumlar veya zayıf sunucu tarafı yetkilendirme | Hassas eylemleri yeniden kimliklendirin ve onayı tam alıcıya ve miktara bağlayın. |
| Para yatırma adresi veya imzalama aldatmacası | Değiştirilmiş web sayfası içeriği veya yanıltıcı işlem açıklamaları | Güvenilir bir cüzdan arayüzünde veya okunabilir bir donanım cüzdanı ekranında ağı, alıcıyı, varlığı ve miktarı doğrulayın. |
| API kimlik bilgisi maruziyeti | Kod, günlükler veya genel dosyalar aracılığıyla sızdırılan sırlar | Anahtarları sunucu tarafında tutun, izinleri dar kapsamlı tutun, gereksiz olduğunda para çekme haklarını hariç tutun ve maruz kalan kimlik bilgilerini döndürün. |
Özel bir anahtarı korumak, onu kullanma kararını otomatik olarak korumaz. Trezor'un net imzalama rehberi, ele geçirilmiş bir ön ucun bir işlemi neden yanlış tanımlayabileceğini açıklar. Anlamlı bir şekilde doğrulayamadığınız istekleri onaylamayın veya güvenlik güncellemesi gerektiğini iddia eden bir web sitesine tohum ifadesi girmeyin.
İlgili yamayı veya kod değişikliğini uygulayın, ardından hem güvenlik kontrolünü hem de normal kullanıcı davranışını test edin. Negatif testler ekleyin: bir kullanıcı, yalnızca bir tanımlayıcıyı değiştirerek başkasının kaydına erişmemelidir. Güvenlik testlerini yalnızca sahip olduğunuz veya değerlendirmek için açıkça yetkilendirildiğiniz sistemlere karşı çalıştırın.
Ele geçirme şüphesi varsa, yamalama kurtarmanın yalnızca bir parçasıdır. Olayı kontrol altına alın, yararlı kanıtları saklayın, kalıcılığı ve maruz kalan kimlik bilgilerini araştırın ve doğrulanmış temiz bir durumdan geri yükleyin. Bir güvenlik duvarı kuralı veya temiz tarayıcı sonucu, bir saldırganın erişiminin kaldırıldığını göstermez.
Sıkça Sorulan Sorular
PHP doğası gereği güvensiz midir?
Hayır. Risk, çalışma zamanı sürümüne, uygulama tasarımına, bağımlılıklara ve dağıtıma bağlıdır. PHP uygulamaları hala rutin güvenlik bakımı gerektirir.
PHP'yi yükseltmek SQL enjeksiyonunu ve XSS'yi düzeltecek mi?
Zorunlu değil. Çalışma zamanı güncellemeleri çalışma zamanı açıklarını düzeltir; güvensiz sorgu oluşturma ve çıktı işleme genellikle uygulama değişiklikleri gerektirir.
HTTPS PHP açıklarını önler mi?
Hayır. HTTPS, aktarım halindeki verileri korur. Bozuk izinleri, güvensiz yüklemeleri veya savunmasız sunucu tarafı kodu düzeltmez.
Web uygulama güvenlik duvarı yamalamanın yerini alabilir mi?
Hayır. Bazı maruziyetleri azaltabilir, ancak altta yatan yazılım kusurunu veya uygulama mantığını güvenilir bir şekilde onaramaz.
Sonuç
PHP açıklarının evrensel bir düzeltmesi yoktur. Çalışma zamanını ve bağımlılıkları yamalayın, veritabanı değerlerini SQL'den ayrı tutun, tarayıcı çıktısını güvenli bir şekilde işleyin, yüklemeleri kısıtlayın ve sunucu tarafı erişim kontrollerini zorunlu kılın.
Kripto uygulamaları için ayrıca para çekme yetkilendirmesini, API kimlik bilgilerini ve cüzdanla ilgili işlem ayrıntılarını koruyun. Her zayıflığı doğru kontrolle eşleştirin ve dağıtımdan sonra bu kontrolü doğrulayın. Güncellemeler, güvenli kodlama ve operasyonel izleme birlikte çalışır; hiçbiri diğerinin yerini tutmaz.
