מילון סייבר בעברית

מה זה SQL Injection ואיך מפרידים נתונים משאילתה

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

איפה עובר הגבול בין נתון להוראה

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

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

עקרונות הגנה ומה כל אחד מוסיף

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

שכבות הגנה והגבולות שלהן
שכבהתרומהמה אינה מחליפה
פרמטרים לשאילתהערכים מטופלים כנתונים במנגנון הנתמךטיפול בכל מבנה דינמי אחר
בדיקת ערכיםהתאמה לכללים שהיישום צריךבנייה בטוחה של השאילתה
הרשאות מסדצמצום היכולת הזמינה ליישוםתיקון החולשה בקוד
WAFבקרה משלימה על בקשותהוכחה שכל השאילתות בטוחות
OWASP: מניעת SQL Injection

מה בעל אתר צריך לברר לגבי תוסף או קוד

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

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

דוגמה להסבר הממצא בלי לפרסם דרך תקיפה

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

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

איך SQL Injection שונה מ-XSS ומ-CSRF

SQL Injection נוגע לפרשנות שאילתה במסד. XSS נוגע להרצת תוכן לא רצוי בדפדפן, ו-CSRF לפעולה לא רצויה דרך הקשר מאומת של משתמש. ההגנות אינן אותו מנגנון, ולכן תיקון בשכבה אחת אינו הוכחה שהאחרות מוגנות.

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

מקור מקצועי: OWASP: מניעת SQL Injection

תשובות ברורות

שאלות שעולות בנושא

SQL Injection אפשרי רק בטופס התחברות?

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

HTTPS או תוסף אבטחה מונעים אותו תמיד?

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

איך יודעים שהבעיה תוקנה?

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

מתקדמים לפי הצורך

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

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

לתיאום בדיקה וטיפול