סייבר ואבטחת מידע · web-api-pt

SQL Injection: זיהוי ואימות בטוח במעבדה

מאת תאיר מלכא 6 דק׳ קריאהפורסם: 5 באוגוסט 2026

המחשה חזותית מקצועית בנושא בדיקת SQL Injection בתחום Web ו-API PT

תשובה מהירה

בדיקת SQL Injection נבדק רק במעבדה או במערכת מורשית. בודקים את Request/Response, התנהגות השרת, Roles, State והשפעה, תוך שימוש בבדיקות מינימליות שאינן פוגעות בנתונים.

בדיקת אבטחת Web ו-API צריכה לבחון את גבולות האמון, ההרשאות, הקלט, ה-State והלוגיקה העסקית. כל בדיקה במאמר מיועדת למעבדה, CTF או מערכת שניתנה לגביה הרשאה מפורשת. המאמר הנוכחי מתמקד ב-בדיקת SQL Injection ומיועד ל-תלמידי Web PT ומפתחים. המטרה היא לתת שיטת עבודה שאפשר ליישם בתרגול, בראיון מקצועי ובסביבת עבודה, בלי להסתפק בהגדרה מילונית.

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

התרחיש המעשי במאמר הוא: בדיקה על אפליקציה פגיעה ייעודית עם נתוני דמה.. כל הדוגמאות הן נתוני מעבדה או תיאור תהליכי. כאשר מדובר ב-Penetration Testing, Web או Cloud, יש לעבוד רק עם אישור מפורש, Scope מוגדר ויכולת לעצור את הבדיקה.

היכן נוצרת SQLi

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

בתרגול, רשמו את input surface, parameterization, error behavior, boolean/time-safe lab checks, least privilege, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

מיפוי Inputs

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

אינדיקציות ו-Differential testing

בדיקה מקצועית ל-בדיקת SQL Injection מתחילה בתנאי הצלחה ותנאי כישלון. מגדירים Case חיובי, Case שלילי, Case גבול ופעילות לגיטימית דומה. כך ניתן לזהות גם False Negative וגם False Positive.

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

אימות בטוח ו-Evidence

Remediation ו-Retest

מוקדי בדיקה ייחודיים

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: input surface, parameterization, error behavior, boolean/time-safe lab checks, least privilege, logging. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

input surface: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
parameterization: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
error behavior: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
boolean/time-safe lab checks: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
least privilege: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
logging: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

כאשר אחד המוקדים אינו זמין, יש לתעד את הפער ולבחור חלופה. לדוגמה, אם Process identifier אינו יציב, אפשר להיעזר בזמן, Host, User ו-Parent; אם Payload מוצפן, משתמשים ב-Metadata, נפח, תדירות ו-TLS/DNS context.

תהליך עבודה מומלץ

הגדירו Scope ושאלת עבודה אחת בנושא בדיקת SQL Injection.
רשמו את מקורות הנתונים והראיות הדרושים: input surface, parameterization, error behavior, boolean/time-safe lab checks.
צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

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

שלב	מה מבצעים	תוצר
הכנה	הגדירו Scope, זמן ויעד. רשמו אילו שדות או ראיות מתוך input surface, parameterization, error behavior צפויים להופיע.	תוכנית בדיקה קצרה
יצירת נתון	בצעו פעולה בטוחה ומדומה הקשורה ל-בדיקת SQL Injection, ללא מידע אמיתי או השפעה על מערכת ייצור.	אירוע/Request/Flow מבוקר
איסוף	אספו את הראיה הגולמית ואת ההקשר ממקור נוסף. ודאו Time zone, מזהים ושלמות.	שתי ראיות מקושרות
ניתוח	כתבו מה כל ראיה מוכיחה, מה אינה מוכיחה ומהו ההסבר הלגיטימי האפשרי.	מסקנת ביניים
סיום	בחרו סגירה, הסלמה, Finding או Tuning; הוסיפו המלצה ו-Retest.	תוצר מתועד

Checklist מעשי

בדקו ותעדו: Role ו-session.
בדקו ותעדו: Endpoint ו-method.
בדקו ותעדו: Request/Response.
בדקו ותעדו: Object identifier.
בדקו ותעדו: Server-side effect.
בדקו ותעדו: Control expected ו-remediation.
ציינו Time zone, גרסת כלי ושעת איסוף.
שמרו את הנתון הגולמי לפני סינון או שינוי.
כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
הגדירו בעלים ופעולת המשך עם מועד.

טעויות נפוצות

לבדוק רק Status code.
להסתמך על שינוי Client-side.
להשתמש ב-Payload מסוכן.
לא לבדוק Roles שונים.
להתעלם מלוגיקה עסקית.
לדווח בלי Request/Response נקיים.

סיכום ו-CTA

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

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

שאלות ותשובות

האם מותר לבדוק בדיקת SQL Injection באתר ציבורי?

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

מה עושים כאשר חלק מהנתונים חסרים?

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

כמה זמן צריך לשמור את הראיות?

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

איך מתרגלים בלי לסכן מערכת אמיתית?

משתמשים במכונות וירטואליות, נתונים מדומים, CTF או מעבדה ייעודית. בבדיקות מורשות מגדירים Scope, Stop conditions וגיבוי לפני תחילת העבודה.

מקורות

רוצים לבדוק אם המסלול מתאים לכם?

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

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI

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

ללימודי SOC וסייבר במסגרת תוכנית Cybersecurity & AI יצירת קשר

על הכותב

תאיר מלכא

מייסד ומנכ״ל HPI ומרצה לסייבר

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

לפרופיל הכותב ↗

הקודם באשכול

Session Security: Cookies, Tokens ו-Session Fixation

הבא באשכול

Cross-Site Scripting: Stored, Reflected ו-DOM