מניעת הזרקת SQL בשרתי SQL Server

הקדמה ¶

הזרקת SQL (SQL injection) מתרחשת כאשר נתונים לא מהימנים הופכים לחלק מתחביר ה-SQL של שאילתה. היא יכולה לחשוף או לשנות את תוכן מסד הנתונים, ובהתאם לתכונות ולהרשאות של מסד הנתונים, להשפיע על קבצים או לבצע פקודות של מערכת ההפעלה. עיין במדריך OWASP Web Security Testing Guide עבור מודל התקיפה והנחיות לבדיקות.

השתמש בשאילתות עם פרמטרים עבור ערכי נתונים, בחירות קבועות בבעלות יישום עבור מבנה שאילתה דינמי, והרשאות מינימליות כדי להגביל נזק. בקרות אלה חלות ללא קשר אם הנתונים מגיעים מבקשת ⁦HTTP⁩, שירות אחר או נתונים שנשמרו בעבר. לסוגי הזרקה אחרים, ראה ⁦Injection Prevention Cheat Sheet⁩.

⁦Primary Defenses⁩ ¶

⁦Defense Option⁩ 1: ⁦Prepared Statements⁩ (עם ⁦Parameterized Queries⁩) ¶

הגדר את מבנה ה-SQL בנפרד מערכי הנתונים שלו, ולאחר מכן בצע binding לערכים הללו דרך ה-API של מסד הנתונים. הצהרות מוכנות (Prepared statements) מתייחסות לערכים מקושרים כנתונים ולא כתחביר SQL. שרשור של ערכים לא מהימנים לתוך השאילתה לפני הכנתה מנטרל הגנה זו.

דוגמה זו ב-Java מניחה קיום של חיבור פעיל וערך customerName שסופק על ידי האפליקציה. היא מציגה את השימוש ב-parameter binding; ניקוי משאבים וטיפול בשגיאות הושמטו.

⁦String query = "SELECT account_balance FROM user_data WHERE user_name = ?" ; PreparedStatement statement = connection . prepareStatement ( query ); statement . setString ( 1 , customerName ); ResultSet results = statement . executeQuery ();⁩

קלט כגון tom' או '1'='1 יטופל כשם משתמש מילולי לצורך השוואה, ולא כתנאי שהוסף לשאילתה. ה-parameter binding מונע מערך זה לשנות את תחביר ה-SQL; הוא אינו קובע האם למשתמש הקורא יש הרשאת גישה לחשבון התואם.

בעת שימוש במסגרות עבודה (frameworks) של מיפוי יחסי-אובייקטיבי (ORM), בצע binding לערכים לא מהימנים בתוך מחרוזות השאילתה במקום לשרשר אותם; שאילתות Hibernate עלולות להיות פגיעות להזרקה. לדוגמאות ספציפיות לשפות ומסגרות עבודה, ראה את ה-Query Parameterization Cheat Sheet.

⁦Stored Procedures⁩ ¶

נהלים מאוחסנים (Stored Procedures) שומרים את קוד ה-SQL בתוך מסד הנתונים, אך אינם חסינים אוטומטית מפני הזרקה. בצע binding לארגומנטים בעת קריאה לנוהל; עיין בתיעוד ה-JDBC של Oracle עבור ה-API המתאים.

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

לדוגמה, התיעוד של PostgreSQL מציג את השימוש ב-EXECUTE ... USING עבור binding של ערכים ואת format('%I', ...) עבור ציטוט מזהים. בחר מזהים מתוך מיפויים קבועים המנוהלים על ידי האפליקציה. ציטוט מזהים מגן על תחביר ה-SQL, אך אינו מגביל לאילו טבלאות היישום יכול לגשת.

⁦Allow-List Input Validation⁩ ¶

סמני פרמטרים מייצגים ערכי נתונים בלבד, ולא שמות טבלאות, שמות עמודות או מילות מפתח ב-SQL כגון ASC ו-DESC; עיין במגבלות של סמני פרמטרים ב-PDO. שמור את הבחירות המבניות הללו קבועות בקוד ככל האפשר. כאשר משתמשים נדרשים לבחור ביניהן, מפה את הבחירה שלהם לקבוצה קטנה של אסימונים (tokens) המורשים עבור שאילתה זו ודחה בחירות לא ידועות. לדוגמה, מפה כיוון מיון מבוקש לערכים המילוליים ASC או DESC, במקום לשרשר את הטקסט שסופק.

מיפוי זה משלים את ה-parameter binding. המשך לבצע binding לכל ערכי הנתונים, גם כאשר הם עוברים בדיקות סוג, אורך או פורמט. אימות (Validation) של ערך אינו הופך אותו לבטוח לשרשור לתוך SQL. עיין ב-Input Validation Cheat Sheet לקבלת הנחיות אימות.

⁦Escaping All Dynamic Inputs⁩ (⁦STRONGLY⁩ ⁦DISCOURAGED⁩) ¶

אל תשתמש בבריחה (escaping) ידנית כתחליף ל-parameter binding. ה-escaping תלוי בניב ה-SQL ובקונפיגורציה: לדוגמה, מצב NO_BACKSLASH_ESCAPES ב-MySQL מבטל את ה-escaping באמצעות לוכסן אחורי. החלף בניית שאילתות שמסתמכת על escaping בשימוש בשאילתות עם פרמטרים.

התקשות ¶

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

⁦Least Privilege⁩ ¶

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

ודא שחשבונות שצריכים רק גישת קריאה מקבלים גישת קריאה רק לטבלאות שהם צריכים גישה אליהן. ⁦DO⁩ ⁦NOT⁩ ⁦ASSIGN⁩ ⁦DBA⁩ ⁦OR⁩ ⁦ADMIN⁩ ⁦TYPE⁩ ⁦ACCESS⁩ ⁦TO⁩ ⁦YOUR⁩ ⁦APPLICATION⁩ ⁦ACCOUNTS⁩. אנחנו מבינים שזה קל, והכל פשוט "עובד" כשאתה עושה את זה ככה, אבל זה מאוד מסוכן.

צמצום הרשאות אפליקציה ומערכת הפעלה ¶

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

בנוסף, עליך לצמצם את ההרשאות של חשבון מערכת ההפעלה שתחתיו פועל ה-DBMS. אל תפעיל את ה-DBMS כ-root או כ-system! רוב מערכות ה-DBMS מגיעות כברירת מחדל עם הרשאות מערכת רחבות מאוד. לדוגמה, MySQL רץ כ-system על Windows כברירת מחדל! שנה את חשבון מערכת ההפעלה של ה-DBMS לחשבון מתאים יותר, בעל הרשאות מוגבלות.

פירוט עיקרון ההרשאה המינימלית בעת פיתוח ¶

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

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

⁦Least Admin Privileges For Multiple⁩ ⁦DBs⁩ ¶

על המעצבים של יישומי אינטרנט להימנע משימוש באותו חשבון ⁦owner/admin⁩ ביישומי האינטרנט כדי להתחבר למסד הנתונים. יש להשתמש במשתמשים שונים ⁦DB⁩ עבור יישומי אינטרנט שונים.

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

כדוגמה, דף כניסה דורש גישת קריאה לשדות שם המשתמש והסיסמה של טבלה, אך אין גישת כתיבה מכל סוג שהוא (ללא הוספה, עדכון או מחיקה). עם זאת, דף ההרשמה בהחלט דורש הוספה של הרשאות לטבלה זו; ניתן לאכוף הגבלה זו רק אם יישומי אינטרנט אלה משתמשים במשתמשי ⁦DB⁩ שונים כדי להתחבר למסד הנתונים.

שיפור עיקרון ההרשאה המינימלית בעזרת תצוגות (Views) ב-SQL ¶

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

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

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

זיהוי ¶

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

השתמש במבחני הזרקת ה-SQL של מדריך ה-OWASP Web Security Testing Guide לצורך בדיקות ידניות ואוטומטיות, כולל טכניקות של blind injection ו-out-of-band.

הפניות ¶