מבדק חדירה לאתר: מה זה ומתי העסק שלכם צריך אותו

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

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

במדריך הזה נסביר:

• מה זה מבדק חדירה ובמה הוא שונה מסריקת פגיעויות;
• למה עסק צריך אותו ומה בודקים באתר עסקי;
• אילו סוגי מבדקים קיימים ומי מבצע אותם;
• איך מתנהל מבדק חדירה, שלב אחר שלב;
• אילו כלים משמשים את הבודקים;
• מה דורש החוק בישראל ואיך להתכונן למבדק באתר Webflow, ‏WordPress או Wix.

מה זה מבדק חדירה (פנטסט)

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

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

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

מבדק חדירה מול סריקת פגיעויות

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

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

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

למה עסק צריך מבדק חדירה

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

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

מה בודקים באתר של עסק

ברוב האתרים העסקיים מבדק חדירה מתמקד בנקודות הבאות:

• טפסים ושדות קלט: הזרקת SQL, ‏XSS ושליחת קבצים זדוניים דרך טפסי צור קשר והרשמה;
• התחברות והרשאות: סיסמאות חלשות, ניסיונות כניסה בלי הגבלה, אימות דו-שלבי, ומה משתמש רגיל יכול לראות או לשנות;
• תשלומים והזמנות: שינוי מחירים, כמויות והנחות, ועקיפת שלבים בתהליך הקנייה;
• ממשקי API ואינטגרציות: חיבורים ל-CRM, למערכות סליקה ולכלי אוטומציה, מפתחות API חשופים ו-webhooks בלי אימות;
• הגדרות שרת ודומיין: תעודות SSL, כותרות אבטחה, קבצים ותיקיות שנשארו פתוחים, תת-דומיינים נטושים;
• רכיבי צד שלישי: תוספים, תבניות, ספריות JavaScript וסקריפטים חיצוניים.

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

סוגי מבדקי חדירה

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

קופסה לבנה (White Box)

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

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

קופסה שחורה (Black Box)

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

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

קופסה אפורה (Gray Box)

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

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

צוות אדום וצוות כחול

בארגונים גדולים מחלקים את העבודה לשני צוותים. הצוות האדום (Red Team) תוקף: הוא מדמה מתקפות מתמשכות ובודק לא רק את הטכנולוגיה, אלא גם את התגובה של הארגון. הצוות הכחול (Blue Team) מגן: הוא מנטר, מזהה חריגות, מגיב לאירועים ומחזק את ההגנות. כשהשניים עובדים יחד, משתפים ממצאים ולומדים זה מזה, קוראים לזה לפעמים Purple Team.

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

חיצוני ופנימי

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

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

איך מתנהל מבדק חדירה, שלב אחר שלב

התהליך משתנה לפי היקף הפרויקט, אבל ברוב המבדקים יש אותם שלבים.

1. הגדרת היקף ואישור בכתב

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

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

2. איסוף מידע ומיפוי

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

3. סריקה וזיהוי חולשות

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

4. ניצול מבוקר

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

5. דוח והמלצות

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

6. תיקון ובדיקה חוזרת

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

כלים שבהם משתמשים בודקי חדירה

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

סורקי פגיעויות: OpenVAS ו-Nessus

OpenVAS, שמפותח היום על ידי Greenbone, הוא סורק פגיעויות בקוד פתוח. הוא בודק שרתים, נתבים, חומות אש ושירותי רשת, מחפש רכיבים מיושנים, סיסמאות ברירת מחדל ועדכונים חסרים, ומפיק דוח עם המלצות. Nessus של Tenable הוא החלופה המסחרית הנפוצה. כלים דומים: Qualys ו-Nexpose.

כלים לבדיקת אפליקציות ווב: Burp Suite ו-ZAP

Burp Suite הוא כלי העבודה המרכזי של רוב בודקי אפליקציות הווב. הוא יושב בין הדפדפן לשרת, מאפשר לראות ולשנות כל בקשה, ומאתר חולשות כמו XSS והזרקת SQL. ZAP הוא חלופה בקוד פתוח, מתאימה גם לסריקות אוטומטיות קבועות. לאתרי WordPress יש גם WPScan, שבודק גרסאות של ליבה, תוספים ותבניות מול מאגר חולשות ידועות.

מיפוי רשת וניתוח תעבורה: Nmap ו-Wireshark

Nmap ממפה אילו שרתים ושירותים פתוחים ברשת. Wireshark מנתח תעבורת רשת ומראה אילו נתונים עוברים ואיך. בעזרתו אפשר לגלות, למשל, מידע שנשלח בלי הצפנה.

מסגרות ניצול: Metasploit

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

בדיקת סיסמאות: Hydra ו-Hashcat

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

ניתוח קוד: SonarQube ו-Semgrep

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

מבדק חדירה והחוק בישראל

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

• תקנות הגנת הפרטיות (אבטחת מידע), 2017 מחייבות ארגונים שמחזיקים מאגרי מידע לנקוט אמצעי אבטחה לפי רמת הרגישות של המאגר. במאגרים ברמת אבטחה גבוהה התקנות דורשות גם מבדקי חדירה תקופתיים.
• תיקון 13 לחוק הגנת הפרטיות, שנכנס לתוקף באוגוסט 2025, הרחיב את סמכויות האכיפה של הרשות להגנת הפרטיות והגדיל את הסנקציות על הפרות. אבטחה מתועדת, כולל מבדקים, עוזרת להראות שהעסק עשה את מה שנדרש.
• PCI DSS, תקן האבטחה של חברות כרטיסי האשראי, דורש מבדקי חדירה מעסקים שמעבדים או שומרים פרטי כרטיסים בעצמם. אתר שמעביר את התשלום לדף סליקה מאובטח של ספק חיצוני מצמצם מאוד את החובות שלו.
• לקוחות גדולים ומכרזים דורשים יותר ויותר מספקים להציג דוח מבדק חדירה עדכני, במיוחד בתחומי הבריאות, הפיננסים והביטוח.

אירוע סייבר אפשר לדווח למערך הסייבר הלאומי במוקד 119. כדי לדעת אילו חובות חלות על העסק שלכם, היעזרו ביועץ משפטי או ביועץ אבטחת מידע. המדריך הזה לא מחליף ייעוץ כזה.

Webflow, ‏WordPress ו-Wix: מה בודקים בכל פלטפורמה

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

WordPress

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

Webflow ו-Wix

בפלטפורמות מנוהלות כמו Webflow ו-Wix, ספק הפלטפורמה אחראי לשרתים, לעדכונים ולתעודות SSL, והעסק לא יכול ואסור לו לבדוק את התשתית עצמה. מה שנשאר באחריותכם: קוד מותאם אישית (Custom Code ו-Velo), סקריפטים של צד שלישי, טפסים ולאן הם שולחים נתונים, ממשקי API ו-webhooks שמחוברים לאתר, והרשאות הגישה של העובדים והספקים לחשבון.

אינטגרציות ואוטומציות

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

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

סריקה אוטומטית במקום מבדק

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

מבדק על אתר חי בלי גיבוי ותיאום

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

דוח שנשאר במגירה

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

בדיקה חד-פעמית

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

היקף צר מדי

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

איך RJL Studio עוזרת לשמור על האתר שלכם מאובטח

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

• בונים אתרים ב-WordPress וב-Webflow עם מינימום תוספים וסקריפטים, הרשאות לפי תפקיד ואימות דו-שלבי;
• מגדירים טפסים, webhooks ומפתחות API כך שנתונים לא ייחשפו בדרך ל-CRM ולכלי האוטומציה;
• מכינים את האתר למבדק: סביבת staging, גיבויים, מיפוי של כל המערכות המחוברות ורשימת גישות;
• מתקנים את הממצאים מהדוח ומבצעים בדיקות QA ורגרסיה לפני שהבודק חוזר לבדיקה החוזרת;
• מלווים את האתר בתחזוקה שוטפת: עדכונים, ניטור וגיבויים.

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

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

האם עסק קטן צריך מבדק חדירה?

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

כל כמה זמן כדאי לבצע מבדק חדירה?

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

כמה זמן לוקח מבדק חדירה לאתר?

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

האם מבדק חדירה יכול להפיל את האתר?

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

במה מבדק חדירה שונה מבאג באונטי?

במבדק חדירה ספק אחד בודק את המערכת בזמן ובהיקף מוגדרים, ומגיש דוח מסודר. בתוכנית באג באונטי (Bug Bounty) חוקרים רבים מחפשים חולשות לאורך זמן ומקבלים תשלום רק על ממצאים מאומתים. רוב העסקים מתחילים ממבדק חדירה, ומוסיפים בהמשך מדיניות דיווח פשוטה, למשל קובץ security.txt באתר.