سلسله آموزش های تست نفوذ Web Application - قسمت چهارم: حملات SQL Injection یا SQLi


فصل پنجم: حملات SQL Injection

مقدمه

یک حمله تزریق SQL یا SQLi از تزریق پرس و جو(query) های SQL در یک وب اپلیکیشن بهره می برد. انجام حمله موفق SQLi (که سی کوئل آی خوانده می شود) می تواند به مهاجم امکان دسترسی به پایگاه داده پشت یک وب اپلیکیشن و امکان ایجاد تغییرات در آن را بدهد.

بطور کلی، پایگاه های داده در وب اپلیکیشن ها به منظور ذخیره سازی اطلاعات، آمار یا اطلاعات هویتی (Credential) کاربران به کار می روند. به منظور تعامل با این پایگاه های داده، وب اپلیکیشن ها از زبان ساختارمند پرس و جو یا همان SQL استفاده می نمایند. SQL زبانی تفسیرشده و قدرتمند است که می تواند برای دستکاری و استخراج داده از یک پایگاه داده بکار رود.

پرس و جوهای SQL

ساختار عبارات SQLبه طور کلی ساختار عبارات پرس و جوی SQL به صورت زیر است:

مثال:

همچنین امکان استخراج داده های خاص ثابت نیز وجود دارد:

همچنین می توان برای جمع کردن (عمل اتحاد در مجموعه ها) دو نتیجه، از دستور UNION بهره برد:

در صورتی که یک جدول (یا بطور کلی خروجی یک پرس و جو) نتایج تکراری داشته باشد می توان از عملگر DISTINCT برای حذف نتایج تکراری استفاده نمود:

دستور UNION بطور پیشفرض از متد DISTNCT استفاده می کند. در صورتی که مایل به عدم حذف نتایج تکراری باشیم باید از عملگر ALL استفاده نماییم:

و نهایتا کامنت گذاشتن در SQL به یکی از دو صورت زیر انجام می شود:

# (نماد هَشتگ)

-- (دو خط تیره بهمراه یک فاصله)

بطور کلی برای آنکه یک وب اپلیکیشن بتواند با پایگاه داده خود در تعامل باشد، باید بتواند سه عمل زیر را انجام دهد:

  • Connect
  • Submit
  • Retrieve
  • کد PHP زیر نمونه ای از اتصال به یک پایگاه داده MySQL و اجرای یک کوئری را نشان میدهد:

پرس و جوهای آسیب پذیر

مانند آسیب پذیری های XSS، در اینجا نیز با آسیب پذیری طرف هستیم که مرتبط با نحوه پردازش ورودی کاربر است. به طور کلی، هر جا پارامتر مورد جست و جو در URL ظاهر شد، می توانیم نقطه مستعد SQLi را یافته باشیم. به عبارت دیگر، ساختار پرس و جوی آسیب پذیر می تواند مشابه ساختار زیر باشد:

برای اینکه یک گام در تشخیص آسیب پذیری پیش رفته باشیم، می توانیم عبارت روبروی id را به عبارت زیر تغییر دهیم:

‘ OR ‘a’=’a

یعنی پرس و جو را به صورت زیر تغییر دهیم:

که اولین شرط، یک ID تهی را انتخاب می کند اما شرط دوم شرطی همیشه صحیح است و در اصل این پرس و جو به پایگاه داده می گوید که تمامی ایتم های موجود در جدول products را انتخاب نماید. مهاجم با انجام حمله موفق SQLi می تواند فایل سیستم را بخواند، دستورات OS را اجرا کند، Shell نصب نماید و به طور کلی تمامی زیرساخت را در اختیار بگیرد. همچنین در بین تمامی حملات، SQLi اولین دسته حمله ای است که مهاجمین آنرا بررسی می نمایند.

طبقه بندی حملات SQLi

دسته بندی های متعددی برای حملات SQLi مطرح شده اما در این مستند بر حسب سه دسته زیر به بررسی آنها می پردازیم:

  • In-Band SQLi

از همان کانالی برای حمله استفاده می کند که برای تزریق کد SQL استفاده شده است(مانند صفحات تولید شده توسط وب اپلیکیشن ها)

  • Error-based SQLi

مهاجم تلاش می کند تا با ایجاد پیام خطا در DBMS و نمایش آن، از اطلاعات مذبور بهره ببرد.

  • Blind SQLi

وب اپلیکیشنی که در مقابل این حمله آسیب پذیر باشد، نتایج را در خروجی خود نمایش نمی دهد. در نتیجه مهاجم باید متدی مداخله گر (نظیر شرایط true/false) برای پیاده سازی حمله بکارگیرد.

یافتن SQLi

به منظور اجرای SQLi، ابتدا باید یک نقطه تزریق را یافت تا در آنجا بتوان Payload موردنظر را اجرا نموده و بر روی سیستم پرس و جوی پویای هدف مسلط شد. ساده ترین راه یافتن این نقاط درون یک وب اپلیکیشن، جستجو در اپلیکیشن برای یافتن ورودی هایی است که کاراکترهای غیرمجاز داشته و سبب نمایش/بازگرداندن خطا می شوند.

نکته: همه ورودی های یک وب اپلیکیشن برای ساخت پرس و جوهای SQL استفاده نمی شوند.

بطور کلی پارامترهای ورودی از طرق زیر منتقل می شوند:

  • درخواست POST
  • درخواست GET
  • سرآیندها
  • کوکی ها
یک سناریوی ساده

در ادامه، مثالهایی را بررسی می کنیم که در آنها ورودی، مستقیما از URL (با متد GET) گرفته می شود. در مثال زیر، بجای مقدار 1 برای متغیر id، از کاما استفاده می کنیم که این کار باعث ایجاد خطا می شود: