مقابله با حملات SQLi

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

مسئول سایت

تیم امنیت وب و تحقیقات سایبری پارسینگ با هدف اطلاع رسانی، آموزش، مشاوره، ایمن سازی و تحقیقات در حوزه امنیت سایبری در سال 1391 توسط مهندس علی اصغر جعفری لاری تاسیس گردید تا علاوه بر اهدافی همچون بالا بردن آگاهی کاربران عمومی نسبت به امنیت، مشاوره و ایمن سازی وبسایت های داخلی برای دفاع در برابر تهاجمات بیگانگان و ارائه تحقیقات سایبری روشن و شفاف برای تحقیق و توسعه پروژه ها توسط دانش پژوهان، بتواند با کسب رضایت و اعتماد مشتریان خود به عنوان یک تیم برتر در حوزه امنیت سایبری در ایران شناخته شود.

وبگاه: www.parsing.ir پست الکترونیکی این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید

درباره پارسینگ

تیم امنیت وب و تحقیقات سایبری پارسینگ با هدف اطلاع رسانی، آموزش، مشاوره، ایمن سازی و تحقیقات در حوزه امنیت سایبری در سال 1391 توسط مهندس علی اصغر جعفری لاری تاسیس گردید تا علاوه بر اهدافی همچون بالا بردن آگاهی کاربران عمومی نسبت به امنیت، مشاوره و ایمن سازی وبسایت های داخلی برای دفاع در برابر تهاجمات بیگانگان و ارائه تحقیقات سایبری روشن و شفاف برای تحقیق و توسعه پروژه ها توسط دانش پژوهان، بتواند با کسب رضایت و اعتماد مشتریان خود به عنوان یک تیم برتر در حوزه امنیت سایبری در ایران شناخته شود.  

تماس با ما

تهران، اقدسیه، میدان ازگل، کوچه نوبهار، بن بست همیشه بهار، پلاک سوم

info[at]parsing[dot]ir

22196283 21 (98)

9120268477 (98)

پارسینگ را در گوگل محبوب کنید: