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

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

מדוע קוד שנוצר על ידי AI דורש ביקורת

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

הנפוצות ביותר שאנו רואים:

• שימוש ב-$_GET או $_POST ללא ניקוי (sanitization)
• אימות nonce חסר בעת שליחת טפסים
• שאילתות ישירות לבסיס הנתונים ללא $wpdb->prepare()
• שימוש ב-eval() או exec() להתנהגות דינמית
• פלט נתוני משתמש ללא esc_html() או esc_attr()

אלה אינם מקרי קצה אקזוטיים. הם מופיעים באופן קבוע בפלט של LLM — אפילו מהמודלים הטובים ביותר.

שלב 1: אימות הנחיה (Prompt validation)

לפני שה-AI כותב שורה אחת, אנו מנתחים את תיאור המשתמש. שלב זה תופס שתי קטגוריות של בעיות:

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

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

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

שלב 2: בדיקת PHP (linting) במיכל מבודד

ברגע שה-AI מייצר קוד PHP, הוא מופעל דרך php -l בתוך מיכל Docker המבודד לחלוטין מכל דבר אחר. זה תופס שגיאות תחביר לפני שהתוסף מגיע בכלל להתקנת וורדפרס.

אבל אנחנו הולכים רחוק יותר: אם הבדיקה נכשלת, המערכת לא פשוט דוחה את הפלט. היא שולחת את השגיאה בחזרה ל-AI עם הנחיה לתיקון — מה שאנו מכנים ריפוי (healing). ה-AI רואה את השגיאה שלו ומנסה שוב, עד שלוש פעמים.

זה אומר שמשתמשים כמעט לעולם לא רואים הודעת "יצירה נכשלה". הם רואים זמן יצירה מעט ארוך יותר — וקוד עובד.

שלב 3: סריקת אבטחת קוד

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

פונקציות מסוכנות: eval(), exec(), system(), shell_exec(), passthru() — כל אחת מאלה חוסמת את שחרור התוסף.

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

בדיקות הרשאות חסרות: מטפלי AJAX שאינם קוראים ל-current_user_can() לפני ביצוע כל פעולה מיוחסת.

אימות Nonce חסר: מעבדי טפסים שאינם קוראים ל-wp_verify_nonce() או check_ajax_referer().

פלט לא מוצפן (Unescaped output): echo $_GET[...], echo $user_input ללא פונקציות הצפנה.

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

איך נראה דוח הביקורת

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

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

הדוח נוצר אוטומטית ומצורף להורדת התוסף. הוא שימושי הן לביטחונך והן להראות ללקוחות שלקחת אבטחה ברצינות.

שלב 4: אימות בעת שמירה

זה אינו חלק מהיצירה הראשונית — הוא חל כאשר משתמשים עורכים ידנית קוד תוסף בעורך PAGEnza.

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

מגבלות הביקורת האוטומטית

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

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

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