WordPress Güvenliği

1. Giriş

WordPress web'in yaklaşık %40'ını çalıştırır — bu, onu hem en yaygın CMS hem de en büyük saldırı hedefi yapar. Ama WordPress güvenliğine dair en önemli gerçek şudur: WordPress çekirdeği nispeten iyi denetlenir ve sertleştirilmiştir; ihlallerin ezici çoğunluğu eklentilerden ve temalardan gelir. Bir WordPress sitesi, çekirdeğin güvenliğinden bağımsız olarak, yüklü herhangi bir eklentinin en zayıf açığı kadar güvenlidir.

Bu, Bölüm 30'un (tedarik zinciri) WordPress'e uygulanmasıdır: her eklenti/tema, sizin sitenizin yetkisiyle çalışan üçüncü taraf bir bağımlılıktır. WordPress eklenti deposu on binlerce eklenti içerir; bunların çoğu küçük ekiplerce, değişken güvenlik olgunluğuyla geliştirilir. Sonuç: Wordfence ve Patchstack gibi kuruluşlar, her hafta çok sayıda eklentide kitlesel sömürülen açık (özellikle kimlik doğrulamasız yetki yükseltme) bildirir — bir saldırganın kendini yönetici yapıp siteyi tümüyle ele geçirmesine (web shell, backdoor — Bölüm 34) izin veren açıklar.

Bu bölüm, WordPress'i iki cephede güvence altına almayı ele alır: (1) ekosistem yönetimi — eklenti/tema riskini azaltma, güncelleme, minimize etme; (2) güvenli geliştirme — kendi eklenti/tema kodunuzda WordPress'in güvenlik API'lerini (bu kitabın önceki bölümlerinin WordPress karşılıkları) doğru kullanma.

---

2. Temel Teori

Tehdit modeli — çekirdek vs ekosistem. WordPress çekirdeği düzenli denetlenir ve otomatik güncellenir; çekirdek açıkları nadirdir ve hızla yamalanır. Asıl saldırı yüzeyi eklentiler ve temalardır (ve zayıf yönetici kimlik bilgileri). Bu yüzden WordPress güvenliği büyük ölçüde bir ekosistem yönetimi problemidir (Bölüm 30).

Eklentilerdeki yaygın açık kalıpları:

Kalıp	Bu kitapta
Kimlik-doğrulamasız yetki yükseltme	Bölüm 14 (rol enjeksiyonu → admin)
Yetkisiz REST uç noktaları	Bölüm 22 (BOLA/BFLA)
SQL injection	Bölüm 6 ($wpdb->prepare eksikliği)
XSS	Bölüm 7 (esc_* eksikliği)
Keyfi dosya yükleme	Bölüm 19 (web shell)
Kimlik doğrulama atlatma	Bölüm 12

WordPress'in güvenlik API'leri — doğru kullanım (önceki bölümlerin karşılıkları): - Nonce (Bölüm 17 CSRF): wp_create_nonce, check_admin_referer/wp_verify_nonce. WordPress'in CSRF savunması; durum-değiştiren her eyleme eklenmeli. - Capability/rol (Bölüm 14 yetki): current_user_can('manage_options'). Her ayrıcalıklı eylemden önce kontrol edilmeli. Nonce CSRF'i önler ama yetki vermez — ikisi ayrıdır. - Sanitize (Bölüm 4 girdi): sanitize_text_field, sanitize_email, absint — girdi temizleme. - Escape (Bölüm 5/7 çıktı): esc_html, esc_attr, esc_url, wp_kses — çıktı bağlamına göre kaçış. - $wpdb->prepare (Bölüm 6 SQLi): Parametreli sorgular; ham string birleştirme yerine.

Diğer WordPress-özgü yüzeyler: - XML-RPC (xmlrpc.php): Kaba kuvvet amplifikasyonu (system.multicall ile tek istekte yüzlerce parola denemesi) ve pingback SSRF (Bölüm 21). Kullanılmıyorsa kapatılmalı. - Kullanıcı enumerasyonu: ?author=1 yönlendirmeleri ve REST /wp-json/wp/v2/users, kullanıcı adlarını sızdırır (kaba kuvvet için, Bölüm 12). - wp-config.php (Bölüm 25): DB kimlik bilgileri ve auth anahtarları; sıkı izinli (Bölüm 28), web'de erişilemez.

Ekosistem savunması (Bölüm 30): 1. Güncelle (1 numaralı savunma): Çekirdek + eklenti + tema; otomatik güncelleme. 2. Minimize et: Her eklenti bir yüzeydir; gereksizleri kaldır. 3. İtibarlı/bakımlı eklenti seç; terk edilmişlerden kaçın. 4. Açık izleme: Wordfence/Patchstack ile bilinen açıkları izle (SCA karşılığı). 5. En az yetki + güçlü auth + 2FA + login sınırı (Bölüm 12).

---

3. Mimarisel Bakış

 TEHDİT DAĞILIMI:
   WordPress çekirdeği  → denetli, otomatik güncellenir → nadir açık
   Eklentiler/temalar   → değişken güvenlik → ÇOĞU İHLALİN KAYNAĞI (Böl.30)
   Zayıf admin kimliği  → kaba kuvvet (Böl.12)

 EKLENTİ PRIVILEGE ESCALATION (yaygın kalıp):
   Saldırgan → yetkisiz/zayıf-auth eklenti uç noktası
        ↓  rol doğrulaması YOK → wp_insert_user(role=administrator)
   → kendini ADMIN yapar → tam site devri → web shell/backdoor (Böl.34)

 GÜVENLİ EKLENTİ KODU (önceki bölümlerin WP karşılıkları):
   check_admin_referer (nonce — Böl.17)  → CSRF
   current_user_can (capability — Böl.14) → yetki
   sanitize_* (Böl.4) → esc_* (Böl.5/7) → wp_kses
   $wpdb->prepare (Böl.6) → SQLi
   finfo + web-dışı (Böl.19) → upload

 SERTLEŞTİRME: güncelle+minimize (Böl.30) · wp-config/izin (Böl.25/28) ·
               XML-RPC kapat · user enum engelle · 2FA+login sınırı (Böl.12)

Kritik gözlem: WordPress güvenliği hem ekosistem yönetimi (güncelle/minimize/izle) hem güvenli kod (WP güvenlik API'leri) gerektirir.

---

4. Güvensiz Kod

Gerçekçi (güvensiz) bir eklenti eylemi:

<?php
// ⚠️ GÜVENSİZ WordPress eklenti kodu
// 1) Nonce yok (CSRF — Bölüm 17), capability yok (yetki — Bölüm 14)
add_action('admin_post_update_profile', function () {
    // 2) Girdi sanitize edilmemiş (Bölüm 4)
    $name = $_POST['name'];
    $role = $_POST['role'];                       // KULLANICI rol belirliyor!

    // 3) Rol doğrulaması yok → privilege escalation (Bölüm 14)
    wp_insert_user([
        'user_login' => $_POST['login'],
        'role'       => $role,                     // 'administrator' enjekte edilebilir
    ]);

    // 4) $wpdb ham string (SQLi — Bölüm 6)
    global $wpdb;
    $wpdb->query("SELECT * FROM {$wpdb->users} WHERE user_login = '{$_POST['login']}'");

    // 5) Escape edilmemiş çıktı (XSS — Bölüm 7)
    echo "Merhaba " . $_POST['name'];
});

---

5. Açığın Analizi

Nonce yok — CSRF (Bölüm 17). Durum-değiştiren bir eyleme nonce (check_admin_referer) eklenmemiş; saldırgan, oturum açmış bir yöneticiyi kandırarak bu eylemi tetikletebilir. WordPress'te nonce, CSRF'in standart savunmasıdır.

Capability yok — Yetki (Bölüm 14). current_user_can() kontrolü yok; herhangi bir kullanıcı (hatta yetkisiz) bu eylemi çağırabilir. Nonce CSRF'i önler ama yetki vermez — bu ikisi ayrı savunmalardır ve ikisi de gerekir.

Rol doğrulaması yok (role kullanıcıdan) — Kimlik-doğrulamasız/yetkisiz privilege escalation — WordPress eklentilerinin en yaygın kritik açığı. Kod, role'ü kullanıcıdan alıp wp_insert_user'a doğrudan veriyor; saldırgan role=administrator enjekte ederek kendini yönetici yapar → tam site devri. Rol, sunucuda beyaz listeden belirlenmeli (Bölüm 4, 14).

$wpdb ham string — SQLi (Bölüm 6). Kullanıcı girdisi doğrudan sorguya konuyor. $wpdb->prepare() ile parametreli olmalı.

Escape edilmemiş çıktı — XSS (Bölüm 7). $_POST['name'] doğrudan echo ediliyor. esc_html() gerekir.

Kök sorun: eklenti, WordPress'in güvenlik API'lerini (nonce, capability, sanitize/escape, prepare) kullanmıyor ve kritik olarak rolü kullanıcıya bıraktığından privilege escalation'a açık. Çözüm: bu API'leri doğru kullanmak.

---

6. Hacker Bakış Açısı

Saldırgan bir WordPress sitesini nasıl hedefler?

Sürümleri ve eklentileri haritalar. WordPress sürümünü, yüklü eklenti/temaları ve sürümlerini (readme dosyaları, JS/CSS yolları, HTML izleri) tespit eder; her biri için bilinen açıkları (Wordfence/Patchstack veritabanları, WPScan) arar. Yamasız bir eklenti = hazır giriş.

Yetki yükseltme eklentilerini yoklar. En verimli hedef: kimlik-doğrulamasız/zayıf-auth yetki yükseltme açıkları. Bir eklentinin rol/kullanıcı oluşturma akışına administrator enjekte edebiliyorsa, tek istekle yönetici olur.

Yetkisiz REST/AJAX uç noktalarını dener. wp-json ve admin-ajax.php üzerinden yetki/nonce kontrolü olmayan eylemleri arar (Bölüm 22 BOLA/BFLA).

Kullanıcı enumerasyonu + kaba kuvvet yapar. ?author=1 ve REST /wp/v2/users ile kullanıcı adlarını toplar; sonra XML-RPC system.multicall ile amplifiye kaba kuvvet (tek istekte yüzlerce deneme — Bölüm 12) uygular.

Yüklemeyi ve dosya yazmayı hedefler. Bir dosya yükleme açığı (Bölüm 19, WP File Manager kalıbı) veya dosya-yazma ile web shell (Bölüm 34) düşürür; wp-content/uploads'ın PHP çalıştırıp çalıştırmadığını (Bölüm 27) test eder.

Yönetici olunca kalıcılık kurar. Kötü eklenti yükler, backdoor ekler, rogue admin oluşturur (Bölüm 34) — Wordfence'in belgelediği tipik sömürü-sonrası davranış.

Savunmacı dersi: Saldırgan için WordPress, "en zayıf eklentiyi bul" oyunudur. Güncelleme, minimize etme, açık izleme ve güvenli kod, bu oyunu kazandırmaz.

---

7. Exploit Mantığı

Bu bölüm çalıştırılabilir saldırı içermez. WordPress risklerinin neden bu kadar yaygın olduğu kavramsaldır:

• Ekosistem = yüzey çarpanı. Her eklenti/tema, sizin yetkinizle çalışan üçüncü taraf koddur (Bölüm 30). WordPress'in devasa eklenti ekosistemi, devasa ve değişken-kaliteli bir saldırı yüzeyi demektir; tek zayıf eklenti tüm siteyi açar.
• Privilege escalation = anında tam devir. WordPress'te "administrator" olmak, eklenti yükleyip kod çalıştırabilmek (web shell) demektir. Bu yüzden yetki-yükseltme açıkları doğrudan tam site devrine (ve RCE'ye) tırmanır.
• Yaygınlık = otomatik kitlesel sömürü. WordPress'in %40 pazar payı, bir eklenti açığının otomatik, kitlesel olarak (botlarla) sömürülmesini sağlar; açıklama sonrası saatler içinde binlerce site taranır.
• Güvenli API'leri atlamak. WordPress güçlü API'ler (nonce, capability, prepare, esc) sunar; ama eklenti geliştiricisi bunları kullanmazsa, kitabın tüm açık sınıfları geri döner.

Savunmacının çerçevesi: (a) çekirdek/eklenti/tema güncel mi, (b) eklentiler minimize/itibarlı mı, (c) açıklar izleniyor mu, (d) kendi kod WP güvenlik API'lerini kullanıyor mu, (e) site sertleştirilmiş mi. Savunma beşini de sağlar.

---

8. Güvenli Kod

WordPress güvenlik API'lerini doğru kullanan eklenti kodu:

<?php
// ✅ GÜVENLİ WordPress eklenti kodu
add_action('admin_post_update_profile', function () {
    // 1) Nonce (CSRF — Bölüm 17) + capability (yetki — Bölüm 14): İKİSİ de
    check_admin_referer('update_profile_action');           // CSRF
    if (!current_user_can('edit_users')) {                  // yetki
        wp_die('Yetkisiz', 403);
    }

    // 2) Girdi sanitize (Bölüm 4)
    $name  = sanitize_text_field(wp_unslash($_POST['name'] ?? ''));
    $login = sanitize_user(wp_unslash($_POST['login'] ?? ''));

    // 3) Rol BEYAZ LİSTEDEN (privilege escalation önlemi — Bölüm 4, 14)
    $allowedRoles = ['subscriber', 'contributor'];          // 'administrator' YOK
    $role = in_array($_POST['role'] ?? '', $allowedRoles, true)
        ? $_POST['role'] : 'subscriber';

    wp_insert_user(['user_login' => $login, 'role' => $role]);

    // 4) $wpdb->prepare (SQLi — Bölüm 6)
    global $wpdb;
    $user = $wpdb->get_row(
        $wpdb->prepare("SELECT * FROM {$wpdb->users} WHERE user_login = %s", $login)
    );

    // 5) Escape edilmiş çıktı (XSS — Bölüm 7)
    echo 'Merhaba ' . esc_html($name);
});

wp-config.php ve site sertleştirme (kod dışı):

// wp-config.php sertleştirme
define('DISALLOW_FILE_EDIT', true);        // dashboard'dan dosya düzenlemeyi kapat
define('WP_AUTO_UPDATE_CORE', true);       // otomatik çekirdek güncelleme
// Auth anahtarları (SALT) benzersiz ve gizli (Bölüm 25); wp-config sıkı izinli (Bölüm 28)

# Sunucu sertleştirme (Bölüm 27, 28):
- wp-config.php web'de erişilemez + sıkı izinli (600/640)
- wp-content/uploads'ta PHP yürütme KAPALI (Bölüm 19, 27) — web shell çalışmaz
- kod web kullanıcısınca yazılamaz (Bölüm 28)
- XML-RPC kapat (kullanılmıyorsa); user enumeration engelle (?author, REST users)
- 2FA + login deneme sınırı (Bölüm 12); WAF (Wordfence/Patchstack)

Öne çıkan modern pratikler: - Nonce + capability, İKİSİ birden: check_admin_referer (CSRF, Bölüm 17) ve current_user_can (yetki, Bölüm 14). Nonce yetki vermez. - Rol/hassas alan beyaz listeden: Kullanıcı rol/yetki belirleyemez (privilege escalation önlemi — Bölüm 4, 14). - Sanitize + escape (Bölüm 4/5/7): sanitize_* girdide, esc_*/wp_kses çıktıda. - $wpdb->prepare (Bölüm 6): Ham string yok. - Güncelle + minimize + izle (Bölüm 30): Çekirdek/eklenti/tema; otomatik güncelleme; Wordfence/Patchstack. - Sertleştirme (Bölüm 25/27/28): wp-config koruması, upload'ta PHP kapalı, kod-yazılamazlık, XML-RPC/enum kapatma, 2FA + login sınırı (Bölüm 12).

---

9. Patch Analizi

Neden işe yarar? Nonce + capability birlikte, hem CSRF'i (Bölüm 17) hem yetkisiz erişimi (Bölüm 14) kapatır. Rolü beyaz listeden belirlemek, WordPress'in en yaygın kritik açığını — kimlik-doğrulamasız yetki yükseltme — kapatır. Sanitize/escape/prepare, kitabın temel açık sınıflarını (Bölüm 4/6/7) WordPress bağlamında önler. Ekosistem tarafında güncelleme + minimize + izleme (Bölüm 30), en büyük risk kaynağını (eklenti açıkları) yönetir. Sertleştirme (Bölüm 25/27/28) hasarı sınırlar.

WordPress API karşılaştırması:

Açık (kitap bölümü)	WordPress'te yanlış	Doğru API
CSRF (17)	Nonce yok	check_admin_referer
Yetki (14)	Kontrol yok	current_user_can
Privilege esc. (14)	Kullanıcı rol belirliyor	Rol beyaz listeden
SQLi (6)	Ham $wpdb->query	$wpdb->prepare
XSS (7)	echo $_POST	esc_html/wp_kses
Upload (19)	Doğrulamasız	finfo + web-dışı + PHP kapalı

Nonce ≠ yetki (kritik): WordPress'te sık yapılan hata, nonce'u bir yetki kontrolü sanmaktır. Nonce yalnızca "bu isteği bu kullanıcı bilerek gönderdi" (CSRF) der; o kullanıcının bu eyleme yetkili olduğunu söylemez. İkisi ayrı ve ikisi de gereklidir.

Performans: Tüm bu API'ler hafiftir; WordPress'in kendi altyapısıdır. Güncelleme/izleme operasyonel maliyettir ama otomatikleştirilebilir. Güvenlik kazancı çok büyüktür.

---

10. Gerçek Hayat Senaryosu

Kurgu — bir KOBİ'nin WordPress sitesi. Site güncel çekirdek çalıştırıyor ama 25 eklentisi var ve bazıları aylardır güncellenmemiş. Bir eklentide kimlik-doğrulamasız yetki yükseltme açığı (rol enjeksiyonu) açıklanıyor; botlar açıklamadan saatler sonra siteyi buluyor ve saldırgan kendini administrator yapıyor. Oradan kötü bir eklenti yükleyip web shell (Bölüm 34) bırakıyor, wp-config.php'den DB kimlik bilgilerini (Bölüm 25) okuyor ve siteyi spam/malware dağıtımına koşuyor. Doğru yönetimle: eklenti minimizasyonu + otomatik güncelleme + Patchstack açık izleme → açık yamalanır/engellenir; upload'ta PHP kapalı + kod-yazılamazlık (Bölüm 27, 28) → web shell çalışmaz. Dersler: (1) risk eklentilerde — minimize + güncelle + izle (Bölüm 30); (2) sertleştirme web shell'i durdurur; (3) yetki yükseltme = tam devir, güvenli kod şart.

---

11. Gerçek Vaka Analizi — Eklenti Yetki Yükseltme Dalgası (OttoKit/SureTriggers CVE-2025-27007 ve Kalıp)

Patchstack ve Wordfence açık bültenleriyle doğrulanmıştır. WordPress'in dominant tehdidinin ders kitabı örneğidir.

Özet. WordPress'in dominant tehdidi tek bir CVE değil, sürekli tekrarlayan bir kalıptır: popüler eklentilerde kimlik-doğrulamasız/zayıf-auth yetki yükseltme açıkları. Temsili bir örnek, Patchstack'in 2025'te en çok sömürülenler arasında listelediği OttoKit (eski adıyla SureTriggers) CVE-2025-27007'dir: 100.000'den fazla kuruluma sahip bu eklentide, sure-triggers/v1/connection/create-wp-connection REST rotası, yalnızca tahmin edilebilir bir kullanıcı adını doğrulayarak yeni bir bağlantı anahtarı eklemeye izin veriyordu; bu anahtar sonra yönetici hesabı oluşturma dahil hassas eylemler (RCE'ye kadar) için kullanılabiliyordu. Kimlik doğrulamasız saldırganlar bunu kitlesel olarak sömürdü; Patchstack kural devreye alındığından beri binlerce denemeyi engelledi.

Teknik neden — rol/yetki doğrulamasının eksikliği. Bu kalıbın kökü, bu bölümün 5. kısmında analiz edilen hatadır: bir eklenti, kullanıcı oluşturma/rol atama argümanlarını izin verilen rollere karşı doğrulamadan kuruyor. Wordfence'in belgelediği bir başka temsili vakada (Post Grid and Gutenberg Blocks, 40.000+ kurulum, 2024), kod gönderilen form verisini yineleyip değerleri doğrudan WordPress'in wp_insert_user() fonksiyonuna geçiriyor — yapılandırılmış kısıtlamalara karşı kontrol etmeden. Saldırgan form gönderimine bir administrator rol parametresi enjekte ediyor ve eklenti bunu doğrulamadan işliyor → saldırgan yönetici oluyor → tam site devri. Benzer biçimde Kirki (500.000+ site, 2026) vakasında bir parola-sıfırlama mantık hatası, sıfırlama bağlantısını saldırganın e-postasına gönderiyordu.

Ortak ders, kitabın Bölüm 14 (yetki) ve Bölüm 4 (girdi doğrulama) derslerinin WordPress'e uygulanmasıdır: kullanıcıdan gelen rol/yetki/hedef değerleri asla doğrulanmadan güvenilmemeli; rol sunucuda beyaz listeden belirlenmeli. Başarılı sömürü, Wordfence'in belirttiği gibi, tipik sömürü-sonrası tekniklerle sonuçlanır: kötü eklenti kurma, backdoor enjekte etme, rogue admin oluşturma, kalıcı web shell (Bölüm 34).

Etki ve hız. Bu açıklar genelde 100.000'lerce siteyi etkiler ve açıklamadan saatler/günler içinde kitlesel otomatik sömürüye girer (Wordfence Kirki için ilk 24 saatte 222+ deneme engelledi). WordPress'in %40 pazar payı, bu hızı ve ölçeği besler.

Çıkarılacak dersler: 1. Risk eklentilerdedir (Bölüm 30). Minimize et, itibarlı/bakımlı seç, güncelle, açık izle (Wordfence/Patchstack). 2. Rol/yetki asla kullanıcıya bırakılmaz (Bölüm 4, 14). Sunucuda beyaz listeden belirlenmeli; wp_insert_user'a doğrulanmamış rol geçilmemeli. 3. Yetki yükseltme = tam devir. WordPress'te admin olmak RCE'ye (eklenti/kod yükleme) eşdeğerdir; sertleştirme (Bölüm 27, 28) hasarı sınırlar. 4. Hız kritiktir. Otomatik güncelleme ve WAF/açık-izleme, açıklama ile yama arasındaki pencereyi kapatır.

---

12. Detection

Kod incelemede (kendi eklenti/tema):

grep -rnE 'wp_insert_user|wp_update_user|add_user_to_blog' . | grep -i role   # rol doğrulama?
grep -rnE 'current_user_can|check_admin_referer|wp_verify_nonce' .            # yetki/nonce var mı?
grep -rn  '\$wpdb->query\|\$wpdb->get_' . | grep -v prepare                   # SQLi (prepare yok)
grep -rnE 'echo .*\$_(GET|POST|REQUEST)' .                                    # XSS (escape yok)

Kontroller: durum-değiştiren eylemlerde nonce + capability var mı? Rol beyaz listeden mi? $wpdb->prepare kullanılıyor mu? Çıktı escape ediliyor mu?

Ekosistem tarama: WPScan/Wordfence/Patchstack ile bilinen-açıklı eklenti/tema/çekirdek sürümlerini (SCA karşılığı — Bölüm 30) tespit et.

DAST: Yetki yükseltme (rol enjeksiyonu), yetkisiz REST/AJAX uç noktaları, user enumeration, XML-RPC amplifikasyonu testleri.

Loglar/SIEM (Bölüm 31): admin-ajax.php/wp-json'a yetkisiz/anormal istekler; ?author= enumerasyonu; XML-RPC system.multicall (kaba kuvvet amplifikasyonu); yeni admin kullanıcı oluşturma; wp-content'te yeni .php (web shell — Bölüm 34); eklenti kurulum/aktivasyon olayları. Rogue admin oluşturma ve yeni eklenti kurulumu en net sömürü-sonrası izlerdir.

---

13. Prevention

• Güncelle + minimize + izle (Bölüm 30): Çekirdek/eklenti/tema; otomatik güncelleme; Wordfence/Patchstack.
• Nonce + capability (Bölüm 17, 14): Durum-değiştiren her eylemde ikisi birden.
• Rol/hassas alan beyaz listeden (Bölüm 4, 14): Kullanıcı belirleyemez.
• Sanitize + escape + prepare (Bölüm 4/5/6/7): WP API'lerini kullan.
• Sertleştirme (Bölüm 25/27/28): wp-config koruması, upload'ta PHP kapalı, kod-yazılamazlık, DISALLOW_FILE_EDIT.
• XML-RPC/enum kapat; 2FA + login sınırı (Bölüm 12); WAF.
• İtibarlı/bakımlı eklenti; terk edilmişten kaçın (Bölüm 30).

---

14. Mitigation

• Acil: Açıklı eklentiyi güncelle/devre dışı bırak; WAF kuralı (Wordfence/Patchstack); rogue admin/eklenti tara ve kaldır; upload'ta PHP yürütmeyi kapat (Bölüm 27).
• Geçici: Web shell/backdoor (Bölüm 34) tara; sızmış kimlikleri/sırları (wp-config — Bölüm 25) döndür; tüm admin hesaplarını denetle.
• Kalıcı: Eklenti minimizasyonu + otomatik güncelleme + açık izleme; kendi kodda WP güvenlik API'lerini standartlaştır; sertleştirme baseline'ı (Bölüm 27, 28) + 2FA/login sınırı.

---

15. Checklist

• [ ] Çekirdek, eklentiler ve temalar güncel mi (otomatik güncelleme)?
• [ ] Eklentiler minimize edilmiş, itibarlı/bakımlı mı ve açıklar izleniyor mu (Bölüm 30)?
• [ ] Durum-değiştiren eylemlerde nonce (check_admin_referer) ve capability (current_user_can) var mı?
• [ ] Rol/hassas alanlar beyaz listeden mi belirleniyor (kullanıcı değil — Bölüm 4, 14)?
• [ ] $wpdb->prepare kullanılıyor mu (SQLi — Bölüm 6)?
• [ ] Çıktı esc_*/wp_kses ile escape ediliyor mu (XSS — Bölüm 7)?
• [ ] wp-config.php sıkı izinli ve web'de erişilemez mi (Bölüm 25, 28)?
• [ ] wp-content/uploads'ta PHP yürütme kapalı mı (Bölüm 19, 27)?
• [ ] XML-RPC/user enumeration kapalı mı; 2FA + login deneme sınırı var mı (Bölüm 12)?
• [ ] DISALLOW_FILE_EDIT ayarlı ve kod web kullanıcısınca yazılamaz mı (Bölüm 28)?

---

16. Laboratuvar

Lab 35.1 — Nonce + capability. İzole bir eklentide nonce/capability olmayan bir eylem yaz; CSRF ve yetkisiz erişimi göster. İkisini ekleyip düzelt; nonce'un neden yetki vermediğini yaz.

Lab 35.2 — Rol enjeksiyonu. wp_insert_user'a kullanıcı-kontrollü rol geçen bir kod yaz; administrator enjekte ederek privilege escalation'ı göster. Rolü beyaz listeye alıp düzelt.

Lab 35.3 — $wpdb->prepare. Ham $wpdb->query ile SQLi'yi göster; prepare ile düzelt (Bölüm 6'ya bağla).

Lab 35.4 — Sertleştirme. İzole bir WordPress'te upload'ta PHP yürütmeyi aç/kapat; bir test dosyasının çalışıp çalışmadığını gözlemle (Bölüm 27). DISALLOW_FILE_EDIT ve wp-config izinlerini uygula.

---

17. Quiz

1. WordPress güvenliğinde asıl risk nerededir (çekirdek mi ekosistem mi) ve neden?
2. WordPress'in beş güvenlik API'sini ve karşılık geldikleri açık sınıflarını eşleştirin.
3. Nonce (Bölüm 17) ve capability (Bölüm 14) arasındaki fark nedir? Neden ikisi de gerekir?
4. Kimlik-doğrulamasız yetki yükseltme kalıbı nasıl çalışır (rol enjeksiyonu)?
5. Rol neden kullanıcıya bırakılmamalı, sunucuda beyaz listeden belirlenmelidir?
6. $wpdb->prepare neden kritiktir (Bölüm 6)?
7. XML-RPC hangi iki riski taşır (amplifiye kaba kuvvet, pingback SSRF)?
8. User enumeration (?author=1, REST users) neden tehlikelidir (Bölüm 12)?
9. WordPress'te "administrator" olmak neden RCE'ye eşdeğerdir?
10. Eklenti riski Bölüm 30 (tedarik zinciri) ile nasıl ilişkilidir?
11. wp-content/uploads'ta PHP yürütmeyi kapatmak neyi önler (Bölüm 19, 27)?
12. OttoKit/Post Grid vakalarının ortak kök nedeni neydi (Bölüm 4, 14)?

---

18. Kaynakça

• WordPress Developer Handbook, Security (nonces, capabilities, sanitizing/escaping, $wpdb->prepare); Hardening WordPress.
• Wordfence ve Patchstack açık bültenleri (Post Grid and Gutenberg Blocks privesc 2024; OttoKit/SureTriggers CVE-2025-27007; Kirki privesc 2026); WPScan Vulnerability Database.
• MITRE, CWE-269 (Improper Privilege Management), CWE-862/863 (yetki), CWE-89 (SQLi), CWE-79 (XSS).
• OWASP, Top 10:2021 A05 Security Misconfiguration ve A06 Vulnerable Components (Bölüm 30).
• WordPress wp-config.php sertleştirme dokümantasyonu (DISALLOW_FILE_EDIT, auth keys/salts).