תיקון ממצאי Pentest בוורדפרס: מדריך לחברות SaaS

אם חברת ה-SaaS שלכם סיימה לאחרונה מבדק חדירה (Penetration Test), אני מניח שדו"ח הממצאים כבר נחת בתיבת המייל שלכם. ייתכן שזו דרישה של SOC 2, וייתכן שלקוח ארגוני דרש זאת במסגרת שאלון אבטחה. כך או כך, עליכם לטפל בממצאים לפני הבדיקה החוזרת.

אותם עשרה ממצאים חוזרים כמעט בכל דו"ח pentest של וורדפרס. בפוסט זה אסביר איך לתקן כל אחד מהם, עם קוד שתוכלו ליישם כבר היום.

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

משטח התקיפה של אתר וורדפרס בחברת SaaS – דומיין משותף, מפתחות API לשירותים חיצוניים ווקטורי pentest נפוצים

מה דו"ח Pentest באמת אומר לכם

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

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

SOC 2, ISO 27001 ו-PCI DSS דורשים מבדקי חדירה שנתיים ותיעוד של התיקונים. "נתקן את זה אחר כך" אינו עובר אודיט. עליכם לתקן, לתעד את התיקון ולאמת אותו לפני הבדיקה החוזרת.

מיון: חומרה מול מורכבות תיקון

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

תיקון 10 ממצאי ה-Pentest הנפוצים בוורדפרס

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

1. Cross-Site Scripting (XSS) בתוספים ותבניות

XSS אחראי לכמחצית מכלל הפגיעויות בתוספי וורדפרס. הבודק מצא מקום בו קלט משתמש מוצג בלי escaping, מה שמאפשר הזרקת סקריפטים.

אם ה-XSS נמצא בתוסף צד שלישי, עדכנו אותו. אם אין תיקון זמין, החליפו את התוסף. כשהבעיה נמצאת בקוד התבנית המותאמת שלכם, תקנו את ה-output escaping:

// Vulnerable: raw output
echo $user_input;

// Fixed: escaped output
echo esc_html( $user_input );

// For HTML attributes
echo '<a href="' . esc_url( $link ) . '" title="' . esc_attr( $title ) . '">';

// For content that should allow safe HTML
echo wp_kses_post( $content );

כל פקודת echo שמוציאה מידע בשליטת המשתמש דורשת פונקציית escaping. וורדפרס מספקת את esc_html(), esc_attr(), esc_url() ו-wp_kses_post() עבור הקשרים שונים. השתמשו בהן באופן עקבי באתר וורדפרס מוקשח.

2. XML-RPC Brute Force

וורדפרס מגיעה עם xmlrpc.php פעיל כברירת מחדל. המתודה system.multicall מאפשרת לתוקפים לנסות מאות סיסמאות בבקשת HTTP אחת, תוך עקיפה מלאה של הגבלות קצב ההתחברות.

חסמו זאת ברמת השרת. פילטר ברמת PHP עדיין טוען את כל וורדפרס בכל בקשה:

# Nginx
location = /xmlrpc.php {
    deny all;
    return 403;
}

# Apache .htaccess
<Files xmlrpc.php>
    Require all denied
</Files>

כתבתי מדריך מפורט על ביטול XML-RPC בוורדפרס שמכסה (בין היתר) מקרי קצה עם Jetpack ושירותים אחרים שתלויים בו.

3. תוספים לא מעודכנים עם CVE ידועים

לפי דו"ח Patchstack לשנת 2026 על מצב אבטחת וורדפרס, 96% מפגיעויות וורדפרס מגיעות מתוספים ותבניות. בשנת 2025 לבדה התגלו 11,334 פגיעויות חדשות.

הריצו ביקורת מהירה:

wp plugin list --fields=name,version,update_version,status
wp theme list --fields=name,version,update_version,status

עדכנו קודם הכול בסביבת staging, בדקו פונקציונליות ליבה ורק אחר כך העלו לפרודקשן. עבור SOC 2, תעדו כל עדכון כטיקט ניהול שינויים (Change Management) עם מספרי הגרסה לפני ואחרי.

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

4. הזרקת SQL

הזרקת SQL בוורדפרס נובעת כמעט תמיד מקוד מותאם או מתוספים ישנים שבונים שאילתות עם קלט גולמי של המשתמש, במקום להשתמש ב-$wpdb->prepare().

// Vulnerable: direct variable interpolation
$results = $wpdb->get_results(
    "SELECT * FROM {$wpdb->posts} WHERE post_title = '$search_term'"
);

// Fixed: parameterized query
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->posts} WHERE post_title = %s",
        $search_term
    )
);

חפשו בקוד שלכם כל שימוש ישיר ב-$wpdb->query(), $wpdb->get_results() או $wpdb->get_var() שלא עוטף את השאילתה ב-$wpdb->prepare(). אלה, בפשטות, נקודות ההזרקה שלכם.

5. מניית משתמשים (User Enumeration)

בודקי חדירה מסמנים שני וקטורי מנייה בוורדפרס. ארכיוני המחברים ב-/?author=1 מפנים לכתובת URL שמכילה את שם המשתמש. ה-REST API בנתיב /wp-json/wp/v2/users מחזיר שמות משתמשים לבקשות לא מאומתות.

// Block author archive enumeration
add_action( 'template_redirect', function() {
    if ( is_author() ) {
        wp_redirect( home_url(), 301 );
        exit;
    }
});

// Restrict REST API user endpoint to authenticated users
add_filter( 'rest_authentication_errors', function( $result ) {
    if ( true === $result || is_wp_error( $result ) ) {
        return $result;
    }
    $current_route = $_SERVER['REQUEST_URI'] ?? '';
    if ( strpos( $current_route, '/wp/v2/users' ) !== false
        && ! is_user_logged_in() ) {
        return new WP_Error(
            'rest_forbidden',
            'Authentication required.',
            array( 'status' => 401 )
        );
    }
    return $result;
});

למבט מעמיק יותר על נעילת ה-REST API בלי לשבור את האתר, עיינו באבטחת ה-REST API של וורדפרס. תוכלו גם לשנות את כתובת ה-URL לממשק הניהול של וורדפרס בכדי לצמצם תעבורת בוטים.

6. Security Headers חסרים

מדובר באחד הממצאים הנפוצים ביותר. כל בודק חדירה בודק את Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy ו-Permissions-Policy.

# Nginx - add to server block
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;

PCI DSS 4.0 דורש כעת את Content-Security-Policy באופן ספציפי. התחילו עם CSP במצב report-only, עקבו אחרי ההפרות ורק אחר כך אכפו. כיסיתי את התהליך המלא במדריך הוספת Security Headers לאתרי וורדפרס.

7. הגדרת SSL/TLS חלשה

בודקי חדירה מסמנים גרסאות TLS מיושנות (1.0 ו-1.1) וחבילות הצפנה חלשות. דפדפנים מודרניים אינם צריכים אותן, ותקני תאימות אוסרים עליהן.

# Nginx - TLS hardening
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;

לאחר היישום, בדקו את ההגדרות באמצעות SSL Labs. כוונו לדירוג A או A+. מידע נוסף על תעודות SSL לאתרי וורדפרס.

8. מצב Debug בפרודקשן

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

// wp-config.php - production settings
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', false );
define( 'DISALLOW_FILE_EDIT', true );

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

9. חשבונות מנהל מיותרים

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

wp user list --role=administrator --fields=ID,user_login,user_email

בדקו כל חשבון. הורידו הרשאות למשתמשים שלא צריכים גישת מנהל מלאה לרמת Editor או Author. מחקו חשבונות ששייכים לעובדים לשעבר או לסוכנויות. ISO 27001 דורש בקרת גישה מבוססת תפקידים (RBAC), וזו הדרך הקלה ביותר להוכיח זאת.

10. היעדר אימות דו-שלבי (MFA)

היעדר MFA בחשבונות מנהל הוא ממצא כמעט מובטח בכל pentest. עם מניית משתמשים וסיסמה חלשה, תוקף נמצא במרחק credential אחד מגישה מלאה לאתר.

השתמשו ב-TOTP מבוסס אפליקציה, כמו Google Authenticator או Authy, או במפתחות חומרה. אכפו זאת על כל משתמש עם הרשאות פרסום או ניהול.

כיסיתי אפשרויות תוספים ושלבי הגדרה במדריך אימות דו-שלבי בוורדפרס.

מיפוי תיקונים לתקני תאימות

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

שמרו רישום לכל תיקון: מה השתנה, מתי, מי אישר ואיך הוא אומת. המבקרים אינם רוצים רק את התיקון. הם רוצים לראות את שרשרת הראיות.

תהליך תיקון שמבקרים אוהבים

תיקון פגיעויות הוא חצי מהעבודה. החצי השני הוא תיעוד שישרוד audit. הנה תהליך עבודה שישמח כל מבקר:

תהליך תיקון בחמישה שלבים, מדו"ח pentest ועד אישור הבדיקה החוזרת

1. צרו טיקט לכל ממצא. מפו כל ממצא מדו"ח ה-pentest לטיקט בכלי ניהול הפרויקט. כללו את מזהה הממצא המקורי, ציון ה-CVSS והרכיב המושפע.
2. תקנו על branch נפרד. לכל תיקון צריך להיות branch משלו ו-Pull Request. הודעת ה-commit צריכה להפנות למזהה הממצא.
3. בדקו בסביבת staging. ודאו שהתיקון עובד ואינו שובר פונקציונליות קיימת. צלמו מסך או תעדו את האימות (כמובן).
4. העלו לפרודקשן ותעדו. רשמו את תאריך ההעלאה, מי ביצע אותה ואיך אותו תיקון אומת.
5. בקשו בדיקה חוזרת. בקשו מהבודק המקורי לאמת את הממצאים הספציפיים. האישור שלו הוא הראיה שלכם ל-audit.

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

שאלות נפוצות

שאלות נפוצות בנושא תיקון ממצאי pentest בוורדפרס:

סיכום

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

תקנו קודם את הפריטים הקריטיים, תעדו הכול ותזמנו את הבדיקה החוזרת. השילוב בין תיקונים טכניים לבין תיעוד שמוכן ל-audit הוא מה שמבדיל בין דו"ח שעובר לבין סבב התעסקות נוסף.

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