SP זה לא פתרון קסם
נכון שכתיבה של SP מאד עוזרת בהגנה על בסיס הנתונים מSQL Injection (דרך אגב זאת צורת עבודה נכונה גם בלי קשר לSQL Injection), אבל כתיבת SP בלבד לא תמיד תעזור. צריך לדאוג לעוד מספר דברים. קודם כל צריך שהSP יהיה כתוב נכון. SQL Injection זאת טכניקה, שמנצלת שגיאות שנעשו. השגיאות לא חייבות להיות של מפתח WEB. השגיאה יכולה להיות של מפתח SQL (אפילו שמעתי על DBA, שעושה שגיאות מידי פעם
). נניח, שיש לנו בבסיס הנתונים טבלה בשם users ובטבלה מאחסנים שמות משתמשים. לצורך הפשטות נגדיר טבלה עם 3 שדות בלבד.
--Creating the table create table Users (UserID int identity(1,1), FirstName varchar(20), LastName varchar(20)) go --Inserting 2 records into the table INSERT INTO Users (FirstName, LastName) SELECT 'Avraham', 'Avinu' union SELECT 'Elizabeth', 'Malca' go
נניח, שיש לנו SP, שמקבל כפרמטר userid, ומחזיר את הרשומה של אותו משתמש. הקוד של הSP נראה כך:
create proc ShowUser (@UserID varchar(50)) as DECLARE @SQL varchar(150) SET @SQL = 'SELECT FirstName, LastName FROM Users WHERE UserID = ' + @UserID EXEC (@SQL)
במידה והמשתמש שולח רק קוד, משתמש לא אמורה להיות שום בעיה. למשל אם הSP יופעל בצורה הבאה:
exec ShowUser 2
המשתמש יקבל את פרטי הUser שהUserID שלו הוא 2. לעומת זאת אם הSP יופעל עם הפרמטר הבא:
exec ShowUser '1 truncate table Users'
המשתמש יקבל את הרשומה של UserID מס' 1, אבל ישר אחרי זה נתוני הטבלה יימחקו. בדוגמא השתמשתי אמנם בSP מאד בעייתי, אבל לפעמים יש SP כאלו באפליקציות, לכן לא ניתן להחליט שכתיבת SP בלבד מגנה עלינו מSQL Injection. גם אם הSP כתוב בצורה מצויינת עדיין יכולות להיות בעיות עם השיכבה שמפעילה את הSP כתובה לא נכון ולא נעשית בדיקה על הUser input. בוא נניח, שהSP שונה ונראה בצורה הבאה:
alter proc ShowUser (@UserID int) as SELECT FirstName, LastName FROM Users WHERE UserID = @UserID
שים לב, שכרגע הinput parameter של הSP הוא מספר, ולא יכול להכיל פקודות מזיקות. אם אני אנסה להפעיל את הSP ולמחוק את הנתונים כמו שעשיתי בגרסא הקודמת, המחיקה לא תתבצע, ואני אקבל את הודעת השגיאה הבאה:
Msg 8114, Level 16, State 1, Procedure ShowUser, Line 0 Error converting data type varchar to int.
למרות זאת עדיין יכולה להיות סכנה. אם בממשק המשתמש אני עדיין לא מבצע בדיקה על הinput ואני לא משתמש באובייקט, שבו מוגדר בדיוק מספר הפרמטרים, סוג הפרמטרים, אורך הפרמטרים וכד' (לדוגמא command object), אלה משתמש באובייקט שמשרשר פרמטרים לקריאה לSP ומפעיל את הSP בצורה דינאמית, המשתמש יכול לקרוא לSP בצורה הבאה:
exec ShowUser 1 truncate table Users
הפעם המשתמש הפעיל את הSP אבל לאחר סיום הSP הופעלה פקודת הTRUNCATE. אלה היו 2 דוגמאות פשוטות, שמראות שכתיבת SP בלבד לא מספקות. ב2 המקרים היו עוד 2 שגיאות מאד גסות, שכל אחת מהן יכלה למנוע את מחיקת הנתונים. השגיאה הראשונה היא, שהuser input לא נבדק לפני שנעשה בו שימוש. השגיאה השניה היא מתן הרשאות של dbo למשתמש. נכון, שאת הדוגמאות עשיתי בבסיס נתונים שלי, אם הרשאות שלי, אבל לצערי בתור DBA שעבד גם באירגונים גדולים, שרוכשים מערכות מספקים, ברוב מוחלט של המערכות, יש שימוש במשתמש עם הרשאות של dbo, כך שהדוגמא לא תלושה מהמציאות.
