כיצד לזהות דלת אחורית של PHP בוורדפרס

אם אי פעם ראיתם בקשה ל /wp-content/uploads/2024/11/cache.php (או גרוע מכך, א ?cmd= (על קובץ שלא אמור להיות שם), כנראה שנתקלת - או היית קורבן ל - דלת אחורית של PHP.

מדריך זה מכוון וורדפרס 6.9.4 (אפריל 2026) ו-PHP 8.1+. אני מניח שאתה יודע להשתמש ב-SSH, WP-CLI, לקרוא יומן Nginx/Apache, ושכבר עבדת עם mu-plugin.

האיום

דלת אחורית ב-PHP בוורדפרס אינה "סתם" קובץ חשוד. זוהי נקודת גישה מתמשכת המאפשרת לתוקף לחזור מתי שהוא רוצה, אפילו לאחר שינוי סיסמת מנהל. מניסיוני, הדלתות האחוריות המטרידות ביותר הן בלתי נראות: הן מסתתרות בפנים. uploads/, בתוסף "ריק", או ב- wp-config.php שונה בשורה אחת שנראית תמימה.

מבחינה מעשית, אם קיימת דלת אחורית, התוקף יכול:

• ביצוע קוד מרחוק (RCE): הפעל פקודות מערכת, הורדת תוכנות זדוניות אחרות, מעבר לאתרים אחרים באותו שרת.
• צור חשבונות מנהל חשאיים או להפעיל מחדש חשבונות שנמחקו.
• גניבת נתונים קובצי Cookie, אסימוני סשן, מפתחות API, ייצוא WooCommerce, מיילים, טפסים.
• הזרקת ספאם של SEO (הסוואה, דפי לוויין) Sans גישה לתוכן שלך גלוי בלוח הניהול.
• הרוויחו כסף מהתנועה שלכם באמצעות הפניות מותנות (רק בנייד, רק בגוגלבוט, רק באזורים גיאוגרפיים מסוימים).

קשה לכמת את התדירות בפועל באופן כללי מבלי ליפול למלכודת של שיווק ספקי אבטחה. מה שאני יכול לומר לכם בצורה מהימנה הוא זה: באירוח משותף ואתרים שמתקינים תבניות/תוספים לא רשמיים, ראיתי דלתות אחוריות. כמעט באופן שיטתי לאחר פשרה ראשונית. ובאתרי Elementor/Divi/Avada, "הגורם המחמיר" אינו בונה התוכנה עצמו, אלא המערכת האקולוגית: תוספים רבים של צד שלישי, לפעמים נטושים, לפעמים הורדים מחוץ לערוצים הרשמיים.

סיכון במילים פשוטות: דלת אחורית היא נקודת כניסה נסתרת בקוד שלך. ניתן לצבוע מחדש את הדלת הקדמית (לשנות את הסיסמאות), אך התוקף עדיין ישתמש בנקודת הכניסה הנסתרת כל עוד היא קיימת.

סיכום קצר

• אל תחפשו "וירוס" חפשו נקודות ביצוע (קבצי PHP בלתי צפויים, הוקים שהוכנסו, אפשרויות WP שהשתנו, עבודות cron חשודות).
• התחל עם המלאי קבצים ששונו לאחרונה, תוספים לא ידועים, תוספים של אפליקציות שונות, משימות WP-Cron, משתמשי מנהל.
• טפלו בגורם תוסף פגיע, פרטי FTP שנפגעו, מפתח SSH גנוב, גישה לפאנל האירוח וכו'.
• הקשחת ביצוע PHP חסום PHP ב uploads/חסום גישה ל .gitהגבל את עורך הקבצים, הוסף כותרות.
• בצעו שחזור נקי "ניקוי ידני" ללא בסיס (ליבה + תוספים) משאיר לעיתים קרובות עומס עקבי.
• זיהוי אוטומטי WP-CLI + סריקות תבניות + בדיקות שלמות (סכומי בדיקה) + ניטור שינויים.

קוד פגיע - מה לא לעשות

דלתות אחוריות "קלאסיות" מסתמכות על רעיון פשוט: השגת מיקום שבו PHP יכולה לבצע קלט הנשלט על ידי המשתמש. הווקטור הנפוץ ביותר בוורדפרס נותר תוסף/תבנית שמקבל פרמטר ומבצע אותו (באופן ישיר או עקיף), או העלאת קובץ מסוננת בצורה גרועה.

דוגמה ריאליסטית: נקודת קצה של AJAX שמבצעת "פקודה אבחונית"

ראיתי לעתים קרובות את הקטע הזה (או גרסה שלו) בתוספים מותאמים אישית, קטעי טקסט מודבקים לתוך functions.php, או "שימושים חובה" מאולתרים. הכוונה היא "מעשית". ההשפעה היא קטסטרופלית.

<?php
/**
 * DANGEREUX : exemple de code vulnérable.
 * Ne déployez jamais ça sur un site public.
 */

add_action('wp_ajax_nopriv_site_debug', 'site_debug_vulnerable');
add_action('wp_ajax_site_debug', 'site_debug_vulnerable');

function site_debug_vulnerable() {
	// Erreur : aucune vérification de permission, aucun nonce
	$cmd = isset($_REQUEST['cmd']) ? $_REQUEST['cmd'] : '';

	// Erreur : exécution directe d'une entrée utilisateur
	$output = shell_exec($cmd);

	// Erreur : fuite d'information + pas de format JSON strict
	echo $output;
	wp_die();
}

למה זה ניתן לניצול (ללא "מדריך הוראות" לתקיפה)

הנה מה שקורה מאחורי הקלעים:

• wp_ajax_nopriv_* זה חושף את הפעולה למבקרים לא מאומתים. בוט אפילו לא צריך חשבון.
• $_REQUEST שילוב של GET/POST/COOKIE: אתה מרחיב את משטח ההתקפה שלא לצורך.
• shell_exec() מבצע פקודת מערכת. בשלב זה, אתה כבר לא "בתוך וורדפרס", אתה נמצא במערכת ההפעלה.
• התשובה הגולמית מחזירה את התוצאה. גם אם התוקף לא משיג ביצוע מלא, הוא לעתים קרובות משיג מידע (נתיבים, משתמשי מערכת וכו').

גרסה מסוכנת לא פחות: "הערכת" PHP מתוך אופציה

דפוס נפוץ נוסף: תוסף מאחסן קוד באפשרות (או בשדה ACF) ומבצע אותו כדי "להתאים אישית" את המערכת. זה לעיתים קרובות גורם לכך שקוד נשמר גם לאחר פגיעה במערכת.

<?php
// DANGEREUX : exécuter du code arbitraire stocké en base
add_action('init', function () {
	$payload = get_option('custom_php_snippet');
	if (!empty($payload)) {
		// Erreur : eval = exécution arbitraire
		eval($payload);
	}
});

ברגע שתוקף יכול לכתוב למסד הנתונים (SQLi, חשבון מנהל גנוב, תוסף פגיע), הוא כבר לא צריך לכתוב קובץ: הוא מזריק מטען לתוך האפשרות והקוד מבוצע בכל עמוד.

קוד מאובטח - הטמעה נכונה

אני משתמש באותה "פונקציונליות" (אבחון), אבל עם גישה שעובדת גם בסביבת ייצור: אין ביצוע פקודה, אין גישה ציבורית, הרשאות מחמירות, שליח, רשימת לבןו - פלט JSON.

מטרה: להציג אבחון של וורדפרס ללא RCE

הפשרה הטובה ביותר היא חשיפת מידע כבר זמין דרך וורדפרס (גרסאות, מצב מטמון, תקינות ה- אתרולדחות כל דבר שדומה לפקודה. אם אתם באמת צריכים פקודות מערכת הפעלה, עשו זאת דרך SSH, לא HTTP.

<?php
/**
 * Exemple sécurisé (WordPress 6.9.4+, PHP 8.1+).
 * À placer dans un plugin dédié ou un mu-plugin, pas dans functions.php.
 */

add_action('wp_ajax_site_debug', 'site_debug_secure');

function site_debug_secure() : void {
	// 1) Authentification : pas de nopriv
	if (!is_user_logged_in()) {
		wp_send_json_error(['message' => 'Non authentifié.'], 401);
	}

	// 2) Autorisation : capability explicite
	// manage_options est souvent trop large, mais acceptable pour un endpoint admin.
	// Sur un site d'agence, je préfère une capability dédiée via un rôle.
	if (!current_user_can('manage_options')) {
		wp_send_json_error(['message' => 'Accès refusé.'], 403);
	}

	// 3) Anti-CSRF : nonce obligatoire
	$nonce = isset($_POST['_wpnonce']) ? sanitize_text_field(wp_unslash($_POST['_wpnonce'])) : '';
	if (!wp_verify_nonce($nonce, 'site_debug_secure')) {
		wp_send_json_error(['message' => 'Nonce invalide.'], 403);
	}

	// 4) Entrée : liste blanche d'actions, pas de "cmd"
	$action = isset($_POST['action_name']) ? sanitize_key(wp_unslash($_POST['action_name'])) : '';
	$allowed = [
		'wp_versions',
		'active_plugins',
		'health_summary',
	];

	if (!in_array($action, $allowed, true)) {
		wp_send_json_error(['message' => 'Action non autorisée.'], 400);
	}

	// 5) Exécution : uniquement des appels WordPress, pas d'OS
	$data = match ($action) {
		'wp_versions' => [
			'wp'  => get_bloginfo('version'),
			'php' => PHP_VERSION,
		],
		'active_plugins' => [
			'plugins' => array_values((array) get_option('active_plugins', [])),
		],
		'health_summary' => site_debug_health_summary(),
		default => [],
	};

	// 6) Sortie : JSON strict + status code correct
	wp_send_json_success($data, 200);
}

/**
 * Résumé minimal de "Site Health" sans exposer de secrets.
 * Évitez d'exfiltrer des chemins absolus, des clés, ou des contenus de logs.
 */
function site_debug_health_summary() : array {
	$summary = [
		'has_https' => is_ssl(),
		'wp_debug'  => (bool) (defined('WP_DEBUG') && WP_DEBUG),
	];

	// Note : la logique Site Health complète est plus riche.
	// Ici on reste volontairement minimal pour limiter la fuite d'infos.
	return $summary;
}

הסבר פשוט

• אתה מסיר גישה ציבורית (nopriv).
• אתה כופה הרשאות מנהל.
• אתה חוסם את ה-CSRF עם nonce.
• אתה מחליף את "פקודה חופשית" ברשימה לבנה של פעולות.
• אתה מחזיר JSON נקי, לא טקסט גולמי.

הסבר טכני (הפרטים שימנעו הפתעות)

• sanitize_key() על שם פעולה: מפחית את שטח התווים המותר (שימושי כנגד הזרקות "יצירתיות").
• wp_unslash() לפני הסניטציה: וורדפרס עדיין חותכת כמה ערכים. שכחו מזה. wp_unslash() זה גורם לבאגים לסירוגין.
• match (PHP 8.1+): קריא, ומונע תקלות בטקסט switch.
• אין מידע רגיש נקודת קצה של ניפוי שגיאות הופכת במהירות לנקודת קצה של חילוץ. יש לשמור על נקודת קצה מינימלית.

תבנית מתקדמת: בידוד הלוגיקה בתוך שירות (DI קל)

באתרים מורכבים (Divi 5 + WooCommerce + multisite), אני מעדיף להימנע מפונקציות גלובליות ולאגד אותן במחלקה, שנטענת דרך מיני-קונטיינר. זה משפר את יכולת הבדיקה והקריאה במקרה של בעיה.

<?php
/**
 * Mini "container" ultra simple pour WordPress.
 * Objectif : centraliser l'enregistrement des hooks et les dépendances.
 */

final class App_Container {
	private array $services = [];

	public function set(string $id, callable $factory) : void {
		$this->services[$id] = $factory;
	}

	public function get(string $id) : object {
		if (!isset($this->services[$id])) {
			throw new RuntimeException("Service introuvable : {$id}");
		}
		$service = ($this->services[$id])($this);
		if (!is_object($service)) {
			throw new RuntimeException("Service invalide : {$id}");
		}
		return $service;
	}
}

final class Debug_Controller {
	public function hooks() : void {
		add_action('wp_ajax_site_debug', [$this, 'handle']);
	}

	public function handle() : void {
		if (!is_user_logged_in() || !current_user_can('manage_options')) {
			wp_send_json_error(['message' => 'Accès refusé.'], 403);
		}

		$nonce = isset($_POST['_wpnonce']) ? sanitize_text_field(wp_unslash($_POST['_wpnonce'])) : '';
		if (!wp_verify_nonce($nonce, 'site_debug_secure')) {
			wp_send_json_error(['message' => 'Nonce invalide.'], 403);
		}

		$action = isset($_POST['action_name']) ? sanitize_key(wp_unslash($_POST['action_name'])) : '';
		$allowed = ['wp_versions', 'active_plugins'];

		if (!in_array($action, $allowed, true)) {
			wp_send_json_error(['message' => 'Action non autorisée.'], 400);
		}

		$data = ($action === 'wp_versions')
			? ['wp' => get_bloginfo('version'), 'php' => PHP_VERSION]
			: ['plugins' => array_values((array) get_option('active_plugins', []))];

		wp_send_json_success($data, 200);
	}
}

// Bootstrap (mu-plugin ou plugin)
add_action('plugins_loaded', function () {
	$container = new App_Container();
	$container->set('debug_controller', fn() => new Debug_Controller());
	$container->get('debug_controller')->hooks();
}, 1);

מלכודת אמיתית: הדבקת קוד זה לתוך תוסף snippet שנטען מאוחר מדי (או לתוך ערכת נושא של צאצאים) ושכחה לגבי סדרי עדיפויות. אם ה-hook שלך מגיע אחרי לוגיקה שמתה מוקדם, אתה "חושב" שהגנת על נקודת קצה אחת... בעוד שנקודת קצה פגיעה אחרת נשארת פעילה.

תצורת שרת

זיהוי לבדו אינו מספיק: חלק גדול מהדלתות האחוריות דורשות פשוט קובץ PHP הממוקם בספריית אינטרנט נגישה. הקשחת צד השרת מבטלת לחלוטין את סוג ההתקפה הזה.

חסימת ביצוע PHP ב-wp-content/uploads (אפאצ'י)

על אפאצ'י עם .htaccessזה קלאסי. להציב ב wp-content/uploads/.htaccess.

# Créez/éditez wp-content/uploads/.htaccess

# (Ce bloc est du .htaccess ; classé en PHP ici uniquement pour le format imposé)
<IfModule mod_php.c>
  php_flag engine off
</IfModule>

<IfModule mod_php7.c>
  php_flag engine off
</IfModule>

<FilesMatch ".(php|phtml|phar)$">
  Require all denied
</FilesMatch>

מקרה קצה: בהתאם לתצורה (PHP-FPM, proxy_fcgi), php_flag ניתן להתעלם ממנו. ה FilesMatch נשאר שימושי, אבל האמין ביותר הוא כלל ברמת vhost.

חסימת ביצוע PHP בהעלאות (Nginx)

מקם זאת בבלוק השרת של האתר. התאם את נתיב הבסיס בהתאם.

# /etc/nginx/sites-available/votre-site.conf

location ^~ /wp-content/uploads/ {
  location ~ .(php|phtml|phar)$ {
    deny all;
    return 403;
  }
}

מלכודת אמיתית: אתם מוסיפים את הכלל, אבל ה-CDN שלכם (או מטמון מסוג Varnish) ממשיך לשרת גרסה ישנה יותר. נקו את המטמון ובדקו שוב.

נעילת wp-config.php (צמצום מקום)

Dans wp-config.phpניתן להגביל וקטורים מסוימים. הערה: הגדרות אלו אינן "מנקות" דבר, הן מפחיתות את ההשפעה.

<?php
// Désactive l'éditeur de fichiers (évite une escalade via admin compromis)
define('DISALLOW_FILE_EDIT', true);

// Optionnel : bloque l'installation/mise à jour via l'admin (à réserver aux workflows CI/CD)
define('DISALLOW_FILE_MODS', false);

// Réduit les fuites d'erreurs PHP en prod
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

אם אתם מנהלים אתרי אינטרנט של לקוחות: DISALLOW_FILE_EDIT זה הציל אותי מכמה מקרים שבהם חשבון מנהל גנוב הזריק דלת אחורית דרך עורך העיצוב.

כותרות HTTP שימושיות (אבטחת דפדפן)

כותרות אלו אינן עוצרות דלת אחורית של PHP, אך הן מפחיתות הזרקות וחטיפת sessions. ב-Apache:

# (Bloc .htaccess)
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
</IfModule>

עבור CSP (אסטרטגיה מבוססת תוכן), הימנעו מהעתקה-הדבקה עיוורת: Divi 5, Elementor ו-Avada מזריקים לעתים קרובות JS/CSS מוטבעים. CSP קפדני Casse התוצאה תהיה מהירה מדי אם לא תבנו אותה בהדרגה.

בדוק אם האתר שלך פגיע

המטרה אינה "לסרוק באופן אקראי". אתם רוצים שיטה ניתנת לשחזור: קו בסיס (סכומי בדיקה), חיפוש תבניות, קורלציה עם יומני רישום, ובדיקה של נקודות התמדה של וורדפרס (אפשרויות, cron, mu-plugins).

1) אימות שלמות ליבת וורדפרס (WP-CLI)

אם יש לך WP-CLI על השרת:

wp core verify-checksums --path=/chemin/vers/wordpress

אם זה מעלה קבצים שהשתנו ב wp-includes ou wp-adminנניח שהליבה נפגמה. במקרה זה, אני לא "מתקן" קובץ אחר קובץ: אני מחליף את הליבה בעותק נקי של אותה גרסה (או שאני מעדכן לגרסה 6.9.x העדכנית ביותר אם אפשר).

2) רשום את קבצי ה-PHP בהעלאות (אות חזק)

Un אתר וורדפרס אין סיבה שיהיה לתקן .php ב wp-content/uploads.

find wp-content/uploads -type f ( -name "*.php" -o -name "*.phtml" -o -name "*.phar" ) -print

מקרה קצה: חלק מהתוספים מדור קודם מציבים "מטפלים" בהעלאות (נוהג רע). בוורדפרס 6.9.4, יש להתייחס לזה כחשוד ולהעביר.

3) חפשו דפוסים אופייניים (מבלי ליפול למלכודת של תוצאות חיוביות שגויות קבועות)

אתם מחפשים אינדיקטורים, לא הוכחה אחת. שלבו מספר דפוסים:

# Fonctions fréquemment utilisées dans des backdoors
grep -RIn --exclude-dir=node_modules --exclude-dir=vendor 
  -E "eval(|assert(|base64_decode(|gzinflate(|str_rot13(|shell_exec(|system(|passthru(|proc_open(" 
  wp-content

אזהרה: base64_decode() et gzinflate() קיימים בקוד לגיטימי (רישיונות, נכסים מקודדים, SDK). מה שמתריע בפניי: שימוש משולב + מחרוזות ארוכות מאוד + ביצוע מאחורי הקלעים (eval, assert) + ערפול.

4) בדוק את התוספים וה-drop-ins של ה-mu

שני מקומות שרובם מתעלמים מהם:

• wp-content/mu-plugins/ (טעון אוטומטית)
• wp-content/ עם כניסות נפתחות: object-cache.php, advanced-cache.php, db.php

ls -la wp-content/mu-plugins
ls -la wp-content | egrep "object-cache.php|advanced-cache.php|db.php"

כבר ראיתי דלתות אחוריות נסתרות ב object-cache.php באתרים עם Redis "מותקן ידנית". הקובץ נראה רגיל, אבל include התנאי הצביע על קובץ בהעלאות.

5) בדוק את WP-Cron (שמירה על קבצים שקטים)

גישה נקייה (clean persistence) משתמשת לעיתים קרובות ב-WP-Cron כדי "להתקין מחדש" את הדלת האחורית אם מסירים אותה.

wp cron event list --fields=hook,next_run,recurrence --format=table

חפש אחר:

• ווים לא ידועים עם שמות אקראיים
• חזרות תכופות מאוד
• אירועים שקוראים לפונקציות "תועלת" לא מתועדות

6) אבחון דרך מסד הנתונים (אפשרויות ומשתמשים)

שתי שאילתות SQL פשוטות (שיבוצעו באמצעות לקוח SQL, או wp db query):

wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

wp db query "SELECT ID, user_login, user_email FROM wp_users ORDER BY ID DESC LIMIT 20;"

מה שאני מחפש לעתים קרובות:

• אפשרות טעינה אוטומטית ענקית (מטען ערום, ספאם SEO, סקריפט מוזרק)
• מנהל חדש "שאינו קיים בשום הליך פנימי"

7) קרא את הלוגים: האות שסורקים לא רואים

ב-Nginx/Apache, חפש נקודות גישה לנתיבים חריגים:

• /wp-content/uploads/ ואחריו קובץ .php
• בקשות ל admin-ajax.php עם פעולות לא ידועות
• מתוך 200 על קבצים שאמורים להיות סטטיים

פקודה כללית (התאמת נתיב הלוג):

grep -E "uploads/.*.(php|phtml|phar)|admin-ajax.php" /var/log/nginx/access.log | tail -n 200

תרשים אבחון (תסמינים נפוצים)

סימפטום	סיבה סבירה	אימות	פתרון
הפניות SEO רק בנייד	דלת אחורית מותנית (UA/geo) בתוסף או wp_options	השווה HTML המוגש דרך curl desktop לעומת mobile, בדוק אפשרויות מגושמות	שחזור מגיבוי נקי + החלפת תוספים + הקשחת העלאות
קבצי PHP מופיעים ב uploads	העלאה ללא סינון + ביצוע PHP מותר	find wp-content/uploads -name "*.php"	חסימת PHP בהעלאות + ניקוי + תיקון תוסף פגיע
מנהלי "רוחות" חוזרים	WP-Cron או mu-plugin מזריקים מחדש משתמש	wp cron event listלִבדוֹק mu-plugins	הסר את ההתמדה + סובב סודות + שחזור מסד נתונים במידת הצורך
צריכת מעבד גבוהה / קפיצות בתהליכי PHP-FPM	ספאם, כוח גס או כרייה/סריקה אחורית	למעלה, יומני גישה, בקשות חוזרות ונשנות	WAF/מגבלת קצב + ניקוי + חסימת נקודות קצה חשופות
אימיילים יוצאים חריגים	הזרקה באמצעות טופס + דיוור אחורי	יומני SMTP, חיפוש mail( ב wp-content	טופס נכון + SPF/DKIM + סיבוב סיסמאות + ניקוי

שגיאות אבטחה נפוצות

שגיאה	ריסק	פתרון
העתיקו את הקוד מ-"cleaner" אל functions.php של הנושא	התיקון אבד כאשר ערכת הנושא שונתה, והיא בוצעה בהקשר הלא נכון.	צור תוסף ייעודי או תוסף mu עם גרסה מוגדרת
שכחת נקודה-פסיק/סוגריים בתוסף mu-plugin	שגיאה חמורה, אתר מושבת (ולפעמים עקיפת הגנות)	בדיקה בסביבת בימוי, הפעלת יומני רישום, פריסה דרך CI
Utiliser wp_ajax_nopriv_* "לבדוק" ולשכוח להסיר אותו	נקודת קצה ציבורית ניתנת לניצול	לעולם אל תשתמשו ב-nopriv ככלי ניהול, ותמיד השתמשו ב-capability control + nonce.
פעולות ומסננים מבלבלים (למשל: add_filter במקום add_action)	קוד האבטחה לא מבוצע, מה שיוצר תחושת ביטחון כוזבת.	בדוק את ה-hooks, הוסף בדיקות זמניות ויומני רישום
בדיקה ישירה בייצור ללא גיבוי	אובדן נתונים, זמן השבתה, שחזור לא שלם	תמונת מצב + בימוי + תוכנית חזרה למצב אחר
שכחה לנקות את המטמון (תוסף/CDN)	אתה חושב שהסרת הפניה/דלת אחורית, אבל היא עדיין מוצגת במטמון.	ניקוי מטמון תוסף + CDN + דפדפן, בדיקה חוזרת עם curl
שימוש בוו לא מתאים (מוקדם מדי/מאוחר מדי)	הגנה לא יושמה, תנאי מרוץ	מסיבות בטיחותיות: plugins_loaded מוקדם, ולהימנע init אם אפשר
קטע שבור על ידי תוסף קטעים	קוד מקוצר/מקודד, עדכון שמסיר הגנה	פריסה כתוסף גרסה (Git)
עקוב אחר מדריך PHP 5/7 ישן	אי תאימות, אזהרות, התנהגות בלתי צפויה ב-PHP 8.1+	התאמה להקלדה ול-API הנוכחיים, בדיקה ב-PHP 8.1/8.2
קישורים קבועים לא נוצרו מחדש לאחר השחזור	שגיאות 404, התנהגות מוזרה, נקודות קצה נסתרות שנשארות נגישות	צור מחדש קישורים קבועים ובדוק את כללי השרת

רשימת בדיקה להתקשות

• חסום PHP ב wp-content/uploads (Nginx/Apache) ולבדוק ש-a .php מחזירה נכון את 403.
• בדוק את סכומי הבדיקה המרכזיים דרך WP-CLI ולהחליף את כל הקבצים שהשתנו.
• הסר תוספים/ערכות נושא לא רשמיות (בטלה) והחלפה בגרסאות מ wordpress.org/plugins או המוציא לאור.
• לִבדוֹק mu-plugins ופגישות כניסה (object-cache.php, advanced-cache.php).
• רשימת מנהלים וביקורת (ולבטל את אלה שאינם מוצדקים).
• סיבוב של סודות סיסמאות WP, סיסמאות FTP/SFTP, סיסמאות מסד נתונים, מפתחות API, ו AUTH_KEY/SALT ב wp-config.php.
• השבת את עורך הקבצים (DISALLOW_FILE_EDIT).
• הגברת הרשאות הקבצים (לא 777, בעלים עקבי, אין כתיבה גלובלית).
• הפעלת ניטור שינויים (hash, mtime) מופעל wp-content ומתריע.
• עדכון וורדפרס 6.9.4+ ואת כל המערכת האקולוגית, לאחר מכן הסירו את מה שלא מתוחזק.

מה אם האתר כבר נפגע?

אם יש לכם ספקות רציניים, הימנעו מהגישה של "אני אמחק שני קבצים וזה יעשה את זה". דלת אחורית היא לעתים קרובות... une התמדה בקרב כמה. הנה תוכנית פעולה המבוססת על אירועים אמיתיים.

1. לבודד העבר את האתר למצב תחזוקה (או הגבל את הגישה לפי כתובת IP) בזמן שאתה בודק. עבור אתר מסחר אלקטרוני, עשו זאת מחוץ לשעות העומס במידת האפשר, אך אל תתעכבו.
2. שמור לצורך ניתוח צור עותק מלא של הקבצים ומסד הנתונים שלך. גיבוי זה אינו מיועד לשחזור, אלא להבנה (ואולי גם לספק האירוח/חברת הביטוח שלך).
3. זהה את נקודת הכניסה תוסף פגיע, חשבון מנהל פגוע, פרטי FTP, לוח בקרה של אחסון. בלי לבדוק את אלה, הניקוי שלך חסר טעם.
4. החלפת ליבת וורדפרס על ידי עותק נקי (אותה גרסה או עדכון). בדוק עם wp core verify-checksums.
5. התקן מחדש תוספים וערכות נושא ממקורות מהימנים מחק את התיקייה ולאחר מכן התקן מחדש. אל "תנקה" תוסף שאינו פעיל: החלף אותו.
6. לְנַקוֹת wp-content/uploads למחוק הכל .php/.phtml/.pharבדוק קבצים ששונו לאחרונה. ניתן גם להסתיר דלתות אחוריות ב... .ico ou .jpg שימוש ב-PHP אם השרת מפרש באופן שגוי (נדיר, אך נראה).
7. ביקורת מסד הנתונים :
   • הסר משתמשים חשודים
   • לִבדוֹק wp_options עבור אפשרויות ענקיות או לא ידועות
   • בדקו את כתובות ה-URL של האתר (home/siteurl) ואת ההפניות.
8. סיבוב של סודות :
   • איפוס כל הסיסמאות (WP + דוא"ל + SFTP + מסד נתונים אם נחשף)
   • לשנות את מפתחות אבטחה (AUTH_KEY/SALTs) ב wp-config.php
9. בדיקת WP-Cron ומשימות מערכת : הסר אירועים לא ידועים, ודא שאף cron של המערכת לא מזריק מחדש קבצים.
10. להקשיח את השרת חסום PHP בהעלאות, חסום גישה ל .gitהוסף הגבלת קצב ל wp-login.php אם רלוונטי.
11. בדיקה לאחר העלאה מחדש ניטור יומני רישום ושינויים בקבצים במשך 72 שעות. הדבקות חוזרות מתרחשות במהירות אם הגורם נמשך.

מכשול נפוץ שאני רואה הוא שחזור גיבוי ש"עובד" אבל כבר נפגע. אם אין לכם נקודת שחזור אמינה, התחילו בבנייה מחדש (ניקוי ליבה + תוספים) וייבאו מחדש רק את התוכן (העלאות מסוננות + מסד נתונים נקי).

טיפים לתחזוקה ותאימות

ב-WordPress 6.9.4, תחזוקת אבטחה יעילה דומה ל-DevOps קל משקל: מלאי, עדכונים, בדיקות שלמות והפחתת שטח.

תאימות Divi 5 / Elementor / Avada: היכן באמת מסתתרות הדלתות האחוריות

• תוספים של צד שלישי זהו האזור האדום. שמור רשימה של תוספים, המפרסם שלהם ותאריך העדכון האחרון שלהם.
• תבניות מיובאות בוני קבצי JSON/HTML מייבאים. דלת אחורית של PHP לא מגיעה "ישירות" מתבנית, אבל תבנית יכולה להחדיר JS זדוני אם אתם מאפשרים סקריפטים.
• קטעי קוד בוני אתרים רבים משתמשים בתוסף snippet. זה נוח, אבל זה גם מציג משטח תקיפה (אחסון מסד נתונים, ביצוע גלובלי). עדיף להשתמש בתוסף מותאם אישית עם גרסה מוגדרת.

ביצועים/קידום אתרים (SEO): השפעות של ניקוי

• לאחר הסרת דפי ספאם, תכננו 404 נהל אותם כראוי (Search Console) והימנע מהפניות מסיביות לבית.
• לאחר תהליך ההקשחה (שגיאה 403 בהעלאות), ודאו שקבצי המדיה שלכם (תמונות, WebP) נשארים נגישים. בדרך כלל הם אמורים להיות נגישים: רק ביצוע PHP חסום.
• לאחר השחזור, בדקו את מטמוני השרת (מטמון עמוד, מטמון אובייקט, CDN). מטמון יכול "להחיות" הפניה זדונית בצד הלקוח.

בדיקות אוטומטיות מומלצות

• WP-CLI ב-cron : wp core verify-checksums + התראה אם ​​שונה.
• קבצי ניטור התראה בנוגע ליצירת .php ב uploads ושינוי של כניסות נפתחות.
• רישום שמור יומני גישה/שגיאות למשך 30 יום לפחות, אחרת אתה חוקר בצורה עיוורת.

---

משאבים

• developer.wordpress.org — wp-config.php (קבועים, מפתחות אבטחה)
• developer.wordpress.org — Nonces (הגנה על CSRF)
• developer.wordpress.org — current_user_can()
• wordpress.org - הקשחת וורדפרס
• developer.wordpress.org — WP‑CLI: סכומי בדיקות אימות מרכזיים
• core.trac.wordpress.org — מעקב אחר תיקוני ליבה של וורדפרס (Trac)
• github.com/WordPress — wordpress-develop (מקור ויחסי ציבור)
• php.net — eval() (סיכונים והתנהגות)

שאלות נפוצות

כיצד להבחין בין תוצאה חיובית כוזבת לבין תוצאה אחורית אמיתית?

אינדיקטור מבודד (למשל: base64_decode()) אינו מספיק. דלת אחורית לעיתים קרובות משלבת ערפול (base64/gzinflate/rot13), ביצוע (הערכה/טענה), ו הפעלה מותנית (פרמטר GET, קובץ cookie, סוכן משתמש). הקורלציה עם הלוגים (בקשות לקובץ) היא לעתים קרובות מכרעת.

למה השבתת PHP בהעלאות כל כך יעילה?

מכיוון שהרבה התקפות מסתיימות ב"השמטת קובץ". אם PHP לא רץ בהעלאות, קובץ cache.php הופך להורדה פשוטה, לא לשער.

האם וורדפרס 6.9.4 "מגן" מפני דלתות אחוריות?

הליבה חזקה משמעותית יותר ממה שהייתה לפני מספר שנים, אך דלת אחורית לעיתים רחוקות מנצלת פגיעות של ליבה מודרנית. בדרך כלל היא עוברת דרך תוסף פגיע, חשבון פרוץ או שרת שתצורתו אינה מוגדרת כראוי. מכאן החשיבות של סכומי בדיקה והקשחת שרת.

האם WP-CLI חובה?

לא, אבל בלי WP-CLI אתם מאבדים כלים מרכזיים (סכומי בדיקה, ביקורת cron, שאילתות מסד נתונים). באתר אינטרנט מתקדם, אני מחשיב את זה כתנאי תפעולי מוקדם.

מה אם אני לא יכול לגשת ליומנים (אירוח משותף)?

בקשו גישה ליומנים מספק האירוח שלכם. אם הם לא מספקים גישה כזו, הפעילו זמנית רישום אפליקציות (תוסף יומנים), אך שימו לב שאתר אינטרנט שנפרץ יכול לזייף את היומנים שהוא מציג. יומני שרת נותרים המקור האמין ביותר.

האם תוספי אבטחה מספיקים?

הם עוזרים (WAF, התראות, ניטור), אבל הם לא מחליפים שחזור נקי או הקשחה (העלאות, כניסות, סיבוב מפתחות). ראיתי דלתות אחוריות שמנטרלות בשקט את תוסף האבטחה דרך אפשרות מסד נתונים.

האם עליי לשנות את ה"מלחים" של וורדפרס לאחר פשרה?

כן. שינוי מפתחות אבטחה מבטל עוגיות וסשנים קיימים. עיין בתיעוד הרשמי בנושא מפתחות אבטחה.

האם דלת אחורית יכולה להיות מבוססת אך ורק על מסד נתונים?

כן. באמצעות אפשרויות שנטענות אוטומטית, קטעי טקסט המאוחסנים במסד הנתונים, או תוכן המוזרק לתוך ווידג'טים/בלוקים. זה פחות "גלוי" מקובץ, וזו הסיבה שביקורת wp_options הוא שימושי.

אילו אזורים יש לבדוק תחילה באתר Elementor/Divi/Avada?

wp-content/uploads, mu-plugins, חלונות מטמון (cache drop-ins) ורשימת התוספים. בוני תוספים מייצרים הרבה קבצים ומטא-דאטה, מה שמקשה על זיהוי אנומליות: אתם צריכים קו בסיס (סכומי בדיקה + מלאי).

למה להימנע מ"ניקוי" ידני של תוסף?

מכיוון שאינך יודע מה השתנה, ומכיוון שאתה מסתכן בהשארת עקבות מתמשכים, מחק את תיקיית התוסף והתקן אותה מחדש ממקור מהימן. אם מדובר בתוסף פרימיום, הורד אותו שוב מחשבון המפרסם שלך.

מהי הבדיקה הטובה ביותר לאחר ניקוי?

בדיקה משולבת: סכומי בדיקות ליבה תקינים, אין PHP בהעלאות, אין אירועי cron לא ידועים, אין פעילות מנהל חשודה, וניטור יומן במשך 48-72 שעות. אם משהו "מופיע שוב", הסיבה (נקודת הכניסה) לא מטופלת.