تزريق SQL (مقابله با حملات)

IRCAR201006066
محققان انواع زيادي از تكنيك­ها را براي حل مساله تزريق SQL ارائه كرده اند. اين تكنيك­ها از روش­هاي برنامه نويسي تا چارچوب­هاي كاملا خودكار براي تشخيص و جلوگيري از حملات تزريق SQL را شامل مي­شوند. در اين بخش ما به مطالعه اين تكنيك­ها خواهيم پرداخت و مزايا و معايب هر يك را بررسي خواهيم كرد.

كد نويسي دفاعي
علت اصلي آسيب پذيري­هاي تزريق SQL، عدم اعتبار سنجي ورودي­هاست. بنابراين، راه حل اصلي براي حذف اين آسيب پذيري­ها، به كار گيري راهكارهاي برنامه نويسي مناسب و دفاعي است. در اينجا به تعدادي از اين راهكارها مي­پردازيم:
بررسي نوع ورودي:
حملات تزريق SQL به وسيله تزريق دستورات به يك رشته يا يك پارامتر عددي انجام مي­شوند. حتي بررسي ساده اين ورودي­ها مي­تواند از بسياري حملات جلوگيري نمايد. براي مثال، در حالتي كه ورودي از نوع عددي باشد، برنامه نويس مي­تواند به سادگي هر ورودي را كه شامل كاراكتري به جز رقم باشد رد كند. بسياري از برنامه نويسان انجام اين نوع بررسي­ها را به صورت تصادفي از قلم مي اندازند. چرا كه ورودي كاربر صرف­نظر از محتويات يا هدف آن، تقريبا هميشه به شكل يك رشته است.
رمزگذاري ورودي­ها:
تزريق به يك پارامتر رشته اي اغلب از طريق استفاده از متاكاراكترها انجام مي­شود. اين كاراكترها داراي معناي خاصي در زبان برنامه نويسي هستند و باعث مي­شوند تجزيه گر SQL، ورودي كاربر را به عنوان مجوز (token) SQL در نظر بگيرد. در حالي­كه جلوگيري از استفاده از اين متاكاراكترها ممكن است، انجام اين كار باعث مي­شود كه كاربري كه قصد خرابكاري ندارد، در وارد كردن ورودي­هاي مجاز حاوي اين كاراكترها نيز دچار مشكل گردد. بنابراين راه حل بهتر اين است كه از توابعي استفاده نماييم كه يك رشته را به صورتي رمزگذاري مي­كنند كه تمامي متاكاراكترها به طور خاص رمز شده و توسط پايگاه داده به عنوان كاركترهاي معمولي تفسير گردند.

Positive Pattern Matching:
برنامه نويسان بايد روتين­هاي تاييد اعتبار ورودي را كه ورودي «خوب» را در مقابل ورودي «بد» تشخيص مي­دهند و ورودي­هاي معتبر را شناسايي مي­كنند، به كار گيرند. اين روش معمولا «تاييد اعتبار مثبت» ناميده مي­شود. در مقابل، «تاييد اعتبار منفي» به دنبال ورودي­هايي منطبق بر الگوهاي ممنوع يا token هاي SQL مي­گردد. برنامه نويسان قادر نيستند تمامي انواع حملاتي را كه عليه برنامه آنان انجام مي­شود در نظر بگيرند، اما بايد قادر باشند تمامي انواع ورودي­هاي معتبر را مشخص كنند. بنابراين «تاييد اعتبار مثبت» روش امن تري براي بررسي ورودي­ها است.

شناسايي تمامي منابع ورودي:
برنامه نويسان بايد تمامي ورودي­هاي برنامه خود را بررسي نمايند. منابع مختلفي براي ورودي­هاي يك برنامه وجود دارد. اگر اين ورودي­ها براي ساختن يك پرس و جو مورد استفاده قرار گيرند، اين منابع ورودي مي­توانند راهي براي يك مهاجم باشند تا حمله تزريق SQL خود را مطرح كند. بنابراين تمامي منابع ورودي بايد بررسي گردند.
با اينكه كد نويسي دفاعي همچنان بهترين روش براي جلوگيري از آسيب پذيري­هاي تزريق SQL است، اما اين برنامه ها در عمل همچنان مشكل دارند. كد نويسي دفاعي مستعد خطاهاي انساني است و به اندازه تكنيك­هاي خودكار، كامل و بي نقص نيست. در حاليكه اغلب برنامه نويسان سعي مي­كنند كد امني را بنويسند، اعمال كدهاي دفاعي به طور كامل و صحيح به تمامي منابع ورودي بسيار سخت است. در حقيقت، بسياري از آسيب پذيري­هاي تزريق SQL كشف شده در برنامه هاي واقعي، به خاطر خطاي انساني رخ داده اند. يعني برنامه نويسان فراموش كرده اند بررسي­هايي را انجام دهند و يا اينكه اعتبار سنجي ورودي را به اندازه كافي انجام نداده اند. به عبارت ديگر، در اين برنامه ها، برنامه نويسان سعي كرده اند حملات تزريق SQL را تشخيص داده و از آنها جلوگيري نمايند، اما موفق نشده اند آن را به طور كامل و دقيق انجام دهند. اين مثال­ها شواهد بيشتري از مشكلات مربوط به استفاده برنامه نويسان از كد نويسي دفاعي را ارائه مي­دهد.
علاوه بر اين، روش­هاي مبتني بر كد نويسي دفاعي توسط برخي توصيه هاي كدنويسي كه در ظاهر راهكارهاي جلوگيري از حمله هستند، تضعيف مي­شوند. ما دو توصيه و راهكار معروف را كه در حقيقت مناسب نيستند، مورد بحث قرار مي­دهيم. نخست، راهكارهايي هستند كه ورودي­هاي كاربر را در مورد كلمات كليدي SQL مانند FROM، WHERE، و SELECT، و نيز اپراتورهاي SQL مانند single quote يا اپراتور توضيحات بررسي مي­كنند. توضيحي كه پشت اين راهكار وجود دارد اين است كه وجود چنين كلمات كليدي و اپراتورهايي ممكن است نشان دهنده تلاشي براي حمله تزريق SQL باشد. اين روش منجر به اين مي­شود كه در موارد زيادي، به اشتباه تشخيص حمله تزريق SQL داده شود، در حاليكه در حقيقت حمله اي رخ نداده است. به عبارت ديگر نرخ false positive اين روش بالاست. چرا كه در بسياري از برنامه ها، كلمات كليدي SQL مي­توانند بخشي از ورودي متني معمولي باشند، و اپراتورهاي SQL مي­توانند براي نشان دادن فرمول­ها يا حتي اسامي به كار روند (مانند O’Brian). دومين راهكار نامناسب كه معمولا توصيه مي­شود، اين است كه از پردازه هاي ذخيره شده يا دستورات آماده براي جلوگيري از حملات تزريق SQL استفاده شود. متاسفانه خود پردازه هاي ذخيره شده و دستورات آماده نيز مي­توانند در برابر حملات تزريق SQL آسيب پذير باشند. مگر اينكه برنامه نويسان به طور جدي راهكارهاي كد نويسي دفاعي را اعمال نمايند.

تكنيك­هاي تشخيص و جلوگيري
محققان تكنيك­ها و ابزارهاي متنوعي را براي كمك به برنامه نويسان و جبران كمبودهاي كدنويسي دفاعي، ارائه كرده اند.

تست جعبه سياه:
«Waves»، يك تكنيك جعبه سياه براي تست برنامه هاي وب در مورد آسيب پذيري­هاي تزريق SQL است. اين تكنيك با استفاده از يك Web crawler، تمامي نقاط يك برنامه وب را كه مي­تواند براي تزريق SQL مورد استفاده قرار گيرد، معرفي مي­كند. سپس بر اساس فهرستي از الگوها و تكنيك­هاي حمله، حملاتي را كه اين نقاط را هدف قرار مي­دهند طراحي مي­كند. سپس Waves پاسخ برنامه را به اين حملات بررسي كرده و با استفاده از تكنيك­هاي يادگيري ماشين، روش شناسي حمله خود را بهبود مي­بخشد. اين تكنيك با استفاده از روش­هاي يادگيري ماشين براي هدايت تست خود، بر اغلب تكنيك­هاي تست نفوذ پيشي گرفته است. البته مانند اغلب تكنيك­هاي جعبه سياه و تست نفوذ، اين روش نيز كامل نبوده و تضميني ارائه نمي­كند.

بررسي كننده هاي كد استاتيك:
JDBC-Checker، تكنيكي است كه نوع تصحيح پرس و جوهاي SQL توليد شده به صورت پويا را، به شكل استاتيك بررسي مي­كند. اين تكنيك با هدف تشخيص و جلوگيري از حملات معمول SQL طراحي نشده است، ولي مي­تواند براي جلوگيري از حملاتي كه از امتياز عدم تطابق انواع بهره مي­گيرند، در يك رشته پرس و جويي كه به صورت پويا توليد شده است، مورد استفاده قرار گيرد. JDBC-Checker قادر است يكي از علت­هاي اصلي آسيب پذيري­هاي حملات تزريق SQL، يعني بررسي نامناسب نوع ورودي را تشخيص دهد. اما اين تكنيك قادر نيست انواع معمول­تر حملات تزريق SQL را شناسايي نمايد، چرا كه اغلب اين حملات از پرس و جوهايي تشكيل شده اند كه از نظر نوع و قواعد دستوري صحيح هستند.
روش ديگري نيز ارائه شده است كه در آن، با استفاده از تحليل استاتيك تركيب شده با استدلال خودكار، بررسي مي­شود كه پرس و جوهاي SQL توليد شده در لايه Application نمي­توانند شامل يك tautology باشند. اشكال اوليه اين تكنيك اين است كه حوزه آن، به تشخيص و جلوگيري از tautology ها محدود است و نمي­تواند انواع ديگر حمله را تشخيص دهد.

تحليل تركيبي استاتيك و پويا
AMNESIA يك تكنيك مبتني بر مدل است كه تحليل استاتيك و نظارت زمان اجرا را تركيب مي­كند. در فاز استاتيك اين تكنيك، از تحليل استاتيك براي ساختن مدل­هايي از انواع مختلف پرس و جوهايي كه يك برنامه به طور طبيعي مي­تواند در هر نقطه دسترسي به پايگاه داده توليد كند، استفاده مي­شود. در فاز پويا، اين تكنيك تمامي پرس و جوها را پيش از ارسال شدن به پايگاه داده نگه داشته، و هر پرس و جو را در مورد مدل­هايي كه به طور استاتيك ساخته شده اند، بررسي مي­كند. پرس و جوهايي كه مدل را نقض مي­كنند، به عنوان حملات تزريق SQL شناسايي شده و از اجراي آنها در پايگاه داده جلوگيري مي­شود. ارزيابي نويسندگان اين تكنيك نشان داده است كه AMNESIA در مقابل حملات تزريق SQL به خوبي عمل مي­كند. محدوديت اوليه اين تكنيك اين است كه موفقيت آن، به دقت تحليل استاتيك براي ساختن مدل­هاي پرس و جو بستگي دارد. انواع مشخصي از ايجاد ابهام در كد، يا تكنيك­هاي توليد پرس و جو، مي­توانند باعث كم دقت شدن اين گام گردند و در نتيجه، منجر به ايجاد خطاهاي false positive و نيز false negative شوند.
به طور مشابه، دو روش SQLGuard و SQLCheck نيز، پرس و جوها را در زمان اجرا مشاهده كرده و تطابق آنها را با يك مدل از پرس و جوهاي مورد انتظار بررسي مي­نمايند. در اين روش­ها، مدل به شكل يك قاعده دستوري بيان مي­شود كه فقط پرس و جوهاي معتبر را قبول مي­كند. در SQLGuard، مدل در زمان اجرا با امتحان كردن ساختار پرس و جو قبل و بعد از اضافه كردن ورودي كاربر استنباط مي­گردد. در SQLCheck، مدل به طور مستقل توسط برنامه نويس مشخص مي­شود. هر دو روش از يك كليد محرمانه براي محدود كردن ورودي كاربر در طول تجزيه توسط چك كننده زمان اجرا استفاده مي­كنند، بنابراين امنيت روش به اين بستگي دارد كه مهاجمان قادر نباشند كليد را كشف كنند. علاوه بر اين، استفاده از اين دو روش نيازمند اين است كه برنامه نويس كد را دوباره نويسي كند تا از كتابخانه واسط استفاده نمايد، يا اينكه به طور دستي نشانه هاي خاص را به كد اضافه نمايد.
همچنين استفاده از سيستم­هاي فيلترينگ پروكسي كه قوانين اعتبار سنجي ورودي­ها را بر روي داده هاي ورودي به يك برنامه وب اعمال مي­كنند از ديگر راه­هاي جلوگيري از حملات تزريق SQL است. برخي سيستم­هاي تشخيص نفوذ (IDS) نيز مي­توانند حملات تزريق SQL را شناسايي نمايند.