WordPress, rakipleri arasında en popüler ve gelişmiş İçerik Yönetim Sistemidir. Bu özellik onu aynı zamanda potansiyel bir hedef haline getirmiştir. Üzerinde en fazla güvenlik açıklarının tarandığı CMS, WordPress’dir

WordPress dosyalarının; Tema ve Eklentilerinin güvenlik açıklarını güncel olarak raporlayan platformlar da vardır. Özellikle -WordPress çekirdek dosyaları üzerinde- güvenlik açıklarının ortaya çıkması istisna olarak kabul edilebilir. Geçmişte önemli güvenlik açıkları ender olarak saptanmış olsa bile bunlar da çok geçmeden kapatılmıştır. Çekirdek dosyaları hedef almak çok zor bir girişimdir ve Hacker unvanına sahip özel yetenekli kişiler için bile (istisna yaşanabilecek bir durum ortaya çıkmazsa) imkansızdır. WordPress çekirdek dosyaları 50 kişilik bir güvenlik ekibi tarafından korunuyor. Bu çekirdek dosyalara yapılacak bir saldırı ihtimali; WordPress’in muazzam bir titizlik gösterdiği konudur. Kullanmakta olduğunuz WordPress CMS arka ucunda komplike bir güvenlikle yapılandırılmıştır. Güncel olduğunuzdan eminseniz; asla basit bir sistemin üzerinde olmadığınızdan emin olabilirsiniz.

WordPress Site Hackleme

Çekirdek dosyaları çok iyi korunmasına rağmen, WordPress web sitelerine yapılan başarılı saldırıların hemen hepsi kullanıcıların bıraktığı açıklardan kaynaklanır

WordPress web sitesini hedef almakla WordPress’i hedef almak aynı şey değildir. WordPress kullanan web sitesinde açık bulmakla, WordPress’de açık bulmak tamamen farklı kavramlardır. WordPress kullanan siteye başarılı bir girişim yapılabilir ve bu duyurulacak bir olay olmaz. WordPress’e tek başına başarılı bir şekilde saldırmak ise; bütün dünyaya duyurulacak bir olay olur. WordPress, temel anlamda bir sunucuya kurulur ve üzerinde de tema ve eklentiler çalıştırılır. Sunucu Güvenliği / -cPanel ya da Plesk gibi diğer panellerin- güvenliği başta olmak üzere; çalıştırılan kodların sistem üzerindeki etkisi de WordPress web sitelerinin güvenlik seviyelerini değiştirir. (Tema / Eklentiler de WordPress üzerinde çalıştırılan hazır paket haline getirilmiş kodlardır)

Tek başına WordPress’in kendisini hedef tahtasına oturtmak; saldırganı pes ettiren düzeyde olduğu için, WordPress sisteminin güvenlik düzeyini değiştirmiş olan -kullanıcı kaynaklı- açıklar taranır. Bunlar da kısaca; barındığı sunucunun güvenlik yapılandırması, tema ve eklentilerin AJAX sorgularıdır. Yine kısaca; bütün bu yapılandırmalar henüz yaygın olmaya devam eden XSS sızıntılarına neden olur. (Sunucu güvenlik yapılandırmaları dahil olmak üzere, Eklentiler ve Temalardaki sızıntılar sadece XSS saldırılarını ortaya çıkarmaz; bunların arasında yaygın olarak ortaya çıkan -genellikle- XSS açıklarıdır)

XSS Nedir?

XSS Kelime anlamı olarak; (Cross-site Scripting) “Siteler Arası Betik Çalıştırma” demektir. Bu işlem ise, Kod Enjeksiyon Saldırısı demektir ve bu saldırı senaryosunda web sayfası üzerinden gidilerek; tarayıcı üzerinde / URL’de, web sitesinin arka uç yetkilerine çapraz erişim için komut ve parametreler çalıştırılır. XSS, çok nadir durumlarda CSS’de bile yürütülebilir. Fakat, genellikle bu kod enjeksiyonları JavaScript üzerinden çalıştırılır. XSS, web sitesindeki tek bir sayfanın tamamını veya bir bölümünü etkileyebilirken (özellikle de yorumlar ve kullanıcı etkileşimine dayanan mesaj panolarını) web sitesinin tamamen tahrif edilmesine de neden olabilir. Saldırgan bu XSS açığı üzerinden JavaScript komutlarını enjekte ettiğinde kullanıcı çerezlerine erişebilir: (çerezler sadece kullanıcıların değil; yönetici oturumunu da kapsayabilir) Ele geçirilen çerezler; sitedeki bir kullanıcıyı veya eğer, bu bir yönetici oturumunda kullanılan çerez ise yöneticiyi taklit etmesine veya yönetici izinlerinin bir bölümünün tarayıcıda ele geçirilmesine neden olur.

XSS Önleme

XSS saldırılarını engellemek için kısaca; web sitesi üzerinden tarayıcıya gönderilen kodlar çapraz izinler vermemelidir. Saldırı Örnekleri: owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet bağlantısından detaylı bir biçimde incelenebilir. XSS saldırılarını önlemek için güvenli bir kodlama kütüphanesine sahip olmalısınız. Dolayısıyla XSS açığını vermemek için web sitenizde çalışan kodların nasıl kapatıldıklarına dikkat etmelisiniz. Bu nedenle web siteniz üzerinde çalışan uygulamalarınız incelenerek test edilmeden XSS açıkları bırakılmadığından emin olamazsınız. Bunun için OWASP XSS Önleme sayfasını inceleyin: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Ama XSS açıklarından yararlanılmasının önüne geçmek için sunucu üzerinde Çerez, X-Frame ve XSS koruma yapılandırılabilir. Bu üç önemli yapılandırma yaygın XSS saldırılarının önüne geçecektir; ancak XSS açıklarınızı kapatmayacaktır. Yalnızca XSS açıkları üzerinden hassas verilerin ele geçirilmemeleri için Temel / Önemli bir güvenlik yapılandırmasıdır.

Yapılandırma genelde Dedicated Server / Adanmış Sunucu modülü üzerinde anlatılmıştır. Apache için Shared Hosting / Paylaşılan Sunucularda (*Kök erişim izinleri bulunmayan sunucular) Htaccess’de de kurulabilir. Yapılandırma, OWASP Zap Saldırı Modu altında doğrulanabilir. (Httponly, X-Frame – XSS)

OWASP ZAP

XSS Güvenlik Açığı

XSS açıklarından yararlanılmasının önüne geçmek için Httponly Çerezleri, (Httponly Cookies) X-Frame-Options, Header X-XSS Protection yapılandırması sitenizin kök klasöründe bulunan Htaccess üzerinde kurulabilir. Httponly Çerezleri, X-Frame-Options – Header X-XSS-Protection yapılandırmasının ise nasıl çalıştıkları şu an bu konuya dahil edilmedi. Gelecekte site üzerinde daha ayrıntılı bir biçimde işlenebilir.

Kısaca: Çerezlerdeki Httponly Flag / Güvenlik Bayrağı; çerezlere erişim riskini azaltan bir tanımlamadır. HTTP Security Headers / HTTP Güvenlik Başlıkları ise: (X-Frame-Options –  Header X-XSS Protection) Sayfadaki Meta, bilgisini tanımlayan başlıklardır. Bu Meta Bilgileri ise gönderilen istekler için tarayıcının sakladığı yetki bilgilerini ve yine sunucu üzerindeki kimlik bilgilerini içerebilir. Bu Güvenlik Başlıkları; bu bilgilerin istemci üzerinde çalışmasını devre dışı bırakan http yanıtıdır.

X-Frame-Options; Clickjacking saldırıların önüne geçmeyi amaçlar. Clickjacking; UI Saldırısıdır (Kullanıcı Arayüzü Saldırısı) Bu bir tür Sahte Click girişimidir. Saldırıyı engellemek için de sayfaların Iframe (İçerikleri sayfaya yerleştiren HTML bileşenleri) yolu ile yönlendirilmesini önlemek için kullanılır. Sayfadaki çerçeve ayarı DENY / SAMEORIGIN ya da ALLOW-FROM URL belirlenebilir.

DENY

Site üzerinde IFRAME kullanarak hiçbir yönlendirmeye izin vermez; (Çerçeve yüklemeleri için en katı kilittir)

SAMEORIGIN

Web sitesinin yalnızca belirtilen sunucu tarafından Embed edilmesine (site üzerinde çalıştırılması / Gömülmesi) izin verir.

ALLOW-FROM URL

Yalnız belirtilen URL için izin verir.

Header X-XSS-Protection

XSS filtresini etkinleştirerek; XSS yürütmeleri algılandığında bu sayfanın oluşturulmasını engeller veya bu sayfada yürütülmeye çalışan kodları bloke eder. (Yapılandırma & filtre sunucu tarafında döndürülür)

Aşağıdaki kodları public_html dizinindeki htaccess dosyasına ekleyin: (Tanımlar, APACHE /LT/NGX (OWASP – ACUNETIX – BURP ile doğrulanabilir ve tarayıcı üzerinde Network kayıtlarında da izlenebilir)

Tanımları htaccess dosyasında en üste belirleyin; htaccess dosyasına müdahale eden / otomatik güncelleyen eklentiler varsa, daha sonra rastgele açılan yeni tanım satırlarını silebilir. Dosyanızdaki htaccess tanımlarını biliyorsanız, o halde sadece bu tanımlara ayrılan satırları kullanmadığınıza emin olabilirsiniz.

X-Frame-Options

XSS-Protection

Httponly Çerezleri

Referanslar:
spark.apache.org/docs/3.1.1/security.html
httpd.apache.org/docs/current/mod/mod_headers.html
zeppelin.apache.org/docs/0.9.0-preview1/setup/security/http_security_headers.html