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

محققان انواع زیادی از تکنیک ها را برای حل مساله تزریق 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 را شناسایی نمایند.