بانکهای اطلاعاتی معمولا قلب یک وب سایت یا یک برنامه Web based و یا Web Enabled را تشکیل میدهند. زیرا اطلاعاتی که باید در سایت نمایش داده شوند در آنها ذخیره میگردد. بر اساس مدلهای مختلف برنامه سازی، ترکیبی از یک بانک اطلاعاتی و یک زبان اسکریپت یا کد نویسی و احتمالا چند لایه دیگر میتوان برنامه ای نوشت که مورد رضایت مشتری قرارگیرد و اورا قانع به پرداخت هزینه های برنامه نویسی نمود.
گاه با اینکه تمام جوانب برنامه نویسی را رعایت کرده ایم ممکن است متوجه وجود برخی حفره ها و یا خطاها در برنامه های خود شویم. در صورتی که این حفره ها به دلیل اشکالات موجود در ابزارهای استفاده شده در برنامه ما، مانند بانکهای اطلاعاتی باشند، میتوان به نصب SERVICE PACK ها و یا ارتقاء به نگارش جدید این برنامه ها مشکل را حل نمود، اما در اکثر موارد اشکال و حفره های موجود در یک برنامه وبی به اشکالات مربوط به “تزریق کدهای SQL” یا همان SQL Injection مربوط میشود….
SQL Injection به چه کاری میگویند؟!
همان طور که میدانید زبان SQL شامل دستوراتی است که انجام عملیات بر روی داده های یک بانک اطلاعاتی را فراهم مینماید. هر عملیات (Query) بر روی بانک اطلاعاتی میتواند شامل چندین دستور (Command) باشد. معمول ترین این دستورات عبارتند از: Select, Insert, Update و Delete.
در صورتی که فردی بتواند بصورت غیر مجاز بر روی بانک اطلاعاتی ما با استفاده از این دستورات به اطلاعاتی دست پیدا کند یا اطلاعاتی وارد سایت نماید یا آنها را تغییر داده و یا احتمالا حذف نماید و این عمل را با استفاده از ضعف ما در تفکیک مقادیر ورودی های کاربر و دستورات SQL انجام دهد، اصطلاحا به این روش غیر مجاز اجرای ستورات SQL Injection Attack میگویند.
مثالی از SQL Injection Attacks
مثالها و ضعف های مختلفی را میتوان برای یک SQL Injection Attack بیان نمود، اما در اینجا به یک نمونه ساده از نحوه عبور از یک فرم مخصوص اعتبار سنجی کاربران که به خوبی طراحی نشده آورده میشود.
معمولا برای ورود به یک سایت از طریق یک فرم کلمه عبور و نام کاربری خواسته شده و مقادیر وارد شده در صفحه دیگری ارزیابی شده و در صورت صحت اعتبار، کاربر به صفحه اصلی انتقال داده میشود. صفحه ورود اعتبار کدی مانند مثال زیر دارد:
اطلاعات فرم بالا پس از Submit به صفحه Login.asp ارسال شده و با کدی مانند آنچه در زیر آمده است مورد ارزیابی قرار میگیرد:
<% dim userName, password, query dim conn, rS userName = Request.Form(”userName”) password = Request.Form(”password”) set conn = server.createObject(”ADODB.Connection”) set rs = server.createObject(”ADODB.Recordset”) query = “select * from users where userName=’” & userName & “‘ and userPass=’” & password & “‘” conn.Open “Provider=SQLOLEDB; Data Source=(local); Initial Catalog=myDB; User Id=sa; Password=” rs.activeConnection = conn rs.open query if not rs.eof then response.write “Logged In” else response.write “Bad Credentials” end if %>
در مثال بالا در صورتی که Username و Password وارد شده حداقل یک بار در بانک اطلاعاتی وجود داشته باشند، کاربر جمله “Logged In” و در غیر این صورت عبارت “Bad Credentials” را مشاهده خواهد نمود.
حال فرض کنید کاربر بجای وارد نمودن Username و Password خود عبارتهای زیر را تایپ نماید:
Username: ‘ or True – Password: [Null]
در اینصورت دستور اجرا شده SQL ما بر روی بانک اطلاعاتی بصورت زیر خواهد بود:
select * from users where userName=” or True -– ‘ and userPass=”
همان طور که ملاحظه میشود در صورت اجرای این کد بر روی بانک اطلاعاتی، همیشه کاربر قادر به ورود به سایت بوده و جمله “Logged In” را مشاهده مینماید! ماجرا همیشه به این سادگی نیست، کاربران غیر مجاز نه تنها از طریق فرمها، بلکه از طریق تغییر Query String های صفحات وبی و یا مقداردهی بهCookie ها نیز قادر به ارسال دستورات مخرب SQL به بانکهای اطلاعاتی میباشند! و گاه میتوانند اطلاعات ما را کاملا حذف نمایند، تغییر دهند، دیتای جدید وارد کنند و یا اطلاعات ما را مشاهده و دریافت نمایند.
بنابر این: همواره مراقب اجرای کدهای مخرب که از طریق کاربر به عنوان اطلاعات معمولی به سیستم تزریق میگردند باشید!
برخی پیشنهادات برای جلوگیری و مقابله با SQL Injection Attacks:
اگر ما به عنوان برنامه نویس وب، برنامه های خود را با دقت بیشتری بنویسیم، در اکثر مواقع میتوانیم جلوی حملات SQL Injection را بگیریم، معمولی ترین راه های مقابله با این نوع حملات میتواند شامل موارد زیر باشد:
۱- محدود کردن سطح دسترسی کاربری که با آن اطلاعات وب را برای کاربر از بانک اطلاعاتی استخراج مینماید، بدین منظور بهتر است به چنین نام کاربری، تنها سطح دسترسی SELECT و INSERT برای جداولی که به چنین سطح اجرای دستوراتی نیاز دارند داده شود.
۲- با استفاده از دستور Replace مقادیر مربوط به کوتیشن ‘ را پیش از ارسال مقادیر دریافت شده از طرف کاربر بر روی سرور، از جملات مربوطه حذف نماییم.
۳- کلمات کلیدی و معنادار برای SQL مانند: Drop, Delete, Update و – را از ورودی های دریافت شده از کاربر حذف نماییم.
۴- طول پارامتر ورودی توسط کاربر را محدود نماییم.
كد نویسی دفاعی
علت اصلی آسیب پذیریهای تزریق 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، مدل به طور مستقل توسط برنامه نویس مشخص میشود. هر دو روش از یك كلید محرمانه برای محدود كردن ورودی كاربر در طول تجزیه توسط چك كننده زمان اجرا استفاده میكنند، بنابراین امنیت روش به این بستگی دارد كه مهاجمان قادر نباشند كلید را كشف كنند. علاوه بر این، استفاده از این دو روش نیازمند این است كه برنامه نویس كد را دوباره نویسی كند تا از كتابخانه واسط استفاده نماید، یا اینكه به طور دستی نشانه های خاص را به كد اضافه نماید.
همچنین استفاده از سیستمهای فیلترینگ پروكسی كه قوانین اعتبار سنجی ورودیها را بر روی داده های ورودی به یك برنامه وب اعمال میكنند
توجه کپی برداری بدون ذکر منبع ممنوع میباشد
دانلود قالب هک