ביקורת אבטחה של Magento 2: בדיקת חולשות מלאה

ביקורת אבטחה של Magento 2: היכן נשברת ההגנה של החנות

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

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

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

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

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

תוצאת הביקורת: אילו וקטורי תקיפה נסגרים

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

הרשאות מנהל החנות

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

הגנה מפני ניחוש סיסמאות

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

הגנה על נתוני הלקוחות

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

פרצות שנסגרו בקוד ובתוספים

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

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

פורמטים של בדיקה: חד-פעמית, שגרתית, לפני עלייה לאוויר

ביקורת אבטחה של Magento 2 פותרת משימות שונות, ולכן בוחרים את הפורמט לפי המטרה, ולא מתוך הרגל «פעם בשנה סרקנו». בדיקה חד-פעמית מציגה את המצב לתאריך מסוים: נקודות כניסה פתוחות, תלויות מיושנות, הרשאות גישה חלשות. מה שיופיע אחרי המהדורה הבאה — היא כבר לא תתפוס.

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

השוואת פורמטי העבודה

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

סדר העבודה: מהמיפוי ועד מסירת הדוח

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

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

2. תוכנית הבדיקה והגבולות. מתאמים את המתווה: עותק בדיקה, נתונים, חלון עבודה, מה נוגעים בו ומה לא. בלי זה הבדיקה הידנית נתקלת במגבלות עומס וגישות.

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

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

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

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

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

מה נשאר אצלכם: תצורות, תוכניות, נהלים

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

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

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

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

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

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

מה גילתה הבדיקה

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

סדר הסגירה והתוצאה

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

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

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

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

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

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

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

ניתוח תצורה וקוד מסביר את הסיבה.

בודקים לא «האם הצליח», אלא «למה הצליח»: הרשאות לקבצים ולתיקיות, מצב הפעולה של פאנל הניהול, הגדרות סשנים ו-cookie, הצפנת נתונים שירותיים, מגבלות על קצב בקשות, מדיניות אבטחת תוכן, וגם מודולים ותבניות לא סטנדרטיים — לרוב המקומות הלא סגורים חיים בדיוק שם.

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

האם הבדיקה בטוחה באתר פעיל?

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

מה לעשות עם ממצאים שידועים כבר מזמן?

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

מי מבצע את התיקונים — אנחנו או הצוות שלכם?

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

באיזו תדירות לחזור על הבדיקה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

מה כדאי להכין לשיחה:

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

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