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

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

איך אתר עובד?

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

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

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

מסד הנתונים (Database) וחשיבותו

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

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

הזרקת SQL

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

נדגים באמצעות פקודה אמיתית. המספר הסידורי של דף זה הוא 10311 – אתם יכולים לבחון זאת בעצמכם ולהכנס עם הכתובת https://internet-israel.com/?p=10311 – מה שאני מורה לאתר זה: ״הבא לי את דף מספר 10311״. מה אם הייתי יכול לשגר פקודה בנוסח: ״תמחק את כל הדפים באתר?״ משהו בסגנון:

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

https://internet-israel.com/?p=DELETE_ALL_USERS

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

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

1. למחוק את כל המשתמשים.
2. לשנות דברים.
3. להעתיק את מסד הנתונים אלי.

ועוד דברים.

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

התקפה אמיתית

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

1. שם משתמש.
2. סיסמה.

איך האתר יודע אם שם המשתמש קיים ומתאים לסיסמה? הוא בודק עם מסד הנתונים כמובן. איך? הוא מחלץ את שני הפרמטרים: username ו-password מהטופס ששלחנו אליו.

אפשר לבדוק בעצמכם! הכנסו אל אתר Testfire של IBM ונסו לעשות לוגין. האתר מיועד לבדיקות אבטחה אז אין שום בעיה להתנסות עליו. פיתחו את לשונית הנטוורק בכלי המפתחים (קראו את המאמר על כלי המפתחים אם אינכם מכירים את הכלי) ותראו שהוא באמת משגר סיסמה ושם משתמש. אם אני מקליד my-username ו-my-password בשדה הלוגין, האתר ישלח אותם.

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

SELECT * FROM users WHERE PASSWORD = my-password AND user = my-username

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

מה אם למשל אני אקליד במקום my-username את הטקסט הזה?

'' OR '1' = '1'

מה יקרה אז? השאילתה תהיה כזו:

SELECT * FROM users WHERE PASSWORD = my-password AND user = '' OR '1' = '1'

מן הסתם אף שורה לא תצא מ: ״תביא לי בבקשה את כל השורות שבהן הסיסמה היא my-password ושם המשתמש הוא ריק״. אין משתמש כזה. לכולם יש שם משתמש. אבל שימו לב לתוספת המחוכמת! ״או 1=1״. מתי 1 שווה ל-1? תמיד, כלומר נקבל תשובה חיובית תמיד – כי תמיד 1 שווה ל-1 בכל השורות. וכיוון שכך, אנחנו נוכל להכנס לאתר!

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

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

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

חומרים לקריאה נוספת:

הסבר של נעם רותם על הזרקת SQL לקהל הרחב

פוסט של טל בן שושן המסביר על הזרקת SQL על DVWA – יותר טכני ומיועד ללומדים ולסטודנטים בתחום אבטחת המידע.