2026-07-02
תהליך אפיון פלטפורמה ואבחון מערכת האבטחה
סופק ע״י king.Hippopotamus - Nir Elmaliah
עבור baby-land - mom2be
עבודתנו החלה בבחינת המערכת ובאיתור שורש התקלות שעליהן דיווח הלקוח איטיות, קפיאות ופעולות שאינן מושלמות. במהלך הבחינה עלו ממצאים שזיהינו כדגלים אדומים כאלה שאינם נוגעים רק לחוויית השימוש היומיומית, אלא גם לסיכון אבטחת מידע. חובתנו הטכנולוגית היא, בראש ובראשונה, לאתר קוד זדוני, לזהות זליגת מידע ולבחון את ארכיטקטורת האבטחה. בדוח שלפניכם תוכלו להיחשף בעצמכם למלוא התמונה של המתרחש במערכת mom2be.
- קריטי31
- גבוה30
- בינוני28
- נמוך5
- מערכת
- mom2be.baby-land.co.il
- פלטפורמה
- WordPress 7.0 · WooCommerce 10.4.4
- תאריך בדיקה
- 2026-07-02
- עורך הדוח
- Hippo.Research
חשיפה חיה
האבחון העלה חשיפה חיה שיש לטפל בה לפני עלייה לייצור: קבצים רגישים נגישים ברשת הפתוחה ללא התחברות, ותצלום מקור חושף מחדש את רשימת הלקוחות.
סיכום מנהלים
דוח ביקורת אבטחה והערכת סיכוני תפעול אבחון ביניים
- אל
- הנהלת mom2be
- מאת
- Hippo.Research
- תאריך
- 2026-07-02
- סיווג
- אבחון ביניים
מבנה הדוח
דוח זה מציג את תוצאות אבחון האבטחה שבוצע למערכת mom2be. מטרת האבחון היא להציף פערים קריטיים בשכבות ההגנה, בתקינות התפעולית ובציות הרגולטורי, אשר עשויים להוות חסם להמשך הפיתוח והשקת הפלטפורמה.
תקציר הממצאים
במהלך הבדיקה אובחנו ליקויים מהותיים הדורשים התייחסות מיידית:
- 01חשיפת מידע: קיימת נגישות ציבורית בלתי מורשית למידע רגיש ולקובצי מערכת, המעלה סיכון ישיר לזליגת נתונים.
- 02כשלים בבקרת הרשאות: זוהו פרצות המאפשרות עקיפת אימות, מה שמעמיד את המערכת תחת סיכון להשתלטות חיצונית.
- 03שלמות עסקאות ותשלומים: מנגנוני הסליקה הקיימים אינם עומדים בתקני האבטחה הנדרשים (PCI-DSS), וקיימת חשיפה למניפולציות בנתוני תשלום.
- 04חוסר עמידה ברגולציה: אופן ניהול המידע הרפואי והאישי אינו מספק מענה לדרישות חוק הגנת הפרטיות הישראלי, בדגש על חובות אבטחה ופרטיות.
הערכת מצב ואחריות
הממצאים מצביעים על חוסר בארכיטקטורת "אבטחה בתכנון" (Security by Design). ללא תיקון הפערים המפורטים בדוח זה, המערכת חשופה לסיכונים תפעוליים, משפטיים ומוניטיניים משמעותיים. הדוח מהווה כלי עבודה אבחנתי בלבד; יישום ההמלצות הוא צעד הכרחי להבטחת עמידות המערכת בסביבת הייצור.
אנו ממליצים על הקפאת פריסה או שינויים נרחבים עד להשלמת סבב התיקונים המוגדר בדוח זה, ובפרט סגירת נקודות התורפה המאפשרות חשיפת מידע וגישה לא מורשית.
חשיפת מידע לציבור
במהלך הבדיקה נמצא כי חלקים מהמערכת הציבורית פתוחים לגישה אנונימית ללא בקרת הרשאות. קבצים ומידע, אשר אמורים להיות חסויים או מוגנים, נגישים לכל דורש ברשת הפתוחה. בדקנו מה זר יכול לשלוף, והורדנו הוכחה לכל פריט.
למה בדקנו זאת
באינטרנט הפתוח אין דבר כזה "פנימי אך נגיש". אם בקשה אנונימית מקבלת תשובה תקינה ואת הקובץ הקובץ חשוף. הכוונה אינה קובעת, הנגישות קובעת.
מה בדקנו
ביצענו סריקה ממוקדת של גישה אנונימית לקבצים רגישים. עבור כל קובץ גיבויים, יומנים, סודות, רשימות לקוחות שלחנו בקשה אנונימית אחת ותיעדנו רק את סטטוס התשובה ואת גודל הקובץ, על בסיס סטטוס תגובת השרת. מעולם לא פתחנו ולא שמרנו את התוכן.
מה מצאנו
קובץ גיבוי מתוארך יחיד הוא, למעשה, כל האתר קוד, תצורה ונתונים הנמסר בקליק אחד. ארכיון שני חושף מחדש את נתוני הישיבה של הלקוחות.
200 · 273 MB + www.zip 200 · 552 KBD08גיבוי תצורה יורד כטקסט גלוי וחושף את סיסמת מסד הנתונים ואת שמונת המפתחות המגִנים על ההתחברות. מפתחות אלה מאפשרים לתוקף לזייף התחברות תקפה לכל חשבון לרבות מנהל בלי לדעת סיסמה כלל.
קובץ קטן מכיל שם משתמש וסיסמה של מנהל בטקסט גלוי, ויורד משתי כתובות נפרדות באתר.
app/config/dump 200 · 41 b ×2D09יומן פעילות בן תשעה חודשים וכמה קובצי ייצוא לקוחות יורדים בחופשיות. אימתנו שהמידע אמיתי ואינו נתוני בדיקה: קובץ אחד לבדו מכיל מאות מספרי נייד ישראליים אמיתיים ומאות רבות של שדות פרטים אישיים נספרו, לא הוצגו.
מפת אתר הפונה למנועי חיפוש מדליפה קטעים מכתובות הדוא"ל של לקוחות בתוך כתובות הכרטיסים ניתנים לאיסוף אוטומטי בשקט, וגם מאשרים שאדם השתתף בתערוכת הריון.
מה זה אומר עכשיו
זהו הממצא החמור ביותר, והוא פעיל היום. כל אחד יכול להחזיק עותק מלא של האתר ושל נתוני הלקוחות. עם המפתחות שדלפו, השתלטות מנהלתית מלאה אינה דורשת סיסמה. ייתכן שכבר קיימים עותקים מחוץ לידיעתנו.
מה יקרה בהמשך
מידע שדלף אינו פג. מספרי טלפון וזהויות מזינים הונאה ממוקדת במשך שנים, ומסד נתונים גנוב הופך לקלף סחיטה; ומעבר לכך, כל אירוע דליפה פוגע במוניטין הארגוני ובאמון הלקוחות. מכיוון שמדובר במידע הקשור להריון, החשיפה היא אירוע בר־דיווח לפי דין הפרטיות בישראל מרגע שעולה חשד.
זו אינה האיטיות שתיארתם אך היא צומחת מאותה הזנחה. אותן ידיים שהותירו תהליכים כבדים רצים בכל עמוד הותירו את מגירות הארון פתוחות. חוסר היציבות היה הסימפטום הגלוי; זו הסכנה שמתחתיו.
המלצה אופרטיבית
- 1
חסימת גישה. הגדרה מיידית של מדיניות הגישה בשרת כך שקבצים רגישים ותיקיות תיוק יהיו חסומים לגישה ציבורית.
- 2
החלפת הסודות שנחשפו. מאחר שגיבוי תצורה חשף את סיסמת מסד הנתונים ואת המפתחות המגִנים על ההתחברות, יש להחליף את כולם בבת אחת עד שיוחלפו, ניתן לזייף התחברות תקפה לכל חשבון, לרבות מנהל.
- 3
הטמעת בקרת הרשאות. הבטחה שכל אובייקט הנגיש דרך המערכת יעבור תהליך אימות זהות לפני מתן הרשאת קריאה.
- 4
סריקת שאריות. ביצוע ניקוי יסודי של המערכת מקבצי גיבוי או קבצים זמניים שאינם אמורים להיות חשופים בסביבת הייצור.
כשל בניהול הרשאות ושליטה במערכת
זיהינו ארכיטקטורה המנתבת את כל פקודות המערכת דרך נקודת כניסה מאוחדת אחת, המוגדרת ללא מנגנון אימות או הרשאה. בפועל, כל פקודה הנשלחת לנקודת קצה זו מבוצעת על ידי השרת ללא וידוא זהות השולח או הרשאותיו.
למה בדקנו זאת
כאשר נקודת כניסה משותפת אחת מריצה כל פעולה בלי לבדוק זהות, חולשה אחת מוכפלת על פני כל המערכת. זהו כשל של בקרת הרשאות שבורה הסיכון המדורג ראשון ברשימת OWASP Top 10 ליישומי רשת.
מה בדקנו
בחנו את התנהגות השרת באמצעות בקשה המנותקת לחלוטין מהממשק הגרפי ללא אסימון התחברות וללא כותרת הרשאה והרצנו פקודת קריאה בלבד. היא בוצעה בהצלחה, דבר המוכיח כי המערכת פועלת במודל של "אמון עיוור" כלפי הקלט הנכנס, ללא כל יכולת לבקר את הפעולות המתבצעות.
מה מצאנו
מנתב יחיד מריץ את כל האפליקציה עבור מבקרים אנונימיים ללא התחברות, ללא בדיקת הרשאה וללא אסימון הגנה מפני זיוף. אימתנו זאת בשידור חי בקריאה בלתי מזיקה.
דרך אותה דלת, וכפי שאומת בקוד המקור, בקשה אנונימית יכולה לחסום או לשחרר כל מושב ששולם, לשבץ מחדש או לייצר מחדש מושבים, ולמחוק הזמנה באמצעות מזהה עגלה שניתן לנחש.
אותו נתיב אנונימי יכול לייצר מחדש או לדרוס כל כרטיס, לסמן כרטיסים כ"נוצלו" בכניסה, ולהפעיל גל בלתי מוגבל של הודעות דוא"ל הנושאות נתוני כרטיס אל כתובת שהתוקף בוחר.
בקשת כתובת רשת פשוטה, שאינה דורשת התחברות, מוחקת את משימת הרקע המסנכרנת ומנקה את שריון המושבים.
GET ?luc1_reset_cronD52
מה זה אומר עכשיו
כל מושב, הזמנה וכרטיס במערכת ניתנים למניפולציה כרגע בידי מי שאין לו חשבון כלל ללא גישה מוקדמת וללא פריצה מורכבת; די בבקשת רשת ישירה אחת. זוהי דליפה של יכולת ניהולית לידיים לא־מורשות. הנגישות הוכחה; רק סירובנו לפגוע בלקוחות אמיתיים משאיר את ההדגמות ההרסניות על עותק בדיקה.
מה יקרה בהמשך
ברגע האחד שחשוב מכירה עמוסה סקריפט יחיד יכול לשחרר, להזמין מחדש או למחוק מושבים מהר מכפי שהצוות מגיב, לזייף כרטיסים בכמות, או לעצור בשקט את מנוע השריון ולהוביל את האירוע לכאוס בכניסה.
כן סביר מאוד שזה חלק ממה שראיתם. מושבים המתנהגים באופן מוזר, שריונים שנעלמים, ומשימת סנכרון שניתן לכבות באופן אנונימי כולם מייצרים בדיוק את "המושבים המשתגעים" ואת חוסר היציבות שתיארתם. אין צורך אפילו בתוקף מכוון: זחלני רשת רגילים הפוגעים בפקודות הפתוחות הללו עלולים להפעיל אותן.
המלצה אופרטיבית
- 1
אימות חובה לכל בקשה. הטמעת שכבת אימות חובה לכל בקשה המגיעה לשרת, ללא קשר לטיב הפקודה עקרון אפס־האמון (Zero Trust), שבו דבר אינו נחשב מהימן כברירת מחדל.
- 2
ניהול מצב וזהות. מעבר לניהול מצב בצד השרת המבוסס על אסימון חתום (JWT) או session מנוהל, כך שכל בקשה מאומתת מול זהות ידועה לפני שהיא פועלת.
- 3
בידוד וקשיחת ממשקי הניהול. סגמנטציה של ממשקי הניהול והעברתם למרחב מוגן שאינו חשוף באינטרנט הציבורי, תוך שמירה עליו באמצעות רשימות בקרת גישה (ACL) נוקשות.
אבטחת טרנזקציות ושלמות התשלום
ניתוח תשתית התשלומים העלה כשלים בארכיטקטורת עיבוד הנתונים. המערכת פועלת בתצורה המאפשרת זליגה של נתוני כרטיס רגישים מספר הכרטיס וקוד האבטחה לתוך רשומות המערכת, וקיימת בה תלות מסוכנת בנתונים המגיעים מצד הלקוח ללא אימות תקיף בצד השרת.
למה בדקנו זאת
טיפול בכרטיסים כפוף לכללי תעשייה מחייבים (PCI-DSS), וכל סכום המסתמך על דפדפן הלקוח הוא דליפת הכנסה ישירה וחוזרת. שניהם נושאים חשיפה משפטית וכספית החורגת מרחק מבאג רגיל.
מה בדקנו
עקבנו אחר זרימת המידע מהקופה ועד לשכבת מסד הנתונים, וזיהינו נקודות שבהן הנתונים הופכים לטקסט גלוי בתוך יומנים או רשומות הזמנה. בנוסף, ביצענו מבחן עקיפה: שלחנו מחיר עסקה השונה מזה שהוגדר במערכת, והשרת עיבד אותה ללא כל התרעה עדות לכך שהשרת אינו בודק את מקור האמת של העסקה.
מה מצאנו
החיבור הנושא את מספר הכרטיס ואת קוד האבטחה אל הספק אינו מאמת את זהות הספק, ואין לו מגבלת זמן דבר המותיר אותו פתוח ליירוט ולתקיעת תהליכים במהלך התשלום.
כל הזמנה שומרת את מספר הכרטיס הגולמי ואת קוד האבטחה, את תשובת הספק המלאה, ופרטים אישיים עודפים לרבות מספר זהות מידע שאסור לו כלל לנוח על השרתים שלכם.
מחיר המושב נלקח ממה שהדפדפן שולח, כך שבקשה מתוקנת יכולה לרכוש כרטיסים בחינם או הרבה מתחת למחיר. חריג מקודד־קשיח מעניק הזמנה חינמית עבור מזהה כרטיס מסוים אחד.
מכיוון שההזמנה, הכרטיסים ורשומת המושב אינם נשמרים כצעד אחד של הכול־או־כלום, כשל באמצע עלול לחייב לקוח ולהותירו ללא כרטיס.
מה זה אומר עכשיו
נתוני כרטיסים מטופלים באופן שגוי בהזמנות חיות היום, וניתן לשלם בחסר בקופה. הדבר מפר את כללי תעשיית התשלומים ומרחיב את הנזק של כל חשיפת מסד נתונים אשר, כפי שמראה החלק הראשון, כבר ממשית.
מה יקרה בהמשך
נתוני כרטיס שמורים הופכים דליפה עתידית לאירוע הונאת אשראי עם אחריות ישירה, קנסות PCI וביטולי חיוב ותחת תיקון 13 לחוק הגנת הפרטיות, דליפה מסוג זה מטילה על בעלי הפלטפורמה אחריות פלילית ונזיקית כבדה. תמחור בלתי־מהימן, משהתגלה, ניתן לשחזור כרצון ומנקז בשקט הכנסות מכל מכירה עמוסה.
בחלקו. פחות מדובר בקפיאות ויותר בכסף ובדין אך לקוח שחויב ונותר ללא כרטיס, או סכומים שאינם מסתדרים בסוף מכירה, הם בדיוק הדברים שסוחר מבחין בהם וזוכר כ"המערכת אינה אמינה".
המלצה אופרטיבית
- 1
יציאה מהיקף התקן. הטמעת פתרון המבוסס על Hosted Fields או iframe של ספק הסליקה כך שנתוני הכרטיס עוברים ישירות מהלקוח לספק הסליקה, ושרת האתר מקבל אך ורק אסימון (Token) אנונימי.
- 2
מנוע אימות בצד השרת. העברת כל חישובי העלויות, המיסים וההנחות למנוע הרץ בצד השרת. כל בקשת תשלום חייבת להיחתם על ידי המערכת על בסיס המחירים השמורים במסד הנתונים בלבד, תוך התעלמות מכל פרמטר מחיר המגיע מהדפדפן.
- 3
מחיקה בטוחה וניקוי נתונים. ביצוע מיידי של מחיקה בטוחה (Secure Purge) לכל הרשומות שבהן נשמר מידע כרטיסי אשראי, והגדרת מדיניות המונעת כתיבה של נתונים אלה לכל יומן מערכתי.
- 4
לוג ביקורת בלבד. הקמת מערכת יומנים פנימית המתעדת אך ורק את סטטוס העסקה הצלחה או כישלון ללא כל פרט מזהה של הכרטיס, למטרות ביקורת בלבד.
כשלים בבקרת קלט והזרקות קוד
זיהינו פגיעוּת רוחבית הנובעת מטיפול לקוי בנתוני קלט של משתמשי הקצה. המערכת סובלת מסינון קלט לא מספק בשלבים קריטיים של צינור עיבוד הנתונים, מה שמאפשר הזרקת פקודות אל מסד הנתונים, הרצתן בדפדפני מנהלים, או שיבוש ייצוא נתונים.
למה בדקנו זאת
פגמים אלה מאפשרים לתוקף לקרוא או לשנות את מסד הנתונים ישירות, או להריץ פקודות בתוך הדפדפן של מנהל מחובר נתיב שכיח מאחיזה קטנה ועד השתלטות מלאה על החשבון.
מה בדקנו
ביצענו סדרת בדיקות אגרסיביות שבהן הזנו מטען ייחודי לכל שדה קלט (ספריות תווים מיוחדים, סימני סקריפט וסימני שאילתה). לאחר מכן עקבנו אחר מסלול הנתונים מהבקשה הנכנסת, דרך שכבת היישום, ועד לאחסון הפיזי וחזרה אל הממשק הממצאים מוכיחים כי בשום שלב לא בוצע עיקור של הערכים. בבחינת הרינדור מצאנו כי המערכת מציגה תוכן משתמש ללא ניקוי נאות, דבר המאפשר הרצת קוד צד־לקוח בתוך אזורים רגישים במערכת.
מה מצאנו
פעולת יציאת־מושב אחת בונה שאילתת מסד נתונים על ידי הדבקת קלט המשתמש ישירות, ופותחת את מסד הנתונים להזרקה.
Seater.php:212D47שמו של הרוכש, ללא בריחה, מוצג בתוך לוחות הבקרה של הצוות ומעובד אל תוך תמונת הכרטיס כך ששם מעוצב יכול להריץ קוד בדפדפן של מנהל או בתוך הכרטיס עצמו.
גיליונות מיוצאים אינם מנטרלים תווי נוסחה מובילים, כך שייצוא שנפתח יכול להריץ נוסחה על מחשב הבודק.
האסימון המגן על שער הכניסה מעורבל בשיטה קבועה וחסרת מפתח שניתן להפוך, כלומר ניתן לזייף אישורי כניסה.
מה זה אומר עכשיו
אלה רדומים היום אך דרוכים לפעולה: הרשמה זדונית אחת או בקשה מעוצבת אחת מספיקות כדי להגיע אל מסד הנתונים או לחטוף הפעלת צוות. חמור מכך, ניתן "להרעיל" נתונים זדוניים אל תוך מסד הנתונים, ואלה ירוצו בהרשאות גבוהות ברגע שיוצגו בלוח הבקרה הניהולי.
מה יקרה בהמשך
אם יישארו במקומם, כל אחד מהם הופך לנקודת המעבר מ"מבקר" ל"מנהל" הצעד ההופך את החשיפות מהחלקים הקודמים מגניבת מידע לשליטה מלאה ומעשית.
אינו הגורם לאיטיות, אך חלק מאותה תמונה: קלט זכה לאמון בכל מקום שבו היה צריך להיחקר. חלק מהייצואים השבורים עשויים גם להיראות מבחוץ כ"לוח הבקרה ריק או מתנהג לא כשורה".
המלצה אופרטיבית
- 1
תקני קידוד מגננתי. הטמעת ספריות עיקור מוכחות (כגון OWASP ESAPI) בכל נקודה שבה המערכת מקבלת קלט.
- 2
קידוד פלט מותאם־הקשר. מעבר לקידוד פלט מותאם־הקשר: אין להסתפק בקידוד גנרי יש להתאים את העיקור ליעד, בין אם HTML, JavaScript, SQL או כתובת URL.
- 3
קשיחת שכבת הגישה לנתונים. אכיפת שימוש ב-Prepared Statements ב-100% מהשאילתות, ואיסור מוחלט על שרשור מחרוזות בבניית שאילתות SQL.
- 4
בדיקות אבטחה אוטומטיות. שילוב כלי סריקה אוטומטיים (SAST/DAST) בצינור הפיתוח, כדי לזהות הזרקות עוד לפני שהשינויים מגיעים לסביבת הייצור.
- 5
כותרות אבטחה ו-CSP. הגדרה קשיחה של כותרות אבטחה בפרוטוקול (כגון Content-Security-Policy), כדי למנוע מראש הרצת סקריפטים ממקורות לא מאומתים, לרבות סקריפטים מוטמעים.
ניהול תלויות וצמצום שטח תקיפה
זיהינו פערים משמעותיים בניהול מחזור החיים של רכיבי התוכנה. הארכיטקטורה הנוכחית מתבססת על תשתית ורכיבי צד־שלישי המצויים בגרסאות מיושנות, לצד חשיפה בלתי־מבוקרת של סביבת הפיתוח והדיבאג לאינטרנט הציבורי. מצב זה יוצר חשיפה מתמדת לניצול פרצות (CVE) שפורסמו זה מכבר בקהילה הטכנולוגית.
למה בדקנו זאת
פרצות ידועות ומפורסמות הן הדרך הקלה ביותר פנימה: קוד הניצול כבר קיים בפומבי, וכלים אוטומטיים סורקים את כל האינטרנט בדיוק אחר גרסאות מיושנות אלה.
מה בדקנו
השווינו את טביעת האצבע הדיגיטלית של כל רכיב מותקן מול מאגר הפרצות הלאומי (NVD), וזיהינו גרסאות הנושאות פגמים ברמת חומרה "קריטית" ו"גבוהה" ובהן כאלה המאפשרות הרצת קוד מרחוק (RCE). כן מיפינו את חשיפת נקודות הקצה, וסרקנו לגילוי קבצים ותיקיות בעלי אופי ניהולי ודיאגנוסטי שהושארו בשורש האתר; הנגישות אליהם מאפשרת לתוקף לבנות מודל איום מלא על המערכת ללא כל אימות.
מה מצאנו
כמה תוספים נמצאים מתחת לגרסאות שתוקנו לאבטחה ובהם אחד עם פגם ידוע המאפשר למשתמש בלא הרשאות להשיג גישה מוגברת, ושניים נוספים עם פרצות מפורסמות להרצת קוד מרחוק. אימתנו את הגרסאות הפועלות בשידור חי.
כלי אבחון למפתחים הושאר פועל בסביבת הייצור, שם הוא עלול להדליף פרטים פנימיים ולאפשר סקריפטים חוצי־אתר.
האתר תלוי באופן קשיח בתוסף נטוש בסוף חייו שלא יקבל תיקוני אבטחה, ונושא כלֵי גיבוי/הגירה עודפים שרק מרחיבים את משטח התקיפה.
מה זה אומר עכשיו
כל רכיב מיושן הוא דרך כניסה מן־המוכן שאינה דורשת תחכום רק סריקה אוטומטית המוצאת את מחרוזת הגרסה שכבר מצאנו; אחדים מאלה מנוצלים באופן פעיל במקומות אחרים ברשת. וכל כלי ניהול או דיבאג שנותר חשוף מעניק לתוקף את המודיעין ההופך סריקה אקראית לתקיפה מדויקת וממוקדת.
מה יקרה בהמשך
הפער רק מתרחב: כל שבוע ללא עדכון מוסיף פרצות שפורסמו לאחרונה, והתלות בסוף־חיים משמעה שחלק אחד מהמערכת לעולם לא יוכל להתעדכן בבטחה בלי להחליפו.
מערך תוספים כבד ונטוש־בחלקו גם מכביד על הביצועים והיציבות כך שהוא רקע תורם לשבריריות שחשתם, מעבר להיותו פרצת אבטחה.
המלצה אופרטיבית
- 1
מפת רכיבים (SBOM). יצירת מפת רכיבים מלאה של כלל התוספים והספריות, ותעדוף כל רכיב על בסיס רמת הסיכון שלו ותדירות העדכונים של היצרן.
- 2
סריקת תלויות אוטומטית (SCA). הטמעת כלים הבוחנים את הקוד מול מאגרי פרצות בזמן אמת, עם מדיניות חסימה/היתר לכל רכיב בהתאם לסטטוס האבטחה שלו.
- 3
הקשחת תשתית. הסרה פיזית של כל כלי פיתוח, יומן וקובץ תצורה מסביבת הייצור, והגבלת הגישה לתיקיות רגישות באמצעות הגדרות שרת.
- 4
מינימליזם תוכנתי. החלת מדיניות מחמירה של מינימליזם תוכנתי כל רכיב שאינו קריטי לליבת הפעילות העסקית יוסר באופן מיידי, לצמצום שטח התקיפה.
- 5
פרוטוקול עדכון יזום. הקמת פרוטוקול חירום לעדכון פרצות (מדיניות תגובה ל-Zero-day), המבטיח הטמעת תיקוני אבטחה קריטיים תוך 24–48 שעות מפרסומם.
יציבות תפעולית, עומסים ומצבי מרוץ
ניתוח ארכיטקטוני העלה חולשות מהותיות בניהול מצבי מרוץ ובטיפול בתהליכים מקביליים. המערכת אינה מנהלת כראוי "שריון משאבים", מה שמאפשר מצבים שבהם משאב בודד מושב נמכר ליותר מלקוח אחד בו־זמנית, לצד ביצועים ירודים תחת עומסי תעבורה.
למה בדקנו זאת
שריון משאב משותף מושב תחת רוכשים רבים בו־זמנית הוא בעיה קשה קלאסית. כשהדבר נעשה ללא אמצעי ההגנה הנכונים במסד הנתונים, הוא עושה בדיוק שני דברים: מוכר את אותו מושב פעמיים, ומאט את כל האתר.
מה בדקנו
ביצענו סימולציה של דרישה בו־זמנית על משאב מוגבל מושב בתערוכה. המערכת כשלה בהטלת נעילה על רשומת הנתונים, ואפשרה למספר עסקאות "להצליח" על אותו אובייקט. לאחר מכן ניתחנו את מחזור חיי הבקשה בשרת וזיהינו פעולות חוזרות ונשנות המתבצעות בכל צפייה בעמוד מושב עדות להיעדר מנגנון מטמון חכם או לשימוש לא יעיל בשאילתות מסד הנתונים.
מה מצאנו
מושבים משוריינים בקריאה־ואז־כתיבה שאין בה נעילה ברמת מסד הנתונים ואין בה כלל האוסר כפילויות, כך ששני רוכשים המגיעים יחד יכולים שניהם לקנות את אותו מושב.
משימות ניקוי וסנכרון כבדות סריקות מלאות של טבלת הישיבה עם כתיבות לדיסק רצות באופן סינכרוני בכל ביקור, ומשימה נלווית מתוזמנת לרוץ בכל שנייה, ונערמת על עצמה.
האתר אינו ניתן למטמון וקושר כל מבקר לשרת אחד באמצעות הפעלה גולמית, כך שאינו יכול לפזר עומס בין מכונות והוא מריץ שאילתות "הבא הכול" ללא גבול, המואטות ככל שהמידע גדל.
ניקוי רקע משתמש ב"עצור" במקום ב"דלג", כך שרשומה תקועה אחת עוצרת את שחרור השריונים שפגו ומכווצת בהדרגה את המושבים הזמינים למכירה.
מה זה אומר עכשיו
האתר איטי ועלול להיתקע תחת עומס היום, ותחת רוכשים בו־זמנית הוא יכול באמת למכור מושב אחד לשני לקוחות משלמים סכסוך בלתי־פתיר בכניסה. מספר המושבים הזמינים גם יורד מעצמו כאשר שריונים שפגו אינם משתחררים.
מה יקרה בהמשך
הארכיטקטורה קורסת בעוצמה הרבה ביותר ברגע שבו היא חייבת להחזיק מעמד: מכירת בזק או תערוכה מבוקשת. ככל שהתנועה עולה, הקפיאה הופכת להשבתה מוחלטת וכפל־ההזמנות מתרבה התרחיש הסביר ביותר לעלות לכם אירוע. ואתר שאינו מגיב הוא אתר שנוטשים, כך שחוסר היציבות פוגע ישירות בשיעורי ההמרה ובהכנסות סיכון עסקי שווה־ערך לסיכון הטכני.
כן במישרין, וזהו לב העניין. הקפיאה, האיטיות והמושבים הכפולים שתיארתם אינם מזל רע מעורפל ואינם אשמת וורדפרס. הם מתחקים אל הפגמים המסוימים והשמיים הללו וכל אחד מהם ניתן לתיקון מבלי לעזוב את וורדפרס.
המלצה אופרטיבית
- 1
טרנזקציות אטומיות ונעילה. הטמעת מנגנוני נעילה ברמת מסד הנתונים (Pessimistic או Optimistic), המבטיחים שרכישת מושב היא פעולה אטומית שאינה ניתנת לשיבוש או לשכפול.
- 2
תיעול לתור. העברת תהליכי התשלום והשריון למנגנון מבוסס תור (Message Queue), המאפשר לשרת לעבד עסקאות בקצב קבוע מבלי לקרוס תחת פיקים של עומס.
- 3
אסטרטגיית מטמון מתקדמת. יישום שכבות מטמון (כגון Redis) לנתונים סטטיים של המושבים, כדי להפחית באופן דרסטי את העומס על מסד הנתונים בפעולות קריאה.
- 4
אופטימיזציית מסד הנתונים. אופטימיזציה לשאילתות הכבדות המנהלות את זמינות המושבים, על ידי בניית אינדקסים חכמים והפחתת פעולות Join מיותרות.
- 5
בדיקות עומס. ביצוע בדיקות עומס מבוקרות (כלי CI/CD) המדמות רכישות במקביל, כדי לוודא שהשיפורים בארכיטקטורה אכן עומדים בעומס היעד המתוכנן.
פרטיות, רגולציה וניהול מידע רפואי
המערכת מנהלת מידע אישי ורגיש (כגון מועדי לידה משוערים, מצב רפואי ונתוני זיהוי) ללא בקרות הפרטיות הנדרשות על פי דין. נמצא כי חסרים מנגנונים בסיסיים למימוש זכויות הפרט, הגבלת החזקת המידע, והבטחת אי־זליגתו כברירת מחדל.
למה בדקנו זאת
פלטפורמה זו מחזיקה מצב היריון, מועדי לידה ומספרי זהות. לפי חוק הגנת הפרטיות (תיקון 13) זהו מידע *רגיש במיוחד*, הנושא חובות שהן משפטיות ואינן רשות ובכללן חובת דיווח המתחילה עם החשד לאירוע, לא ימים לאחר מכן.
מה בדקנו
בחנו את עקרון הפרטיות בתכנון ומצאנו כי אין הפרדה בין המידע המנהלי למידע הרפואי הרגיש, ואין הצפנה של נתונים אלו במסד הנתונים (Encryption at Rest). סקרנו את מחזור חיי המידע ואת "הזכות להישכח", ומצאנו כי אין מנגנון המאפשר מחיקה גורפת ומוחלטת של משתמש ומידע רפואי משויך מרשומות המערכת, מהגיבויים ומהיומנים. כן בדקנו את אבטחת התקשורת בדואר היוצא ומצאנו ליקויים באימות השולח (SPF/DKIM/DMARC), המאפשרים התחזות.
מה מצאנו
אין מנגנון למחיקת או ייצוא מידע של אדם לפי בקשה, אין מגבלת שמירה, ורשומות לרבות רשומות לידים וכרטיסים נשמרות רשומות בפומבי ומאורכבות במקום פרטיות.
הודעות הכרטיסים נשלחות ללא רשומות אימות־שולח סטנדרטיות, כך שכרטיסים לגיטימיים סבירים להגיע לתיבת הזבל והכתובת קלה להתחזות.
אוטומציה של צד שלישי מקבלת נתוני לקוח ללא אימות השולח וללא מגבלת זמן, ומעבירה מידע אישי כחלק מזמן ההמתנה של הרוכש בקופה.
אין נעילת ניסיונות פריצה או חומת־אש יישומית, ואין קובץ הקשחה ברמת השרת הפלטפורמה נשענת על כך שדף ההתחברות פשוט מוסתר במקום על הגנות אמיתיות.
מה זה אומר עכשיו
העסק אינו מתיישר עם הדין המסדיר בדיוק סוג מידע זה, כרגע ואינו יכול כרגע להיענות לבקשה בסיסית של לקוח "מחקו את המידע שלי" או להוכיח מה הוא מחזיק ולכמה זמן, דבר החושף אותו לסנקציות משמעותיות מרשות הגנת הפרטיות.
מה יקרה בהמשך
בשילוב עם החשיפה החיה בחלק הראשון, הדבר הופך תקלה טכנית לאירוע פרטיות בר־דיווח עם פיצוי סטטוטורי שבו יחידים יכולים לתבוע פיצוי ללא הוכחת נזק, והרגולטור חייב לקבל הודעה. ומכיוון שמדובר במידע רפואי של נשים בהיריון, דליפתו נושאת נזק מוניטיני בלתי־הפיך, הרבה מעבר לנזק הטכני הישיר.
בחלקו ובאופן מוחשי: "הכרטיסים שלנו מגיעים לספאם" הוא סימפטום ישיר שאולי כבר שמעתם מלקוחות. פערי הרגולציה העמוקים יותר הם חשיפה שעליכם להכיר, גם אם אינם מה שחשתם ביום־יום.
המלצה אופרטיבית
- 1
מזעור מידע. יישום מדיניות של מזעור מידע שמירת נתונים רק לפרק הזמן ההכרחי לביצוע העסקה, ומחיקה אוטומטית לאחר מכן.
- 2
מסגרת ציות רגולטורי. הטמעת מנגנוני ניהול הסכמה (Consent Management) בטופס הרישום, המבהירים ללקוח איזה מידע נאסף, למה הוא משמש, וכיצד ניתן למחוק אותו.
- 3
אנונימיזציה והצפנה. הצפנת כל שדה המכיל מידע רפואי במסד הנתונים (AES-256), ושימוש בטכניקות פסאודונימיזציה כדי להפריד בין נתוני הזיהוי של הלקוח לבין המידע הרפואי הרגיש.
- 4
הקשחת תקשורת. הגדרת פרוטוקולי אימות דואר אלקטרוני מחמירים למניעת התחזות, והפסקת שליחת מידע רגיש בפורמט גלוי ללא הצפנה.
- 5
לוג ביקורת לפרטיות. ניהול לוגים נפרד, מוצפן ובלתי ניתן לשינוי, המתעד כל גישה למידע רפואי מי ניגש, מתי, ואיזה מידע נצפה בהתאם לדרישות החוק.
מנגנונים חריגים ודלתות אחוריות
במסגרת האנליזה איתרנו רכיבי תוכנה ומנגנוני גישה המקנים הרשאות עקיפות למערכת, ללא תלות במנגנוני האימות הרגילים. מנגנונים אלה מתפקדים דה־פקטו כ"דלת אחורית", המאפשרת גישה מיוחסת למסד הנתונים או לממשק הניהול באופן החורג מסטנדרטים תפעוליים תקינים. אנו מדווחים עליהם בפשטות, ואיננו טוענים דבר לגבי הסיבה לקיומם.
למה בדקנו זאת
מנגנון יחיד כזה מבטל כל הגנה אחרת. חובתנו להציפו במישרין, לתאר מה הוא עושה, ולהותיר בצד את שאלת הכוונה שאותה איננו במעמד לשפוט.
מה בדקנו
כחלק מכל בדיקה רצינית אנו מחפשים מנגנונים המעניקים גישה מיוחסת או מזייפים אמון מהסוג המתפקד כדלת אחורית ללא תלות בכוונה שמאחוריו.
מה מצאנו
קובץ המכיל שם משתמש וסיסמה של מנהל בטקסט גלוי מוגש לכל אחד משתי כתובות רשת מפתח־אב לא־נעול לכל האתר.
app/config/dump 200 · 41 bD09הקופה מעניקה הזמנה חינמית לחלוטין בכל פעם שמשתמשים במזהה כרטיס מסוים אחד ערך קבוע הכתוב בקוד, שכל מי שמכירו יכול לנצלו כרצונו.
Checkout.php:490 (cc_id == 317330009)D37כלי בדיקה מייצר ברקודים תקפים לשער הכניסה ומדליף נתוני משתתפים, ואסימון האמון של השער מעורבל בשיטה חסרת מפתח שניתן להפוך יחד, אישורי כניסה הניתנים לזיוף אל האירוע.
סיסמת שער תשלום יושבת מקודדת־קשיח (אם כי בהערה) בקוד המקור, ופרמטר נסתר בכתובת רשת משקף חתימת־מחבר מפוענחת שני עקבות המתייחסים לסודות ולזהות בקלות ראש.
מה זה אומר עכשיו
כל אחד מאלה, בידי מי שיודע שהוא קיים, עוקף תשלום, מזייף אישור כניסה, או משתלט על האתר לחלוטין ללא צורך במיומנות ניצול. ומכיוון שמנגנונים כאלה נטולים בדרך כלל הגבלת קצב ותיעוד, הם נתיב הפריצה המועדף ואינם מותירים כמעט עקבות.
מה יקרה בהמשך
עד שכל אחד יימצא ויוסר, הם נותרים דרכים שקטות ואמינות לחזור פנימה, השורדות החלפות סיסמה ותיקונים וזו בדיוק הסיבה שיש למנותם ולסוגרם במכוון, לא רק לטייח עליהם.
זה אינו מה שחשתם כמשתמשים, ואנו מעלים זאת בזהירות. אך ביקשתם שנבדוק אם יש קוד העלול לפגוע במערכת, וההגינות מחייבת לקרוא למנגנונים אלה בשמם התפקודי תוך הימנעות מפורשת מטענה מי הניחם ומדוע.
המלצה אופרטיבית
- 1
נטרול והסרה. הסרה מיידית של כל פונקציה או מנגנון המאפשרים גישה מיוחסת ללא אימות מלא (MFA/SSO).
- 2
סקירת קוד ידנית. ביצוע סקירת קוד ידנית של כל ליבת המערכת, כדי לוודא שלא נותרו מנגנוני סיסמאות מוטמעות בקוד (Hardcoded Credentials) או הרשאות־על (God-mode) חבויים.
- 3
ניתוח שלמות פורנזי. בחינת היומנים (במידה שקיימים) לזיהוי האם מנגנונים אלה נוצלו בעבר, וביצוע ניקוי של כל החשבונות שנוצרו דרכם.
מה שכל אחד יכול להוריד עכשיו
ללא התחברות, ללא כלים. הגענו לכל אלה על גבי האינטרנט הפתוח והורדנו הוכחה מציגים רק את גודל הקובץ ואת תשובת השרת “200 תקין”, לעולם לא את התוכן.
כל אחד מ-94 נספר עד הסוף
לא בדקנו מדגם. כל אחת מ-94 הבעיות הייחודיות נושאת מסקנה אחת בדיוק הוכחה על האתר החי, הוכחה בקוד, או ממתינה לבדיקה אחת שנקבנו עבורכם. 228 הממצאים הגולמיים שמאחוריהן הצטמצמו ל-94 לאחר איחוד כפילויות אותה תקלה שסומנה בידי כמה בודקים.
| קביעה | פריטים |
|---|---|
| אומת חי | 20 |
| אומת בקוד | 60 |
| ממתין לבדיקה | 11 |
| נבדק, לא שוחזר | 2 |
| הופרך | 1 |
| סך הכול (כל פריט נושא קביעה אחת בדיוק) | 94 |
| ממצאים גולמיים שנספגו בניכוי כפילויות | 228 |
עד כמה חמורים הממצאים
כל בעיה מדורגת מ"קריטי" ועד "נמוך". לפניכם הפיזור ובאופן גלוי, כיצד 228 הממצאים הגולמיים הצטמצמו ל-94 בעיות ייחודיות לאחר איחוד כפילויות, לרבות אי-התאמה של פריט אחד שהועברה מן הביקורת המקורית ואנו מציפים אותה במקום לתקנה בשקט.
| חומרה | ממצאים גולמיים | פריטים ייחודיים |
|---|---|---|
| P0 · קריטי | 62 | 31 |
| P1 · גבוה | 80 | 30 |
| P2 · בינוני | 63 | 28 |
| P3 · נמוך | 22 | 5 |
| סך הכול | 227 | 94 |
הערת יושרה: ספירות ה-P הייחודיות של הביקורת המקורית הסתכמו ב-91 מול 92 ליקויים שקדמו ל-D93 אי-התאמה של פריט אחד שהועברה מן המקור. הספירות המוצגות כאן נספרו מחדש מתוך 94 כותרות התיקים ומסתכמות ל-94; אנו מציפים את אי-ההתאמה המקורית במקום “לתקן” אותה בשקט.
לעיין בכל ממצא בעצמכם
שום דבר כאן אינו מוסתר. סננו לפי המסקנה שלנו, מידת החומרה, מי יכול להפעיל, במה זה פוגע ולאיזה שלב תיקון זה שייך; חפשו ומיינו, ואז פתחו כל כרטיס לפירוט המלא שלו. קישור לשיתוף שומר את מה שסיננתם.
סייר הממצאים
94 מתוך 94 ממצאים
Unauthenticated full attendee-PII dump via `?luc1_override`
An unauthenticated visitor can trigger a hidden parameter that dumps every attendee's name and phone number at once.
Ticket IDOR: any buyer's name + phone by sequential ID
Anyone could page through sequential ticket IDs to read other buyers' names and phone numbers without logging in.
`wp-config-bkp.pjp` downloads as plaintext (DB password + 8 salts)
A backup of the main config file downloads in plain text, exposing the database password and secret keys.
Public 123MB `debug.log` (attendee PII + checkout internals)
A very large debug log is publicly downloadable and contains attendee personal data and checkout internals.
Public PII exports (customers/failed/integromat JSON, tels.csv)
Several exported data files holding customer contact details are downloadable by anyone, no login required.
seatgen JSON: 465+43 attendee records + 54 order/customer pairs
Seat-generation data files listing hundreds of attendee records are publicly downloadable without authentication.
~97 wpallexport CSVs (national ID / pregnancy / kids)
Around a hundred exported spreadsheets holding sensitive customer data sit in a publicly reachable folder.
Full-site backup archives downloadable (273MB + www.zip)
A full-site backup archive (about 273 MB) plus a smaller zip download freely, exposing source, data and secrets.
`app/config/dump` plaintext admin credential (if served)
A config file returns a plaintext administrator credential to anyone who requests it.
`export-attendees.php` pregnancy/EDD CSV, no auth, remote-URL require (RFI)
An export script builds a sensitive attendee spreadsheet with no login and can pull in a remote file (RFI risk).
God-router: no nonce + no capability check, nopriv-exposed (whole app surface)
A single catch-all endpoint runs for anonymous users with no security token or permission check, exposing the whole app.
`lcf_seater` engine table: no schema-in-code, missing UNIQUE(event_id,seat)/indexes
The core seat table has no schema in code and likely lacks the unique key and indexes needed to prevent double-booking.
`lcf_seater.time` written in SECONDS by ticket-sync but MILLISECONDS everywhere else
Seat timestamps are written in seconds by one path but milliseconds everywhere else, corrupting time logic.
Payment cURL TLS certificate verification disabled on PAN+CVV request
The server sends card number and security code to the payment gateway with TLS certificate checking turned off.
Payment cURL has no connect/read timeout (worker hang, double-charge risk)
The payment request has no timeout, so a slow gateway can hang server workers and risk double charges.
Raw gateway response + full `$_SERVER` + national ID persisted to order meta
Raw payment data, the full server request, and a national ID are saved into order records that should never store them.
Secrets in webroot: second `wp-config-bkp.php` + live `wp-config.php` (DB password + salts)
The web root exposes config backups and the live config file containing the database password and secret keys.
ACF Extended 0.9.2.3 < 0.9.2.6 (unauthenticated privilege escalation, exploited in the wild)
A plugin is several versions behind and vulnerable to an actively exploited unauthenticated privilege-escalation flaw.
Hardcoded payment bypass: `cc_id == 317330009` marks order paid with no charge
A hardcoded magic value lets an order be marked paid with no actual charge.
babyland-checkout binds non-existent `save_kids_count_meta_box` → fatal on order save
Saving an order calls a callback that does not exist, causing a fatal error.
Stored XSS: buyer `full_name` unescaped in event-guests wp-admin metabox
A buyer's name is shown unescaped in an admin screen, allowing stored cross-site scripting.
Price tampering: client `seatPrice` trusted verbatim → free/underpriced tickets
The checkout trusts the price sent by the browser, letting an attacker buy tickets for free or underpriced.
`ajax_tickets` force-deletes an arbitrary order via forgeable cart-cookie
A forgeable cart cookie lets an attacker force-delete any order through the open endpoint.
`ajax_seat_state` lets an anonymous user free/overwrite any (paid) seat and NULL a ticket
An anonymous user can free, overwrite, or blank out any paid seat through the open endpoint.
`ajax_reassign_seat` has no capability check, reachable by anonymous users
Seat reassignment runs with no permission check and is reachable by anonymous users.
SQL injection in `exit_ticket()`: `event_id`/`seat` interpolated unprepared into SELECT
A seat parameter is placed into a database query unsafely, allowing SQL injection.
Seat reservation race (read-check-write, no lock/unique) → double-booking
Seat reservation checks and writes without a lock, so two buyers can end up booking the same seat.
`Tickets::ajax_render` (nopriv) regenerates/overwrites any ticket
An open endpoint lets anyone regenerate and overwrite any existing ticket.
Stored XSS via buyer name/NID into ticket SVG served `image/svg+xml`
A buyer's name flows unescaped into an SVG ticket served as an image, allowing stored cross-site scripting.
`execute_seater_cleaner` `return` not `continue` → hold-expiry stops → inventory shrink
A loop uses return instead of continue, so hold-expiry cleanup stops early and seat inventory shrinks.
`seater_cleaner`/`seater_updater` run synchronously on EVERY init (full scan + disk I/O)
Heavy seat cleanup and sync jobs run synchronously on every request, scanning data and hitting disk each load.
`ajax_get_map`/`ajax_get_state` unauthenticated seat-state read
Anyone can read live seat-state data through the open endpoint without logging in.
WooCommerce 10.4.4 < 10.5.3 (CVE-2026-3589)
The store platform runs an outdated version affected by a known published security vulnerability.
WPCode 2.3.3 < 2.3.6 (CVE-2026-8832 Author+ RCE, live `eval()`)
A code-snippet plugin runs an outdated version affected by a known remote-code-execution vulnerability.
Query Monitor 3.20.2 active in production (reflected XSS + info disclosure)
A developer debugging plugin is left active in production, leaking internal info and enabling reflected cross-site scripting.
Framework bootstrap hard-depends on the abandoned/EOL `mobble` plugin
The site's framework hard-depends on an abandoned, end-of-life plugin that no longer receives fixes.
Plaintext deploy credentials in `mom2be/.env`
Plaintext deployment credentials are stored in an environment file inside the codebase.
DISABLE_WP_CRON absent, wp-cron runs on every visitor load
Scheduled tasks run on every visitor page load instead of on a real schedule, hurting performance.
`SELECT * ... GROUP BY user` violates `ONLY_FULL_GROUP_BY` (empty exports)
A database strict-mode setting can make grouped export queries fail and return empty results.
WooCommerce block-pattern cache holds stale absolute paths (open_basedir spam)
A cached list holds stale absolute file paths, spamming error logs after the site was moved.
HPOS: babyland compat undeclared + metabox/kids_count store mismatch
Order metaboxes may read from or write to the wrong storage when the modern order-storage mode is enabled.
No SMTP/DKIM/Return-Path → ticket emails to spam; `wp_mail()` return value ignored
Ticket emails lack sender-authentication setup so they land in spam, and send failures are silently ignored.
Stored XSS in admin dashboards (guests/tickets/leads) + reflected XSS in seatgen
Several admin dashboards render buyer input unescaped, allowing stored and reflected cross-site scripting.
Admin CSV export + mark-used are CSRF-able GET state-changes, no nonce
Admin export and mark-used actions run on simple links with no security token, enabling cross-site request forgery.
`ajax_remail` un-throttled mail-bomb + ticket-exfil to attacker email
An open re-email action can be abused to mail-bomb or send tickets to an attacker's address.
Gate `qr_confirm` marks used + fires Make webhook, no auth/throttle, forgeable QR
A gate confirmation marks tickets used and fires a webhook with no authentication or throttling.
Unauth GET `?luc1_reset_cron` wipes the seat-sync/cleanup cron
An unauthenticated link can wipe the site's seat-sync and cleanup scheduled task.
Coupon single-use reuse guard is dead code (email ignored)
The coupon single-use guard is dead code, so single-use coupons can be reused.
`every_second` wp-cron schedule (self-DoS / event pile-up)
A once-per-second scheduled task can pile up and overload the site.
Raw `session_start()` on init after output; legacy `session_id()` guard; sha256 ownership
A raw PHP session is started on every request with a weak guard, confirmed live by the session cookie.
No DB transaction over order+tickets+seater → charged-but-undelivered
Order, tickets, and seat updates aren't wrapped in one transaction, risking charged-but-undelivered orders.
`execute_seater_updater` non-atomic JSON write (truncated reads)
A data file is written non-atomically, so readers can catch truncated content.
Unbounded `SELECT * FROM lcf_seater` (cleaner + admin)
The code reads the entire seat table with no limit, wasting memory as the data grows.
`ImagickException` caught in wrong namespace → real failures fatal
An image exception is caught in the wrong namespace, so real failures become fatal errors.
`occupy()` re-marks ALL seats per ticket, O(n²), mislabels ownership
A ticket routine re-marks all seats each time, running slowly and mislabeling seat ownership.
`post_exists` dedup omits `order_id` → repeat order clobbers prior ticket
Duplicate-check for tickets ignores the order ID, so a repeat order can clobber an earlier ticket.
`ticket.php` `die('no seat')` inside buffered template aborts post-payment
A template aborts the whole request when a seat is missing, breaking the post-payment page.
Two divergent QR engines / non-standard `LcfQRCode` → scan drift/unreliable
Two divergent QR engines produce inconsistent codes, causing unreliable gate scans.
No WP privacy erasure/exporter hooks; lead CPT public; no retention
No privacy erasure or export hooks exist and lead records are public, with no data-retention controls.
`lcf_seater` grows unbounded (cleaner never DELETEs)
The seat table grows forever because cleanup never deletes old rows.
Public sitemap + ticket slug leaks customer email addresses
The public sitemap lists ticket URLs whose slugs leak fragments of customer email addresses.
seatgen json dir has no directory-listing deny (enumeration)
The exports folder lacked directory-listing protection, which could let visitors enumerate its files.
Simple History 5.22.0 (sensitive-data exposure) + 3 redundant activity loggers
An activity-logging plugin runs an outdated version with a known sensitive-data-exposure issue.
WP All Export (free) 1.4.14 `eval()` on admin-configured export queries
An export plugin evaluates admin-configured query code, an outdated version with a code-execution surface.
Two divergent theme copies (`www/luc1f3r` vs `wp-content/themes/luc1f3r`)
Two divergent copies of the theme are served publicly, doubling exposure and causing code drift.
`wp-config.php` hardening gaps: `WP_MEMORY_LIMIT=128M`, `UPLOADS='src/media'`, `DISALLOW_FILE_MODS=false`
Config hardening gaps: a low memory limit, an unusual uploads path, and in-dashboard file edits left enabled.
Make.com webhook: no timeout, no HMAC, forwards PII synchronously
An outbound integration webhook forwards personal data with no timeout and no message signing.
HPOS admin: metaboxes no-op / wrong-store on order screen
Order metaboxes silently do nothing or read the wrong store under the modern order-storage mode.
`luc1ph3r` keyless Feistel = QR/gate authz boundary (forgeable tokens)
The QR/gate token scheme uses a keyless, reversible cipher, so tokens can be forged.
CSV formula injection in attendee/dashboard exports
Exported spreadsheets don't neutralize leading formula characters, allowing spreadsheet formula injection.
Freebie threshold `intval($sum)<=1` skips payment for ~1–1.99₪
A rounding bug lets very small cart totals skip payment entirely.
Stored XSS: event ACF fields + seat-map JSON unescaped into front templates
Event fields and seat-map data render unescaped into front-end templates, allowing stored cross-site scripting.
`generate-test-barcode.php` mints valid gate barcodes + leaks PII (if in webroot)
A leftover test script can mint valid gate barcodes and leak personal data if it is web-reachable.
N+1 `wc_get_product()` inside per-seat loop; dashboard N+1
Product lookups repeat inside a per-seat loop, creating an N+1 query slowdown.
`log_debug()` unbounded read-append-write into autoloaded ACF option
A debug logger reads, appends, and rewrites an auto-loaded option, bloating it without bound.
BabyLand Statistics `wc_get_orders(limit=-1)` unbounded per page load
A statistics screen loads all orders with no limit on every page view.
`App`/`Gate`/`Guests __construct` deref `$post->ID` with no null guard (fatal)
A constructor reads a post ID with no null check, causing a fatal error when it is absent.
Order created 'pending' before payment, no hold-expiry → stale orders/holds
Orders sit pending before payment with no hold expiry, leaving stale orders and locked seats.
Gate/qr writes `WHERE user+event` (no id/seat) → wrong rows
A gate update matches on user and event only, so it can update the wrong rows.
OR-precedence bug in event-leads guest query (wrong seats)
An operator-precedence bug in a guest query returns the wrong seats.
Front-end JS: NaN totals, overlapping intervals, holds leak on unload
The front-end checkout script has bugs: bad totals, overlapping timers, and holds leaking on page unload.
`SetupSec::luc1h4sh()` AES hardcoded key/bad IV every init
A helper reuses a hardcoded key and a bad initialization vector for encryption on every load.
No brute-force lockout/WAF; relies on WPS-Hide-Login obscurity
There is no brute-force lockout or web application firewall; security relies only on a hidden login URL.
Cancel/refund leaves lead PII + `lcf_seater` history; cleaner keeps `last_user`
Cancelled or refunded orders leave behind personal data and seat history, a data-retention gap.
Ajax router doesn't validate class/method exist; unused allowlist
The endpoint router doesn't verify the target class or method exists and keeps an unused allowlist.
Redundant migration/backup tooling (3 plugins)
A redundant migration/backup plugin is installed alongside two others, confirmed present in production.
`ajax_seat_state` block() insert has no availability guard
A seat-block insert has no availability guard, allowing conflicting seat states.
No root `.htaccess`/`.user.ini` (no app-layer hardening/headers)
There is no root-level hardening file, so no app-layer access rules or security headers are set.
CPT Hebrew display-name as rewrite slug; lead/ticket public + archives
Public archives and a display-name-based URL slug expose lead and ticket records.
`?luc1sh1n3` reflects a decrypted author string (fingerprint)
A public parameter reflects a decoded author fingerprint string, a low-severity information leak.
Tech-debt cluster: bundled jQuery, hardcoded paths, dead code, console.logs
A cluster of maintainability issues: bundled jQuery, hardcoded paths, dead code, and leftover console logs.
Commented-out hardcoded Tranzila password in source
A commented-out hardcoded payment-gateway password remains in the source code.
HTML-only ticket email, unescaped names, no text/plain alt
Ticket emails are HTML-only with unescaped names and no plain-text alternative.
"Seater bootstrap calls undefined `xxx()`" (REFUTED)
A reported call to an undefined function was disproven; the function is actually defined. No real defect.
כיצד ניתן להגיע אל המערכת בפועל
בקשה אחת ממבקר אנונימי ללא התחברות, ללא בדיקת אבטחה נוחתת על נקודת כניסה אחת תופסת־הכול, ומשם מגיעה אל מנועי המושבים, התשלום והכרטוס ואל מסד המושבים. להלן: הנתיב החי שהבקשה עוברת, מפה של מי יכול להפעיל מה, והסדר שבו בדקנו את הכול.
aזרימת נתונים מהאינטרנט האנונימי למסד המושבים
בקשה אחת לא מאומתת מגיעה אל נתב תופס-הכול ומתפצלת אל כל מנוע ומנוע.
מרחב השמות המחודש של REST (/luc1-json/) וסשן ה־PHPSESSID הגולמי שניהם פעילים בסביבת הייצור.
bמי יכול להפעיל כל בעיה וכמה מסוכן לבדוק אותה
כל ממצא ממוקם לפי מי יכול להפעיל אותו (מבקר אנונימי, משתמש מחובר, או תהליך רקע) ולפי כמה בטוח לנו לבדוק אותו (הצצה בלתי־מזיקה מול פעולה שהייתה משנה נתונים אמיתיים). תאים גדולים וחמים יותר = יותר ממצאים וחומרה גבוהה יותר. בחרו תא כדי לפתוח את הממצאים שבו.
| וקטור לפי מחלקת בטיחות | S1 קריאה בלבד | S2 אקטיבי-בטוח | S3 הרסני | S4 קריאת שרת / מסד |
|---|---|---|---|---|
A GET לא מאומת | ||||
B POST לא מאומת | וקטור B POST לא מאומת, בטיחות S4: אין ממצאים | |||
C מאומת | וקטור C מאומת, בטיחות S1: אין ממצאים | |||
D פנימי | וקטור D פנימי, בטיחות S1: אין ממצאים | וקטור D פנימי, בטיחות S2: אין ממצאים | וקטור D פנימי, בטיחות S3: אין ממצאים |
- AGET לא מאומת כתובת URL אנונימית בדפדפן
- BPOST לא מאומת בקשה אנונימית מעוצבת (נתב-העל)
- Cמאומת דורש התחברות / סשן מנהל
- Dפנימי ללא טריגר חיצוני (רקע / שכבת נתונים)
- S1קריאה בלבד בטוח לצפייה ללא שינוי מצב
- S2אקטיבי-בטוח שולח בקשה אך אינו משנה דבר
- S3הרסני משנה נתונים אמיתיים סביבת בדיקות בלבד
- S4קריאת שרת / מסד אומת דרך קריאת שרת, מסד נתונים או קונפיגורציה
cכיצד סידרנו את הבדיקות הבטוחות ביותר תחילה
לא בדקנו באקראי. 94 הפריטים סודרו בתור לפי בטיחות: הוכחות הצצה־בלבד בלתי־מזיקות תחילה, אחר כך בדיקות שרת ומנהל, וכל דבר שעלול להפריע לנתוני לקוח אמיתיים הושאר לעותק מבודד לעולם לא על הלקוחות החיים שלכם.
בטוח להוכחה חיה ההוכחות מול הלקוח
הוכחת מחלקת ה־CSRF וההרשאות ללא שינוי נתונים
קריאת WP-CLI / SQL / קונפיגורציה אחת לכל פריט
דורש סשן מנהל לצורך הדגמה
משנה נתונים אמיתיים לשחזר על עותק
אומת בקוד; לא ניתן לצפייה חיצונית
תוכנית התיקון המדורגת T1 → T2 → T3
תוכנית מדורגת שניתן לשלוח שכבה אחר שכבה. T1 עוצר את הדימום הפעיל תוך ימים; T2 מסלק כפל-הזמנות ומרחיב את קופת התשלום; T3 בונה מחדש את תשתית הפלטפורמה, הפרטיות והניטור. כל פריט עבודה מפרט את הליקויים שהוא סוגר בחרו תגית ליקוי כדי לאתר אותו בחוקר הממצאים.
עצירת הדימום
הכלת הפריצה, החלפת כל סוד ושמונת ה־salts, נעילת נתב-העל, שחזור אבטחת התשלומים, תיקון ה־CVE-ים וריסון ה־cron.
- T1-00/06מאמץ בינוני20h
הכלה ותגובת פריצה (מחיקת ארטיפקטים, החלפת כל הסודות + 8 salts, כללי חסימה, ביקורת לוגים, ספר-הרצה ל־PPL)
סוגר 7 ליקויים - T1-01מאמץ בינוני16h
תיקון CVE בתוספים + שדרוג WooCommerce עם רגרסיה מדורגת של זרימת ההזמנות המותאמת
סוגר 6 ליקויים - T1-02מאמץ גבוה28h
הקשחת נתב-העל (nonce + רשימת-היתר לנקודות קצה + הרשאה לכל פעולה + הוצאת פעולות ניהול מ־nopriv + מגביל קצב)
סוגר 2 ליקויים - T1-03מאמץ בינוני16h
עצירת דימום PCI בשכבת הקונפיגורציה (אימות TLS + טיים-אאוטים + אידמפוטנטיות, הסרת עקיפה, הפסקת שמירת נתוני כרטיס/SAD)
סוגר 4 ליקויים - T1-04מאמץ נמוך10h
תיקון ה־Cleaner + ניטרול ה־cron (return→continue, הסרת קריאות בכל init, ביטול תזמון כל-שנייה, cron מערכת)
סוגר 3 ליקויים - T1-05מאמץ נמוך10h
חיסול IDOR לא-מאומת ודלת אחורית (שער HMAC ל־view_ticket_svg + הגבלת קצב; הסרת פרמטרי override/debug)
סוגר 4 ליקויים - T1-hwמאמץ נמוך8h
רווחים מהירים בביצועים (הגבלת זיכרון, OPcache, קאש-עמוד לדפי שיווק, N+1 בנתיב-החם)
סוגר 3 ליקויים
מקביליות וסקייל
שריון מושבים אטומי (ללא כפל-הזמנות), הסטה אסינכרונית של עבודה, קאשינג, תקינות HPOS, escaping של פלט, ומסירוּת דוא״ל.
- T2-08מאמץ בינוני24h
סכימה-בקוד + המרה ל־InnoDB + UNIQUE(event,seat) + אינדקסים + מיגרציה לנרמול יחידות-זמן
סוגר 2 ליקויים - T2-09מאמץ גבוה44h
שירות שריון-מושב אטומי (תבנית ReserveStock, ניסיון חוזר) המאחד 4 נתיבים + תיקוני SQLi ו־OR-precedence
סוגר 5 ליקויים - T2-10מאמץ גבוה28h
הסטה ל־Action Scheduler (QR/Imagick, דוא״ל, HMAC ל־webhook של Make, פקיעת-החזקה מבוססת-קבוצה) + תיקוני Imagick/כרטוס
סוגר 4 ליקויים - T2-11מאמץ בינוני16h
תקינות HPOS (הצהרת תאימות, API של order-meta, metabox חסר, רישום במסך HPOS)
סוגר 3 ליקויים - T2-12מאמץ בינוני20h
מטמון אובייקטים ב־Redis + העברת סשנים ל־Redis + שומר-סשן + הסרת mobble + no-store בנתיבים דינמיים
סוגר 3 ליקויים - T2-13מאמץ בינוני20h
escaping של פלט ב־~12 תבניות + היגיינת CSV/JSON + CPT public=>false + תיקון GROUP BY
סוגר 7 ליקויים - T2-14מאמץ בינוני18h
מסירוּת דוא״ל (SMTP/DKIM/DMARC, בדיקת-החזרה של wp_mail) + אסימוני שער HMAC + qr_confirm אידמפוטנטי
סוגר 3 ליקויים
תשתית פלטפורמה, אבטחה ופרטיות
העברת הקוד ל־mu-plugin נתמך-תחזוקה, הסרת נתוני כרטיסים מהשרתים שלכם, הקשחת התשתית, ובניית בקרות פרטיות, ניטור ובדיקות.
- T3-W1מאמץ גבוה70h
העברת הלוגיקה לתוסף must-use + PSR-4 + endroid/qr-code + מחיקת ערכת-הנושא הכפולה + open_basedir/דיפלוי
סוגר 4 ליקויים - T3-W2מאמץ גבוה40h
צמצום מלא של היקף ה־PCI (hosted-fields או הפניית Tranzila, כך שרק אסימון נוגע ב־PHP; SAQ)
סוגר 4 ליקויים - T3-W3מאמץ גבוה40h
הקשחת תשתית (חסימת nginx + כותרות + WAF + 2FA + הגנת brute-force + כיוונון FPM) ומיגרציה ל־VPS/מנוהל
סוגר 3 ליקויים - T3-W4מאמץ בינוני32h
מדיניות שמירה + WP Privacy API (מוחקים/מייצאים, משימת שמירה, מזעור) + מדיניות אבטחה + ספר-הרצה לאירוע פריצה
סוגר 3 ליקויים - T3-W5aמאמץ בינוני24h
בדיקות עומס (מסגרת k6/Locust + הרצות על נתיב החזקת-המושב הבלתי-ניתן-למטמון ונתיב התשלום בעומס שיא של 5–20×)
- T3-W5bמאמץ נמוך16h
יכולת תצפית (Sentry או שווה-ערך, מנוקה PII) + הוצאת רישום ה־debug אל מחוץ ל־webroot
סוגר 2 ליקויים - T3-W5cמאמץ נמוך12h
גיבוי + מסגרת rollback בדוקה לכל מיגרציה
- T3-W5dמאמץ נמוך12h
תיאום ציות פרטיות (סיווג שכבות-נתונים, קשר עם ה־DPO)
מה נדרש ממך כדי לסגור כל פריט פתוח
אחד־עשר ממצאים אמיתיים אך חסומים כל אחד דורש קריאה חיצונית אחת בדיוק כדי להגיע לפסק חי/staging סופי. מימין, אחת־עשרה הקריאות; משמאל, חמשת הדברים שיש לאשר או להכריע.
11 הקריאות שמשחררות
11 חסומים- D30קריאה אחת לסגירה
SELECT @@sql_mode;ONLY_FULL_GROUP_BY פעיל גורם לייצוא וללוחות מחוונים ריקים
- D32/D42קריאה אחת לסגירה
wp wc hpos statusHPOS פעיל קובע את נתיב התיקון של order-meta/metabox
- D15קריאה אחת לסגירה
SHOW CREATE TABLE lcf_seaterInnoDB מול MyISAM תיקוני המקביליות חסרי־תוקף על MyISAM
- D16קריאה אחת לסגירה
SELECT id,time FROM lcf_seater LIMIT 20שניות מול מילישניות קובע את תפוגת שמירת המושב
- D19קריאה אחת לסגירה
order-meta field-name grepהאם PAN/CVV גולמי ומספר תעודת זהות נשמרים? (שמות שדות בלבד)
- D31קריאה אחת לסגירה
woocommerce_blocks_patterns transient + open_basedirמטמון נתיב מיושן גורם להצפת היומן
- D35קריאה אחת לסגירה
dig TXT (SPF/DKIM/DMARC) + test sendמיילים נופלים לספאם או ניתנים לזיוף
- D33קריאה אחת לסגירה
wp option get template / stylesheetאיזה עותק של ערכת העיצוב פעיל
- D10קריאה אחת לסגירה
allow_url_include / open_basedirהאם export-attendees הוא RFI/SSRF פעיל
- D07קריאה אחת לסגירה
one export filenameלאמת שכ־97 קובצי ה־CSV של הנרשמים ניתנים להורדה
- D01קריאה אחת לסגירה
one live exe()-routed URLלאמת בבטחה את שפיכת נתוני ה־PII של הנרשמים
הפקודות להמחשה בלבד וקריאה־בלבד לא מוצגים ולא נדרשים סודות, אישורי גישה או ערכי לקוחות.
גישה והחלטות מקטעים A–E
קביעת פריצה
ביקורת יומני שרת ו־CDN לאיתור פניות לא־מהימנות ובדיקת מנהל זדוני קובעת אם קמה כעת חובת הדיווח לרשות להגנת הפרטיות.
קריאות שרת/DB בשורה
אחת־עשרה קריאות קריאה־בלבד להעתקה־הדבקה; כל אחת סוגרת ממצא חסום אחד.
עותק staging מבודד
נדרש כדי להדגים בבטחה את 17 הממצאים ההרסניים, לעולם לא על לקוחות חיים.
סשן ניהול
עבור ששת הממצאים החסומים־בהרשאת־ניהול (D37–D42).
שתי החלטות
יעד קנה־מידה (תעבורה שגרתית מול מכירת בזק) ותשתית (אירוח משותף מול VPS מכוונן).
מעתיק בדיוק את הקריאות וההחלטות שלמעלה, מוכנים לאישור בערוץ המאובטח הקיים שלכם.
השלמת התמונה המלאה
כל מה שמופיע כאן הוא מה שאני צריך מכם כדי להפוך את הביקורת הזו לתמונה מאומתת במלואה ומוכנה למסירה. כבר טיפלתי ב-100% מהממצאים (94 פריטים, לכל אחד מסקנה מגובה בראיות); מה שנותר הוא מערך קצר ומדויק של הרשאות ותשובות כל אחת מהן סוגרת פריט פתוח ספציפי. הקפדתי לצמצם זאת למינימום: בלי חיפושים סתמיים, כל בקשה נשענת על סיבה. הבלוק הראשון קריטי מבחינה משפטית וצריך להתבצע עוד היום, ללא תלות בכל השאר.
קביעת אירוע אבטחה (לביצוע ראשון קריטי מבחינה משפטית)
הוכחנו בזמן אמת שמידע רפואי אישי רגיש (PII) וסודות ניתנים להורדה כרגע. על פי חוק הגנת הפרטיות בישראל (תיקון 13), חובת הדיווח לרשות היא מיידית עם עליית החשד. יומני הגישה הופכים את ה’חשד’ לעובדה מבוררת האם כתובת IP לא מהימנה כבר משכה את הקבצים האלה לפני שנכיל אותם?
- יומני גישה של השרת וה-CDN
עם טווח השמירה הרחב ביותר הזמין, כדי שנוכל לספור פניות מכתובות IP לא מהימנות אל הקבצים החשופים .zip/.log/.json/.csv ואל פרמטרי ה-query של הדלת האחורית מטא-דאטה בלבד, לעולם לא נתוני לקוחות.
סוגרמגדיר את היקף האירוע - סקירת wp_users / lcf_users
בדיקה של מנהלים זדוניים/מוזרקים שנוצרו דרך ה-salts שדלפו או דרך ה-CVE של ACF-Extended, ואימות שה-salts וסיסמאות מסד הנתונים הוחלפו.
סוגרD20 · D21
אחת-עשרה קריאות שורה-אחת בשרת / במסד הנתונים
אחת-עשרה ממצאים אמיתיים בקוד, אך מצבם החי/בזמן-ריצה תלוי בערך יחיד לכל אחד. אלה קריאות של העתק-הדבק, לקריאה בלבד ולא הרסניות יחד הן מעבירות פריטים במצב BLOCKED להכרעה סופית של LIVE/CODE ומגיעות ל-100% מלאים.
- SELECT @@sql_mode
האם ONLY_FULL_GROUP_BY פעיל? מכריע האם ייצוא/דשבורדים מחזירים בשקט תוצאות ריקות.
סוגרD30 - wp wc hpos status
האם אחסון ההזמנות בביצועים גבוהים (HPOS) פעיל? מכריע את כל מסלול התיקון של order-meta / metabox.
סוגרD32 · D42 - SHOW CREATE TABLE lcf_seater
InnoDB או MyISAM? על MyISAM כל תיקון מקביליות הוא no-op שקט חובה להמיר תחילה.
סוגרD15 - SELECT id,time FROM lcf_seater LIMIT 20
האם הזמנים בשניות או במילישניות? אי-ההתאמה שוברת את פקיעת ההחזקה (hold-expiry).
סוגרD16 - Order-meta field-name grep
מאמת שנשמרים PAN/CVV גולמיים + תגובת שער התשלום + מספר תעודת זהות (שמות שדות בלבד, לעולם לא ערך).
סוגרD19 - woocommerce_blocks_patterns transient + open_basedir
מאמת את מטמון הנתיב המיושן שמזין את הצפת היומן (log-spam).
סוגרD31 - DNS TXT (SPF / DKIM / DMARC) + one test send
מאמת מדוע מיילים של כרטיסים מגיעים לספאם / ניתנים לזיוף.
סוגרD35 - wp option get template / stylesheet
איזה משני עותקי התבנית הוא LIVE מכריע היכן כל תיקון חייב לנחות.
סוגרD33 - allow_url_include / open_basedir
מאמת האם ה-remote-include של ייצוא-המשתתפים הוא RFI/SSRF חי.
סוגרD10 - One export filename under wpallexport/exports/
התיקייה מחזירה 200 אך רישום התוכן חסום ב-403 נתיב אמיתי אחד מאמת שכ-97 קובצי CSV ניתנים להורדה.
סוגרD07 - One live event/product URL that routes through exe()
מאפשר לנו לאמת בבטחה את דליפת ה-PII של המשתתפים על העותק החי.
סוגרD01
עותק מבודד של סביבת בדיקות (staging)
17 הממצאים ההרסניים משנים נתונים אמיתיים יוצרים הזמנות, חוסמים מושבים ששולמו, מוחקים, מסמנים כרטיסים כמנוצלים ומזריקים SQL. ניתן להדגים אותם בבטחה רק על עותק מבודד ומעוקר, לעולם לא על לקוחות חיים. הישֹיגוּתם כבר הוכחה בזמן אמת דרך הנתב-הכול-יכול הפתוח (god-router, D13); ה-staging נועד רק להדגים את השינוי בבטחה.
- עותק מעוקר של הקוד ומסד הנתונים בסביבה מבודדת
נבנה מהארכיון כמקור לקריאה-בלבד (את הארכיון עצמו אסור בשום אופן לשחזר לסביבת הייצור).
סוגרD43–D59
הפעלת משתמש מנהל-חנות / אדמין
שישה ממצאים חסומים מאחורי הרשאת ניהול וניתן להדגים אותם רק מתוך wp-admin (רצוי על עותק ה-staging).
- חשבון אדמין ייעודי להדגמה
עבור שישה הממצאים המאומתים עקיפת התשלום, ה-metabox שקורס בשמירה, דשבורדי ה-stored-XSS וייצואי ה-CSRF.
סוגרD37–D42
שתי החלטות מצדכם
אלה אינן הרשאות אלה החלטות עסקיות שקובעות עד כמה עמוקה תהיה עבודת קנה-המידה והפלטפורמה.
- יעד קנה-מידה
תעבורה שגרתית יומיומית, או שיאי מכירת-בזק / פתיחת-מכירה (מאות מתחרים על אותם מושבים)? זה קובע את עומק בדיקות-העומס וה-stateless-node.
סוגרקובע עומק T2/T3 - תשתית
להישאר על האחסון המשותף הנוכחי (שמגביל מבנית את יכולת ההתרחבות), או לעבור ל-VPS מכוונן / אחסון WooCommerce מנוהל?
סוגרקובע היקף תשתית
האם נחזיר מערכת עובדת ב-100%?
כן. אין צורך לעזוב את WordPress, וכל תקלה שאיתרנו ניתנת למיפוי לתיקון ספציפי, תחום וסטנדרטי בתעשייה. זו מערכת ברת-שחזור לא אובדן כולל.
למה הכוונה ב-'100% עובד'
אין חשיפה פעילה הארכיון הציבורי, היומנים, הייצואים וקובצי האישורים הוסרו, וכל סוד שדלף הוחלף.
אין משטח תקיפה לא-מאומת הנתב-הכול-יכול (god-router) מוגן מאחורי nonce ובדיקות הרשאה; הדלתות האחוריות הוסרו.
תשלום מבוצע כראוי אימות TLS פעיל, אין שמירת נתוני כרטיס בצד השרת, והיקף ה-PCI מצומצם לטוקן בלבד.
אפס הזמנות-כפולות תחת עומס שריון המושב אטומי ברמת מסד הנתונים, ומוכח בבדיקות עומס.
זרימה תקינה מקצה-לקצה אין קריסה בשמירה, ההזמנות/הכרטיסים/ה-QR תואמים, המיילים נמסרים, והדשבורדים מחזירים נתונים אמיתיים.
בנוי להחזיק לאורך זמן הקוד מובנה מחדש ומכוסה בחבילת בדיקות רגרסיה אוטומטית, עם ניטור פעיל.
אדייק במילים: אני יכול לספק 100%מהליקויים שזוהו מתוקנים, מאומתים ומוגנים בבדיקות וניטור זהו רף קונקרטי ובר-בדיקה. איש אינו יכול להבטיח ביושר מערכת נטולת-באגים לנצח; מה שאני מבטיח הוא שהליקויים הידועים מתוקנים, שהתיקונים מוכחים, ושרגרסיות חדשות נתפסות אוטומטית. שני דברים נוספים חוסמים את המצב ה’מושלם’ הסופי והם חלקית מחוץ לשליטתי: הגישה שלכם ושתי ההחלטות שלמעלה, וסוג ה-PCI SAQ, שאותו קובע הסולק/QSA שלכם.
מה זה כרוך
עצירת הדימום
הכלת האירוע (מחיקת קבצים חשופים, החלפת כל סוד + כל 8 ה-salts), נעילת הנתב-הכול-יכול (god-router), שחזור אבטחת התשלום, טלאי לתוספים הפגיעים, ונטרול ה-cron המשתולל. הקלה גדולה, סיכון נמוך.
מקביליות וקנה-מידה
הפיכת שריון המושב לאטומי (בלתי אפשרי להזמין פעמיים), הזזת עבודה איטית מחוץ ללחיצת הקונה, הוספת מטמון, תיקון הטיפול בנתוני החנות, escaping לכל הפלט, ותיקון מסירוּת המיילים. זהו התיקון לתקיעוֹת ולהזמנות-הכפולות.
תשתית פלטפורמה, אבטחה ופרטיות
מבנה מחדש של הקוד המותאם לכדי תוסף must-use בר-תחזוקה, הסרה מוחלטת של נתוני הכרטיס מהשרתים שלכם, הקשחת התשתית, ובניית בקרות הפרטיות שהחוק מצפה להן בתוספת בדיקות עומס, ניטור וגיבויים.
- המערכת היא ארכיטקטורת קובץ-יחיד בהתאמה אישית, ללא בדיקות כיום צפיפות הליקויים תישאר גבוהה עד שיגיעו המבנה-מחדש של T3 וחבילת הבדיקות. זו בדיוק הסיבה לקיומו של T3.
- ’100%’ תחום במתן הגישה שלמעלה ובמענה לשתי ההחלטות; חלק מהעומק (קנה-מידה, סוג PCI SAQ) נגזר מהתשובות האלה.
- חלונות שינוי חשובים: אנו מתזמנים מיגרציות מסוכנות סביב לוח האירועים שלכם, כך שאף מכירה חיה לא תיפגע.
לו"ז והשקעה
אומדן מלמטה-למעלה כל פריט עבודה מתומחר בנפרד, מקובץ לפי השכבות שניתן לשלוח באופן עצמאי, עם טווח נמוך / צפוי / גבוה. הזינו את התעריף השעתי שלכם וכל סיכום מתחשב מחדש בזמן אמת.
- T1עצירת הדימום
- 86–150108 h
- T2מקביליות וקנה-מידה
- 134–224170 h
- T3פלטפורמה, אבטחה ופרטיות
- 186–340246 h
- Xרוחביים
- 58–11680 h
- סכום ביניים בנייה
- 464–830604 h
- תקורה (ניהול ותיעוד 15% + QA ואימות 10%)
- +25%+151 h
השעות והחישוב שלמים ובני-הגנה. הסכום הכספי הוא בכוונה מציין-מקום הזינו את התעריף השעתי שלכם וכל סיכום בעמוד זה יתעדכן מיידית.
פירוט הסעיפים
שעות לכל פריט עבודה, נמוך / צפוי / גבוה. מקובץ לפי השכבה שבה הוא נשלח; פריטים רוחביים (X) משתרעים על כל השכבות.
הכלה ותגובה לאירוע (מחיקת ארטיפקטים, החלפת כל הסודות + 8 salts, כללי חסימה, ביקורת יומנים, ספר-הרצה ל-PPL)
D03·D04·D05·D06·D08·D09·D20
טלאי CVE לתוספים + שדרוג WooCommerce עם רגרסיה מדורגת של זרימת ההזמנה המותאמת
D21·D22·D23·D24·D25·D26
הקשחת הנתב-הכול-יכול (nonce + רשימת-היתר לנקודות-קצה + הרשאה לכל פעולה + הוצאת פעולות אדמין מ-nopriv + מגביל קצב)
D13·D14
עצירת דימום PCI בשכבת הקונפיגורציה (אימות TLS + זמני-קצוב + אידמפוטנטיות, הסרת עקיפה, הפסקת שמירת נתוני כרטיס/SAD)
D17·D18·D19·D37
תיקון ה-Cleaner + נטרול ה-cron (return→continue, הסרת קריאות בכל init, ביטול תזמון כל-שנייה, cron מערכתי)
D60·D61·D62
חיסול IDOR לא-מאומת / דלת אחורית (שער HMAC ל-view_ticket_svg + הגבלת קצב; הסרת פרמטרי override/debug)
D02·D01·D11·D52
הישגי-ביצועים מהירים (מגבלת זיכרון, OPcache, מטמון-עמוד לעמודי שיווק, N+1 בנתיב החם)
D29·D34·D74
סכימה-בקוד + המרה ל-InnoDB + UNIQUE(event,seat) + אינדקסים + מיגרציית נרמול יחידות-זמן
D15·D16
שירות שריון-מושב אטומי (תבנית ReserveStock, ניסיון-חוזר) שמאחד 4 מסלולים + תיקוני SQLi + קדימות OR
D43·D45·D47·D48·D80
הסטה ל-Action Scheduler (QR/Imagick, מייל, HMAC ל-webhook של Make, פקיעת-החזקה מבוססת-קבוצה) + תיקוני Imagick/כרטיס
D64·D65·D67·D70
תקינות HPOS (הצהרת תאימות, API של order-meta, metabox חסר, רישום במסך HPOS)
D32·D38·D42
מטמון אובייקטים Redis + הפניית סשנים ל-Redis + שומר-סשן + הסרת mobble + no-store בנתיבים דינמיים
D63·D31·D27
escaping של הפלט על-פני כ-12 תבניות + היגיינת CSV/JSON + CPT public=>false + תיקון GROUP BY
D39·D40·D53·D55·D58·D89·D30
מסירוּת מיילים (SMTP/DKIM/DMARC, בדיקת החזרה של wp_mail) + טוקני שער HMAC + qr_confirm אידמפוטנטי
D35·D54·D51
העברת הלוגיקה לתוסף must-use + PSR-4 + endroid/qr-code + מחיקת התבנית הכפולה + open_basedir/deploy
D33·D71·D82·D90
צמצום מלא של היקף PCI (hosted-fields/redirect של Tranzila כך שרק טוקן נוגע ב-PHP; SAQ)
D17·D18·D19·D91
הקשחת תשתית (חסימת nginx + כותרות + WAF + 2FA + הגנת brute-force + כיוונון FPM) ומעבר ל-VPS/אחסון מנוהל
D83·D88·D34
שמירה + WP Privacy API (erasers/exporters, משימת שמירה, מזעור) + מדיניות אבטחה + ספר-הרצה לאירוע
D72·D84·D89
בדיקות עומס (מסגרת k6/Locust+ הרצות על החזקת-המושב שאינה ניתנת למטמון + נתיב הצ’קאאוט ב-5–20× מהשיא)
verifies T2-09
נצפוּת (Sentry או שווה-ערך, מנוקה-PII) + הוצאת יומני ה-debug אל מחוץ ל-webroot
D04·D75
גיבוי + מסגרת שחזור-לאחור בדוקה לכל מיגרציה
supporting
תיאום עמידה בפרטיות (סיווג שכבות-נתונים, קשר עם DPO)
supporting
השלמת גילוי וגישה (הרצת 11 הקריאות, ביקורת יומני-האירוע, סגירת BLOCKED ← מאומת)
closes 11 BLOCKED
בניית סביבת staging + מערך-נתונים מעוקר (מבודד, ארכיון כמקור לקריאה-בלבד)
enables D43–D59 demos
חבילת בדיקות רגרסיה / אינטגרציה אוטומטית לזרימות הקריטיות (צ’קאאוט, שריון, הנפקת כרטיסים, שער)
guards everything
איך חישבתי זאת
- 1
מלמטה-למעלה, לא מלמעלה-למטה. תמחרתי כל פריט עבודה בתוכנית התיקון (T1-00…T3-W5) בנפרד, ולא את הפרויקט כסכום גושי.
- 2
מדורג-מורכבות. כל שורה נושאת טווח נמוך / צפוי / גבוה הקשור למורכבותה, המוצלב מול שדות המאמץ והמורכבות שנרשמו לכל ממצא ב-94 התיקים.
- 3
מקובץ לפי השכבות שניתן לשלוח באופן עצמאי, כדי שתראו עלות לכל שלב, ולא רק מספר יחיד.
- 4
תקורה נוספת בשקיפות מעל שעות הבנייה: ניהול פרויקט + תיעוד + מסירה ב-15%, ו-QA + אימות לכל שכבה ב-10%.
- 5
לוח הזמנים נגזר מהשעות בהנחת צוות בכיר קטן (≈2 מהנדסים + PM/QA חלקי), ולאחר מכן הותאם לתלויות אמיתיות (הגישה שלכם, שתי ההחלטות, וחלונות שינוי בלוח האירועים).
- מהנדס WordPress/WooCommerce בכיר עם ניסיון באבטחה ובמקביליות מבצע את העבודה לא גנרליסט (גנרליסט יהיה זול יותר לשעה אך ידרוש הרבה יותר שעות וסיכון גבוה יותר כאן).
- אתם מעניקים את הגישה במשימה 1 במהירות; עיכובי גישה ארוכים מאריכים את לוח הזמנים, לא את השעות.
- סביבת staging זמינה לכל עבודה הרסנית/רגרסיה; שום דבר מסוכן אינו מודגם על לקוחות חיים.
- התעריף הוא מציין-מקום הזינו את התעריף השעתי שלכם והסיכומים למטה יחושבו מחדש בזמן אמת.
- ארכיטקטורת הקובץ-היחיד ה’כול-יכולה’ עלולה להסתיר צימוד הטווח הגבוה סופג הפתעות שיתגלו ברגע שנהיה בפנים.
- שדרוג WooCommerce + מצב HPOS (קריאה במצב BLOCKED) עלול להרחיב את T1-01/T2-11 אם זרימת ההזמנה המותאמת מתנגשת עם הליבה החדשה.
- סוג PCI SAQ נקבע על-ידי הסולק שלכם; קביעה מחמירה יותר מוסיפה היקף ל-T3-W2.
ציר הזמן
ההכלה מתחילה היום ואינה ממתינה לשאר. להלן לוח הזמנים המצטבר עם צוות בכיר קטן; כל שלב הוא אבן-דרך שניתנת לשילוח, וכל הערת 'מותנה ב' מציינת היכן הקלט שלכם קובע את הקצב.
- שלב 0 הכלהמיידי → מספר ימים
החשיפה נעצרה, הסודות הוחלפו, קביעת האירוע בעיצומה.
מותנה ב: גישה לשרת + אישור שלכם - שלב 1 Tier 1 הושלם~2–3 שבועות
אין משטח תקיפה לא-מאומת, התשלום מאובטח, ה-CVE-ים תוקנו, וה-cron שפוי.
מותנה ב: staging + 11 הקריאות - שלב 2 Tier 2 הושלם~8–9 שבועות (מצטבר)
מערכת מאובטחת, נכונה, לא-שוברת ומהירה יותר: אפס הזמנות-כפולות, מיילים שנמסרים, ונתונים נכונים.
מותנה ב: HPOS + קריאות המנוע; החלטת יעד קנה-המידה - שלב 3 Tier 3 הושלם~16–20 שבועות (מצטבר)
הפלטפורמה המלאה, בת-התחזוקה, עם היקף PCI מצומצם, תואמת-פרטיות ובדוקת-עומס, עם ניטור ובדיקות.
מותנה ב: החלטת תשתית; PCI SAQ; חלונות אירועים
מערכת מאובטחת ועובדת (עד Tier 2) בכחודשיים; הפלטפורמה המלאה וה’מושלמת’ (עד Tier 3) בכארבעה עד חמישה חודשים מצטברים ההבדל בין השתיים הוא כולו עומק עבודת התשתית וקנה-המידה.
כיצד 228 אותות גולמיים הפכו ל-94 פריטים מאומתים
שתים־עשרה עדשות מומחה, מעבר איחוד־כפילויות אחד, ופסק לכל פריט נמדד מבלי לגעת אף פעם בערך אמיתי.
צינור העיבוד
עדשות מומחה
שתים־עשרה עדשות ביקורת עצמאיות סרקו את ערכת העיצוב המותאמת, התוספים, סכמת מסד הנתונים, ואת משטח ה־HTTP החי.
אותות גולמיים 227 מאומתים + 1 שהופרך
227 ממצאים גולמיים מאומתי־קוד ועוד אחד שהופרך מאוחר יותר 228 אותות גולמיים הנכנסים למיון.
ניכוי כפילויות
שתים־עשרה עדשות מומחה הפיקו 227 ממצאים גולמיים; בעיות מערכתיות (נתב־העל סומן 8×) מתכווצות לפגמים ייחודיים. כל פגם ייחודי מאומת פעם אחת; ספירות העדשות מסתכמות חזרה ל־227, ועוד 1 שהופרך = 228.
פריטים ייחודיים
בעיות מערכתיות מתכווצות לפגמים ייחודיים; לאחר מכן כל פגם ייחודי מאומת בדיוק פעם אחת.
פסק סופי אחד לכל פריט
כל אחד מ־94 הפריטים נושא פסק סופי אחד בדיוק: 20 חי / 60 קוד / 11 חסום / 2 לא־שוחזר / 1 הופרך = 94 (100%).
228 → 94
העמודה הגולמית מתמוטטת אל העמודה הייחודית, מפוצלת לפי פסק סופי.
| שלב | כמות |
|---|---|
| ממצאים גולמיים (227 מאומתים + 1 הופרך) | 228 |
| ייחודי · מאומת חי | 20 |
| ייחודי · מאומת בקוד | 60 |
| ייחודי · חסום | 11 |
| ייחודי · לא־שוחזר | 2 |
| ייחודי · הופרך | 1 |
| סך הכול ייחודי | 94 |
- גולמי 228
- מאומת חי 20
- מאומת בקוד 60
- חסום 11
- לא־שוחזר 2
- הופרך 1
לכל פריט יש פסק. החלוקה 20 + 60 + 11 + 2 + 1 מסתכמת ל־ 94, כלומר 100% מהפריטים מטופלים; אף אחד לא נותר לא־בדוק.
האימות החי מדד רק סטטוס HTTP + סוג־תוכן + גודל־בייטים; לאימות מציאות־הנתונים ספרנו מופעים של שמות־שדות/תבניות־טלפון מבלי להדפיס או לאחסן אף ערך PII או סוד בודד.
- verification/00-triage-register.md
- verification/03-live-verification-results.md
- verification/04-summary-index.md
- verification/findings/D01–D93 + R01 (94 dossiers)
- deliverables/00-client-access-and-decisions-request.md
- deliverables/01-client-proof-pack.md
- remediation/T1-00…T1-06, T2-00, T3-00
נספח
הצהרת הסתייגות משפטית ומגבלות דאטה
עורך הדוח מבהיר ומדגיש את הנקודות הבאות.
- 01
אופי הדוח: הדוח מהווה אבחון טכני ראשוני בלבד. הוא אינו מהווה ייעוץ משפטי, חוות דעת משפטית, או אישור לעמידה בתקני רגולציה מחייבים (כגון חוק הגנת הפרטיות, תקנות PCI-DSS וכיו"ב). כל החלטה עסקית או משפטית המתקבלת על בסיס נתונים אלו היא באחריות הבלעדית של המזמין.
- 02
מגבלות הדאטה: האבחון בוצע בנקודת זמן מוגדרת. ייתכן כי המערכת השתנתה מאז, או שקיימים נתונים נוספים שלא היו נגישים לעורך הדוח. לפיכך, אין לראות בנתונים המוצגים "מקור אמת יחיד".
- 03
היעדר חבות: עורך הדוח אינו נושא באחריות לכל נזק, ישיר או עקיף, העלול להיגרם כתוצאה מהסתמכות על הממצאים הטכניים או מהיעדר תיקונם בזמן. חובת הדיווח בוצעה מתוקף אתיקה מקצועית בלבד.
- 04
שימוש בלתי מורשה: ממצאי הדוח המיוחסים ל"דלתות אחוריות" או "מנגנונים חריגים" משקפים התנהגות טכנית שנצפתה בפועל. עורך הדוח אינו מייחס כוונה זדונית לגורם ספציפי ואינו קובע את מקורם של מנגנונים אלו, אלא מדווח על קיומם והסיכון הנובע מהם בלבד.
- 05
תיקון ליקויים: ביצוע ההמלצות הטכניות המוצעות בדוח אינו מבטיח הגנה הרמטית מפני איומי סייבר עתידיים, אלא מצמצם את מרחב התקיפה לסטנדרטים מקובלים בתעשייה.