התגוננות מפני sql injection

[לומדaspdotnet]

התגוננות מפני sql injection

התגוננות מפני sql injection קראתי על הנושא ולמדתי שיש 3 דרכי התגוננות מפני sql injection : א. שימוש ב try catch למנוע קריסת האתר והצגת שם בסיס הנתונים, סוגו ושמות הטבלאות ושמות השדות בפני הגולש לאתר במקרה של שגיאה. ב. הקלט שמקליד הגולש צריך לעבור ולידציה רצינית שתמנע ממנו מלהקיש תווים שאינם מספרים או אותיות ובמיוחד תחסום את השימוש ב : ' " ; ג. ההעברה של הקלט לא תעשה ישירות מהtextbox שאליו הגולש הקליד לשאילתת sql אלא דרך parameter שיוכנס לשאילתה. האם יש עוד משהו? עוד טכניקה שאני צריך לדעת בנושא ?

 

[ברק קרב]

אם אתה מעביר לפרמטר אתה לא צריך לחסום שימושים

כל הרעיון של הפרמטר ב asp.net שהוא עושה הכל בשבילך.

 

[חובב טניס]

מספר הערות

לגבי נקודה א - זה דבר שיכול לעזור, אבל בהחלט לא למנוע SQL Injection. כיום כבר יש טכניקות פריצה לאתרים באמצעות SQL Injection גם ללא קבלת הודעת שגיאה עם פרטים טכנים. ממליץ לך לבצע חיפוש בgoogle על blind sql injection. דרך אגב, ניתן להסתיר את ההודעות הטכניות ברמת הIIS. שימוש בtry catch לא נראה לי קשור לנושא. נקודה ב - הדבר הכי חשוב. צריך לבצע בדיקות ולידציה רציניות. צריך להקפיד על data type נכון (אם מצפים למספר, לקבל רק מספר, אם אורך של שדה בטבלה הוא 30 תווים, לא לתת להכניס מעל 30 תווים בממשק משתמש וכד'). לעולם לא לקחת את הuser input ולהשתמש בו כפי שהולקד ללא שום בדיקה. נקודה ג - נקודה נכונה וחשובה, אבל היא לא פותרת את הבעיה. מאד חשוב לכתוב גם את הstored procedure בצורה נכונה. במידה והSP שמפעילים כתוב בצורה גרועה, גם עבודה נכונה עם פרמטרים והפעלה נכונה של הSP לא תעזור. נקודה נוספת שלא רשמת - הרשאות נכונות בבסיס הנתונים. כמות הפעמים, שנתקלתי באפליקציות, שמתחברות לבסיס הנתונים בתור משתמש ששייך לקבוצת הdb_owner, היא גבוה מאד. ברור, שזה נעשה ע"מ לא להיתקל בבעיות הרשאות, אבל האם המשתמשים אמורים לבצע פעולת drop לטבלה? האם הם אמורים להוסיף הרשאות למשתמשים? לכולם ברור שלא, אז למה לתת להם את ההרשאות האלו? במקום לעבוד עם dbo, צריך לבדוק איזה הרשאות משתמש צריך ע"מ שיוכל לעבוד ולתת לו רק את אותם הרשאות.

 

[24sharon]

שימוש בפרמטרים ב.NET פותר חלק ניכר מהבעיות

והנה דוגמא להמחשה.

INSERT INTO [tblPhotoCategory] ([hbCategory], [enCategory]) VALUES (@hbCategory, @enCategory)​

שאילתא רגילה להכנסת נתונים שהייתה יכולה להיות בעייתית. הכנסתי תווים כמו גרש וכמו ; שיכולים להוות בעיה בשאילתא רגילה. וכך הפרופיילר מריץ שאילתא כזו:

exec sp_executesql N'INSERT INTO [tblPhotoCategory] ([hbCategory], [enCategory]) VALUES (@hbCategory, @enCategory)',N'@hbCategory nvarchar(7),@enCategory nvarchar(8)',@hbCategory=N'פלאג''ים',@enCategory=N'fullwho;'​

כמו שניתן לראות הגרש הוכפל וכן אי אפשר לשחק עם שרשורי שאילתות - היות שהם מגיעים כפרמטרים הסתרת הודעות שגיאה מפורטות - שזה חלק חשוב. (בASP NET יש עוד דברים לבדוק בנוסף לתקינות הSQL כמו תווים של HTML וכד', חסימת האפשרות לקריאת עוגיות בצד לקוח, בדיקה מוחלטת של החומר שמתקבל בQUERYSTRINGועוד - אבל זה כבר סטייה מהנושא)

 

[חובב טניס]

אני מסכים ששימוש בפרמטרים פותר חלק ניכר

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

CREATE MySP (@String varchar(1000)) as EXEC (@String)​

בהפעלת הSP, ניתן לשלוח את הפרמטר הבא - drop table users. מאחר ומצפים לסטרינג, והסטרינג עומד בקריטריונים, שהוגדרו לSP (לא ארוך מידי, לא unicode וכד'), הפרמטר יכול לעבור לSP. לא משנה אם אני מפעיל את הSP באמצעות connection או באמצעות command. בכל מקרה התוצאה תהיה זהה, לכן מאד חשוב איך כותבים את הSP. הדוגמא שנתתי אמנם קיצונית, אבל באופן מפתיע היא לקוחה מאפליקציה אמיתית שבאחד ממקומות העבודה הקודמים שלי, רכשו אותה.