WordPress güvenlik sorunları neden hiç bitmiyor?

WordPress güvenlik haberleri bir döngü hâlinde akar: bir eklentide açık bulunur, yüz binlerce site etkilenir, yama çıkar, herkes güncellemeye çağrılır, birkaç hafta sonra başka bir eklentiyle aynı haber yeniden yazılır. Bu döngü yıllardır sürüyor ve bitmeyecek. Bunun nedeni WordPress geliştiricilerinin kötü iş çıkarması değil — nedeni, WordPress güvenlik probleminin yapısal olması. Bugün bu yapıyı açalım; çünkü sorunu yapı düzeyinde anlamadan alınan her önlem, delik tekneye kova taşımaktır.

Sorun WordPress'in kendisi değil, kurduğu dünya

Hakkını teslim edelim: WordPress çekirdeği olgun bir yazılımdır. Arkasında deneyimli bir güvenlik ekibi vardır, açıklar genellikle hızla yamalanır ve otomatik güncellemeler yıllardır çekirdek için açık gelir. Yalnızca çekirdek WordPress çalıştıran, eklentisiz bir site nispeten güvenlidir.

Ama kimse öyle bir site çalıştırmıyor. WordPress'in değeri ekosistemidir: on binlerce eklenti, binlerce tema, her işe bir çözüm. Ve güvenlik sorunlarının ezici çoğunluğu tam da buradan gelir. Sektörde güvenlik firmalarının yıllık raporları bu tabloyu tekrar tekrar doğrular: bildirilen WordPress açıklarının ağırlıklı kısmı çekirdekte değil, eklentilerde ve temalardadır. Kesin oran yıla göre değişir ama tablo değişmez.

Neden? Çünkü ekosistem tanımı gereği denetimsizdir. Eklenti yazan herkes eklenti yayınlayabilir. Kimi eklentiyi güvenlik geçmişi güçlü bir şirket geliştirir; kimini bir kişi hafta sonu yazmış, iki yıldır güncellememiştir. Siteniz kurulduğu anda, bu farklı ellerden çıkmış kodların hepsi aynı yetkiyle çalışır. Sitenizin güvenliği en özenli eklentiniz kadar değil, en özensiz eklentiniz kadardır.

WordPress'in mimarisi neden saldırganların işine yarar?

Her sayfa, çalışan bir uygulamadır

WordPress'te bir ziyaretçi sayfayı her açtığında PHP kodu çalışır ve veritabanı sorgulanır. Bu, sitenizin internete açık, sürekli çalışan bir uygulama olduğu anlamına gelir. Çalışan uygulama, saldırı yüzeyi demektir: kod çalıştırılabiliyorsa, kötü niyetli biçimde çalıştırılmanın da bir yolu aranabilir. SQL enjeksiyonu, dosya yükleme açıkları, uzaktan kod çalıştırma — bu saldırı sınıflarının hepsi "ziyaret anında kod çalışan" mimarilere özgüdür.

Kapı herkes için aynı yerde

Her WordPress sitesinin yönetim girişi bilinen adrestedir: /wp-admin. Veritabanı yapısı standarttır, dosya düzeni standarttır, sürüm bilgisi çoğu sitede okunabilir durumdadır. Bu tekdüzelik saldırıyı sanayileştirir: bir açık bulunduğunda, saldırgan tek tek site incelemez; botlar interneti tarar, o açığı taşıyan her siteyi otomatik bulur ve otomatik sömürür. Sitenizin küçük olması sizi korumaz — saldırıların çoğu hedefli değil, taramayladır. "Bizim siteyi kim hackleyecek ki" sorusunun cevabı: kimse. Bir bot hackleyecek, sizi hiç tanımadan.

Popülerlik, ödülü büyütür

İnternetteki sitelerin büyük bölümü WordPress ile çalışır. Bir saldırgan için bu şu demektir: WordPress'te bulunan tek bir açık, milyonlarca potansiyel hedef üretir. Aynı emeği niş bir platforma harcamak rasyonel değildir. WordPress kötü olduğu için değil, en yaygın olduğu için en çok saldırılan platformdur — tıpkı en çok virüs yazılan işletim sisteminin en yaygın olanı olması gibi.

"Güvenlik eklentisi kurarız" neden yeterli değil?

WordPress güvenlik sorununa en yaygın cevap bir güvenlik eklentisi kurmaktır. Bu eklentiler işe yaramaz değildir; giriş denemelerini sınırlar, bilinen saldırı imzalarını engeller, dosya değişikliklerini izler. Ama yapısal bir tuhaflığı görmek gerekir: çözüm, sorunla aynı katmanda yaşıyor. Güvenlik eklentisi de bir eklentidir — aynı PHP ortamında, aynı yetkilerle çalışır. Sömürülen açık ondan önce davranırsa, koruyamaz. Nitekim güvenlik eklentilerinin kendilerinde açık bulunduğu vakalar da yaşanmıştır; bekçinin de aynı evde uyuduğu bir düzen bu.

Aynı şey öbür ritüeller için de geçerli:

• Sürekli güncelleme gerekli ama yorucudur ve kendi riskini taşır: güncelleme siteyi bozabilir, bu yüzden ertelenir, ertelendikçe açık pencere büyür.
• Yedekleme hasarı geri alır ama saldırıyı engellemez; veri zaten sızmışsa yedek onu geri getirmez.
• Web uygulama güvenlik duvarları trafiği süzer ama uygulamanın kendisindeki açığı kapatmaz.

Bunların hepsi tekneden kova ile su boşaltmaktır. Yapılabilir, yapılmalıdır da — WordPress'te kalacaksanız bu bakım disiplini pazarlık konusu değildir. Ama deliğin kendisi mimaridedir.

Bir de işin sessiz tarafı var: hacklenen WordPress sitelerinin önemli bölümü bunu fark etmez bile. Saldırganın amacı çoğu zaman siteyi çökertmek değil, onu kullanmaktır — spam sayfaları eklemek, ziyaretçileri başka adreslere yönlendirmek, arama sonuçlarına ilaç ve bahis linkleri sızdırmak. Site sahibine her şey normal görünür; hasarı ilk fark eden genellikle Google olur ve siteyi "bu site hacklenmiş olabilir" etiketiyle cezalandırır. Yani fatura, olay gününde değil, haftalar sonra ve itibar cinsinden kesilir.

Peki mimari düzeyde çözüm ne?

Bir saldırının çalışması için üç şeye ihtiyacı vardır: ulaşabildiği çalışan kod, sorgulayabildiği bir veritabanı, deneyebildiği bir giriş kapısı. Modern statik mimari bu üçünü de ziyaretçinin erişebildiği yüzeyden kaldırır.

Statik üretim + headless CMS modelinde sayfalar önceden üretilir; ziyaretçiye sunulan şey çalışan bir uygulama değil, hazır dosyalardır. Ziyaretçinin ulaştığı yüzeyde PHP yok, veritabanı yok, /wp-admin yok. İçerik yönetimi ayrı, kimlik doğrulamalı bir katmanda yaşar ve sitenin kendisiyle aynı yüzeyi paylaşmaz. Botlar taramaya devam eder ama deneyecek kapı bulamaz. Bu, sitenin "çok iyi korunması" değil — korunacak şeyin azaltılmasıdır. Güvenlikte en sağlam ilke budur: var olmayan bileşen hacklenemez.

Dürüst dipnot: statik mimari sihirli bir kalkan değildir. Formlarınız bir sunucuya gider, yönetim paneliniz bir yerde çalışır, alan adı ve DNS hesaplarınız çalınabilir. Saldırı yüzeyi sıfırlanmaz; radikal biçimde küçülür ve tek tek bilinen, kontrol edilen noktalara iner. Fark, yüz kapılı bir binayla iki kapılı bir bina arasındaki farktır.

WordPress'te kalmak ne zaman makul?

Bu yazının amacı "WordPress kullanan herkes tehlikede" paniği yaratmak değil. Şu koşullarda WordPress güvenlik açısından yönetilebilir:

• Site küçük ve içinde değerli veri yok (üyelik yok, ödeme yok, müşteri verisi yok).
• Eklenti sayısı az ve hepsi aktif olarak bakılan, bilinen eklentiler.
• Güncellemeleri düzenli yapan biri gerçekten var — "var sayılan" değil, var olan.
• Yönetilen (managed) bir WordPress barındırma kullanılıyor ve yama yükünün bir kısmı onlara devredilmiş.

Kişisel blog, hobi sitesi, küçük tanıtım sitesi: bu profil için WordPress + disiplinli bakım yeterlidir. Denklem, site iş kritik hâle geldiğinde değişir. Müşteri verisi tutuyorsanız, siteniz satış kanalıysa ya da markanızın hacklenmiş hâlinin bir günlük görüntüsü bile pahalıysa, "sürekli savunma" modelinden "küçük saldırı yüzeyi" modeline geçmek konuşulmaya değer.

Sitenizin güvenlik yükünü büyütmeden azaltmanın yolunu arıyorsanız Vucod'a yazın; mevcut kurulumunuza bakıp WordPress'te kalmanın mı, geçişin mi mantıklı olduğunu açıkça söyleriz. Her başvuruya 48 saat içinde dönüyoruz: vucod.com