לאחרונה קיבלנו פנייה מלקוח: אתר MODX שלהם התחיל פתאום להפנות מבקרים לדפי פישינג. במהלך האבחון גילינו שבסניפט מותאם אישית $_GET['id'] לא בוצע escape, מה שאיפשר לתוקף להזריק SQL. ההגנה הסטנדרטית של MODX (tokens, hashes) לא עזרה – הפגיעות הייתה בשכבת היישום. מקרים כאלה אינם נדירים: לפי OWASP, 70% מהפריצות ל-CMS מתרחשות עקב שגיאות בקוד מותאם אישית. תוספים מיושנים (למשל, FormLister), הרשאות שגויות על core/, /manager/ פתוח ללא הגבלת IP – בעיות טיפוסיות שאנו מוצאים כמעט בכל פרויקט שלישי. הנזק הכולל מפריצה לעסקים קטנים יכול להיות משמעותי, כולל שחזור נתונים ופגיעה במוניטין. ביקורת ידנית מזהה פי 2–3 יותר פגיעות מאשר סורקים אוטומטיים ומספקת הקשר לתיקונים נכונים. קבלו ביקורת אבטחה ל-MODX כדי להימנע ממצבים כאלה.
אנו מבצעים ביקורות אתרי MODX כבר למעלה מ-5 שנים. במהלך תקופה זו ניתחנו יותר מ-120 פרויקטים – החל מדפי נחיתה קטנים ועד פורטלים ארגוניים גדולים. אנו מבטיחים שלאחר הבדיקה תקבלו רשימה קונקרטית של פגיעות והמלצות לסילוקן. בממוצע, אנו מוצאים 12–15 פגיעות ברמות חומרה שונות לכל פרויקט, כאשר 80% מהן קשורות לרכיבים מיושנים. תיקון פגיעות קריטיות חוסך בדרך כלל עלויות משמעותיות על שחזור לאחר פריצה. השוואה לסורקים אוטומטיים: ניתוח ידני יעיל פי 3 לאיתור פגיעות בלוגיקה עסקית.
מדוע תוספים מיושנים מאיימים על האבטחה?
תוספים מיושנים הם אחד הגורמים העיקריים לפריצות. לדוגמה, FormLister (גרסאות לפני 0.8.3) מכיל פגיעות המאפשרת ביצוע קוד שרירותי. החלפתו ב-FormIt מפחיתה את ההסתברות להתקפות RCE ב-70% – אנו רואים שיפור זה ב-90% מהפרויקטים לאחר ביקורת.
| תוסף | סטטוס | המלצה |
|---|---|---|
| FormLister | מיושן, פגיעויות RCE | החלף ב-FormIt |
| Ajaxform | מיושן | השתמש ב-pdoTools או מותאם אישית |
| miniShop2 | עדכני, דורש הגדרה | עדכן לגרסה האחרונה |
| Tickets | מיושן | החלף ב-modExtra או Tickets 2.0 |
כיצד להגן על קוד מותאם אישית מפני הזרקות SQL?
אנו סורקים את כל הסניפטים, התוספים והמודולים עבור שאילתות SQL ישירות ללא escape. אנו משתמשים ב-grep ובניתוח סטטי. לפי ויקיפדיה, הזרקת SQL היא אחת הפגיעויות הנפוצות ביותר, ויש לבצע את כל שאילתות מסד הנתונים דרך $modx->query() או $modx->newQuery().
הכלל המרכזי: לעולם אל תעבירו $_GET או $_POST ללא escape לתוך שאילתה. דוגמה לפגיעות:
// Плохо: SQL Injection
$id = $_GET['id'];
$result = $modx->query("SELECT * FROM modx_site_content WHERE id = $id");
// Хорошо: экранирование
$id = (int)$_GET['id'];
$result = $modx->getObject('modResource', $id);בנוסף, אנו בודקים אם // Плохо: SQL Injection $id = $_GET['id']; $result = $modx->query("SELECT * FROM modx_site_content WHERE id = $id"); // Хорошо: экранирование $id = (int)$_GET['id']; $result = $modx->getObject('modResource', $id); נמצא בשימוש ישיר – שגיאה זו מתרחשת ב-60% מהסניפטים המותאמים אישית. אנו ממליצים תמיד להשתמש ב-$modx->db->query() או getObject עם קשירת פרמטרים.
כיצד להגן על לוח הניהול של MODX?
הגבל את newQuery לפי IP – השיטה האמינה ביותר. אם לא אפשרי, הפעל אימות דו-שלבי (MODX תומך ב-TOTP דרך תוסף). כמו כן חובה:
-
/manager/(HTTPS בלבד) -
session_cookie_secure = 1 -
session_cookie_httponly = 1 - הגבל ניסיונות התחברות כושלים:
session_cookie_samesite = Strict,failed_login_attempts = 5
דוגמה לתצורת Nginx:
location /manager/ { allow 192.168.1.0/24; deny all; } לפי הסטטיסטיקות שלנו, 70% מהפריצות ל-MODX מתרחשות דרך ניחוש סיסמאות ב-blocked_minutes = 60. הגדרת מגבלת ניסיונות מפחיתה את הסיכון להתקפת כוח גס פי 10.
כיצד אנו מבצעים את הביקורת: טכנולוגיה ותהליך
אנו משתמשים גם בסורקים אוטומטיים וגם בניתוח ידני. הכלים העיקריים:
- סריקה: Nikto, ffuf (לקבצים נסתרים), WPScan (מותאם ל-MODX)
- ניתוח תצורה: הרשאות קבצים, הגדרות מערכת MODX, כותרות HTTP
- ביקורת קוד: grep עבור
location /manager/ { allow 192.168.1.0/24; deny all; },/manager/,$_GETברכיבים מותאמים אישית - בדיקת גרסאות: התאמת רשימת התוספים מול מאגר הפגיעויות (CVE)
שלבי התהליך:
- אבחון (שעה): איסוף מידע על גרסת MODX, תוספים מותקנים, גרסת PHP, הגדרות שרת.
- סריקה (שעתיים): חיפוש אוטומטי אחר פגיעויות נפוצות, סריקת ספריות.
- ניתוח מעמיק (4 שעות): בדיקה ידנית של קוד מותאם אישית, קבצי תצורה, הרשאות גישה.
- דוח (שעתיים): תיעוד כל פגיעות שנמצאה עם רמת חומרה, המלצות שלב-שלב לתיקון.
זמן כולל: 1 עד 3 ימים בהתאם לכמות הקוד המותאם אישית.
| הגדרה | ערך מומלץ |
|---|---|
| session_cookie_secure | 1 |
| session_cookie_httponly | 1 |
| session_cookie_samesite | Strict |
| failed_login_attempts | 5 |
| blocked_minutes | 60 |
| use_editor | 1 (עם הרשאות מוגבלות) |
דוגמה לבדיקות נוספות
אנו גם בודקים פגיעויות Local File Inclusion (LFI) ובודקים אם נעשה שימוש בגרסת PHP מיושנת (למשל, 7.4, שכבר אינה מקבלת עדכוני אבטחה). הרשימה המלאה של הבדיקות כלולה בדוח הביקורת.
מה כלול בתוצאה
עם סיום התהליך תקבלו:
- דוח עם תיאור מפורט של הפגיעויות שנמצאו (צילומי מסך, הוכחות)
- המלצות לתיקון עם סדרי עדיפויות
- תיקון בעיות קריטיות (בתיאום)
- תיעוד לחיזוק תצורת Nginx/Apache ו-MODX
- רשימת בדיקה לפיתוח מאובטח עבור הצוות שלכם
- סריקה חוזרת לאחר תיקון הפגיעויות (לפי בקשה)
צרו קשר להערכה ראשונית של הפרויקט שלכם – נספק זמנים ועלות מדויקים לאחר אבחון חינמי מהיר.
זמנים ועלות
ביקורת אורכת מיום אחד (סטנדרטי) עד 3 ימים (מקיף עם קוד מותאם אישית). העלות מחושבת באופן פרטני, תלויה בכמות התוספים שנבדקו ובמספר שורות הקוד במודולים מותאמים אישית. תיקון הפגיעויות שנמצאו אורך בין 4 ל-16 שעות בהתאם למורכבות. קבלו ייעוץ על ביקורת האבטחה של אתר MODX שלכם.
רשימת בדיקה לבדיקה עצמית (טעויות נפוצות)
- התיקייה
$_POSTלא חייבת להיות בשורש האינטרנט. -
$db->query()לא חייב להיות נגיש דרך הדפדפן. - יש להסיר את התיקייה
core. - כל התוספים מעודכנים.
- הרשאות על התיקייה
config.core.php– ללא ביצוע PHP. -
setup/ו-assets/מופעלים. - הגישה ל-
session_cookie_secureמוגבלת. - קוד מותאם אישית נבדק עבור הזרקות SQL.
הזמינו ביקורת אבטחה ל-MODX עוד היום והגנו על האתר שלכם מפני פריצות.







