במשך שנים מונחים מתכנתים במגוון שפות להשתמש ב-Stored Procedures על מנת לשפר את ביצועי השאילתות שאותן הם מפעילים כחלק מהתוכנות אותן הם מפתחים. בנוסף, מומחי אבטחת מידע מזהירים תמיד מפני הסיכונים שבעבודה מול שרת מסד נתונים שלא באמצעות Stored Procedures. בשל כל הנושאים הללו, הפך השימוש ב-Stored Procedures למעין "קמיע" של תוכניתנים ואנשי מערכות מידע אשר על ידי שימוש בו הם משוכנעים (ואולי אף משכנעים את עצמם) כי מערכת המידע אותה הם מפתחים מחוסנת כעת מפני פגעי אבטחת המידע. משום כך ראיתי לנכון להסביר מעט על מהות השימוש ב-Stored Procedures מול שרתי מסדי נתונים, מתי השימוש בהם הוא אפקטיבי ומדוע, מתי למרות השימוש בהם כדאי להשתמש באמצעים נוספים.
ובכן, נסביר, בתור התחלה, מהם בדיוק Stored Procedures ומהם המשמעויות של שימוש בהן לעומת שימוש באמצעים אחרים לגישה למסד הנתונים. על מנת לגשת למסד נתונים חייבים להשתמש בשאילתה, כאשר שאילתות מבצעות, בגדול, ארבע פעולות בסיסיות לגבי המידע המאוחסן במסד הנתונים: 1. SELECT – שליפה. פעולה זו מאחזרת נתונים מטבלה במסד הנתונים. ניתן להשתמש בשיטה זו על מנת לאחזר נתונים תוך כדי מיזוגם בין מספר טבלאות ו/או שאילתות אחרות. 2. INSERT – כתיבת ערכים חדשים. פעולה זו מייצרת רשומות חדשות בטבלה במסד הנתונים. את הנתונים אותם פעולה זו תכתוב למסד הנתונים ניתן להזין כארגומנטים לפנייה או לקלוט מטבלה או שאילתה אחרת. 3. UPDATE – עדכון ערכים קיימים. פעולה זו מעדכנת רשומות קיימות במסד הנתונים. את הנתונים אותם פעולה זו תכתוב למסד הנתונים ניתן להזין כארגומנטים לפנייה או לקלוט מטבלה או שאילתה אחרת. 4. DELETE – מחיקת רשומות ממסד הנתונים. פעולה זו מוחקת רשומות שנבחרו ממסד הנתונים. את הקריטריון לפיו תיבחרנה הרשומות שאותן יש למחוק ניתן להגדיר בהתבסס על נתונים מטבלה או שאילתה אחרת. בנוסף לפעולות הללו, קיימות עוד שלוש פעולות בסיסיות המבוצעות על מבנה הנתונים במסד הנתונים: 1. CREATE – יצירה. פעולה זו מקימה טבלאות חדשות, Stored Procedures חדשות ואף מסדי נתונים חדשים. 2. DROP – מחיקה. פעולה זו מוחקת טבלאות שלמות, Stored Procedures ואף מסדי נתונים שלמים. 3. ALTER – פעולה זו משנה מבנה של טבלאות (הוספה/הסרה של טורים), מבנה של Stored Procedures ומסדי נתונים שלמים. בעת ביצוע פנייה מסוג זה שרת מסד הנתונים נדרש לנתח את מבנה השאילתה שהוצגה לו ולבצע תהליך הידור (קומפילציה) שלה, אחד היתרונות המוכרים ביותר לשימוש ב-Stored Procedures הוא העובדה שמדובר בשאילתה שהיא כבר מהודרת (מקומפלת) ומשום כך ביצועיה יהיו טובים יותר. למרות שנתון זה אינו מדויק שכן בעקבות השימוש הרב אשר נעשה בשאילתות כאלו הוקמו בשרת מסד הנתונים מנגנונים מיוחדים שכל תפקידם הוא לשפר את ביצועיהן ואשר בעקבותם כיום, במקרים מסוימים נופלים ביצועי תחביר טיפוסי לפניה לפעולות אלו מתוך תוכנית (ללא תלות בשפה) נראה בערך כך:
string sqlCommandText = "SELECT * FROM MyTable WHERE FieldX='" + txtFieldX.Text + "'"; SqlCommand sqlCmd = new SqlCommand(); sqlCommand.ExecuteReader();
אם ניקח בחשבון שמישהו יכול בשדה הטקסט שלנו להקיש כל טקסט שהוא (מה שאסור שיהיה), נוכל בקלות להגיע למצב שבו שורת הקוד שתישלח לשרת ה-SQL תיראה כך:(הטקסט המודגש באדום מציין את הטקסט שהוכנס בשדה txtFieldX)
SELECT * FROM MyTable WHERE FieldX='a' AND DELETE MyTable OR FieldX='a'
בשלב הזה שרת ה-SQL יבצע קודם את השאילתה הפנימית (DELETE * FROM MyTable) ורק לאחר מכן ינסה לבצע את השאילתה העוטפת. כך שלמעשה יימחקו כל הנתונים מהטבלה ששמה MyTable. באופן דומה יהיה ניתן לבצע כל שאילת SQL שעולה בדעתכם.
האפשרות לשימוש ב-Stored Procedures מספקת פתרון מסוים לבעיה זו בכך שהיא גורמת לשאילתה שלנו להיראות כך:
EXEC MyStoredProc @Arg0 = 'a' AND DELETE MyTable OR FieldX='a'
במקום למשל, ככה:
EXEC MyStoredProc @Arg0 = 'MyFieldxValue"
באופן כזה, ניסיון ליצור שאילתה מסוכנת ייצור למעשה הודעת שגיאה לגבי המבנה של השאילתה ולא יבצע את הפנייה עצמה למסד הנתונים. עם זאת, עדיין מתאפשר ביצועה של שאילתה מסוכנת, זאת באמצעות מתקפת SQL Injection מדור שני. כלומר, אם בשלב מסוים בעבודה מול מערכת המידע אנו נדרשים להזין תוכן מסוים אשר במקום אחר מערכת המידע מוצג למשתמש תוכן כלשהו על בסיס אותו נתון, נוכל להזין ערך מסוכן בשלב הראשון אשר בעזרת טיפול נכון בתו הגרש יאפשר לנתון להיכנס למסד הנתונים ללא גרימת נזק בשלב הזה, אך אם מערכת המידע הזו מאפשרת הצגת נתון אחר על בסיס הערך הזה במיקום אחר, ייתכן בהחלט (תלוי בשאילתה המבוצעת) שהערך המסוכן שהזנו יבוא לידי ביטוי. כמו בדוגמה הבאה:
נניח שאנו עובדים על מערכת מידע כלשהי אשר במקרה מסוים מחייבת את המשתמש בהזנת פרטיו האישיים כחלק מהרשמה לאתר. בנוסף, מחויב המשתמש בהזנת שם משתמש אשר ישמש אותו בהמשך. לאחר הקמת שם המשתמש, יחויב המשתמש בכניסה למערכת אשר לאחריה יוצג במיקום כלשהו באתר שמו המלא כפי שהזין אותו בשלב ההרשמה.
בשלב ההרשמה אנו מנסים להציב את הטקסט המסוכן הבא בתור שם המשתמש המבוקש:
a'; DELETE Users WHERE UserName<>'a
נניח, שהמתכנת שפיתח את האתר ניסה להגן עליו באמצעות החלפה של כל תו גרש בשניים ואף טרח להשתמש ב-Stored Procedures כאמצעי נוסף, כך שהפניה למסד הנתונים נראית כך:
EXEC AddNewUser @UserName='a"; DELETE Users WHERE UserName<>"a', @FirstName='Israel', @LastName='Israeli'
עד כאן, הכל לכאורה טוב ויפה, הוספנו רשומה חדשה במסד הנתונים, שום דבר לא נמחק ולא נגרם בשלב זה כל נזק. אך למעשה החדרנו למסד הנתונים פצצה מתקתקת, היות ובאתרים רבים מקובל (ואף הגיוני) לשלוף בעת הכניסה לדף הראשי את שמו המלא של המשתמש ולאחסן אותו במיקום כלשהו הזמין ל-Session הזה, למשל אובייקט ה-Session, כך: