حمله های تزریق SQL

SQL (Structured Query Language) که به آن «زبان Query ساختاریافته» نیز گفته می‌شود، زبانی است که برای دستکاری و مدیریت داده ها در پایگاه داده طراحی شده است. از زمان پیدایش، SQL به طور پیوسته راه خود را در بسیاری از پایگاه‌های داده تجاری و منبع باز پیدا کرده است. حمله تزریق SQL (SQLi) نوعی حمله امنیت سایبری است که پایگاه‌های داده را با استفاده از عبارات SQL ساخته‌شده خاص هدف قرار می‌دهد تا سیستم‌ها را برای انجام کارهای غیرمنتظره و ناخواسته فریب دهد.

اقداماتی که یک مهاجم موفق ممکن است بر روی یک هدف در معرض خطر انجام دهد عبارتند از:

• دور زدن احراز هویت
• استخراج/سرقت داده‌ها
• تغییر یا تخریب داده‌ها
• حذف کردن داده ها
• اجرا کردن کدهای دلخواه
• دسترسی کامل به خود سیستم

حمله تزریق SQL چقدر خطرناک است؟

در صورت تکمیل موفقیت آمیز، حمله تزریق SQL این پتانسیل را دارد که به طور باور نکردنی برای هر کسب و کار یا فردی مضر باشد. هنگامی که داده‌های حساس در یک حمله به خطر بیفتند، بازیابی کامل آن می‌تواند دشوار باشد.

پایگاه‌های داده معمولاً برای تزریق از طریق یک برنامه هدف قرار می‌گیرند (مانند یک وب‌سایت، که درخواست ورود کاربر را می‌کند و سپس بر اساس آن ورودی، در پایگاه داده جستجو می‌کند)، اما می‌توانند مستقیماً نیز هدف قرار گیرند. حملات تزریق SQL در لیست 10 خطر امنیتی برنامه برتر OWASP است که شرکت‌ها با آن‌ها دست و پنجه نرم می‌کنند، فهرست شده‌اند.

انواع حملات تزریق SQL

حملات تزریق SQL را می‌توان به روش‌های مختلفی انجام داد. مهاجمان ممکن است رفتار سیستم را قبل از انتخاب بُردار/روش حمله خاص مشاهده کنند.

ورودی پاکسازی نشده

ورودی غیر سالم یک نوع متداول از حمله SQLi است که در آن مهاجم ورودی کاربر را فراهم می‌کند که به درستی برای کاراکترهایی که باید حذف شوند، پاکسازی نشده است، و یا ورودی برای نوع صحیح/مورد انتظار تأیید نشده است.

برای مثال، وب‌سایتی که دارای درگاه پرداخت صورتحساب‌ها می‌باشد، ممکن است شماره حساب کاربر را در یک فرم وب درخواست کند و سپس آن را به پایگاه داده ارسال کند تا اطلاعات حساب مرتبط را جمع‌آوری کند. اگر برنامه وب در حال ساخت یک رشته جستجوی SQL به صورت پویا با شماره حسابی است که کاربر ارائه کرده است، ممکن است چیزی شبیه به این باشد:

مثلاً یک وب‌سایت که برای پرداخت آنلاین استفاده می‌شود، ممکن است شماره حساب کاربر را در یک فرم وب درخواست کند و سپس آن را به پایگاه داده ارسال کند تا اطلاعات حساب مرتبط را جمع‌آوری کند. اگر برنامه وب در حال ساخت یک رشته جستجوی SQL به صورت پویا با شماره حسابی است که کاربر ارائه کرده است، ممکن است چیزی شبیه به این باشد:

”’;” “SELECT * FROM customers WHERE account = ‘“ + userProvidedAccountNumber”

در حالی که این برای کاربرانی که به درستی شماره حساب خود را وارد می‌کنند کار می‌کند، «در» را برای مهاجمان باز می‌گذارد. به عنوان مثال، اگر شخصی تصمیم بگیرد که شماره حساب “‘ یا “1” = “1” ارائه کند، منجر به یک رشته query می‌شود:

1’;”’ = 1“SELECT * FROM customers WHERE account = ‘’ or ‘

با توجه به اینکه “1” = “1” همیشه به TRUE تخمین زده می‌شود، ارسال این عبارت به پایگاه داده منجر به بازگشت داده‌های همه مشتریان به جای یک مشتری می‌شود.

تزریق کور  sql

حمله تزریق کور SQL که به آن تزریق استنتاجی SQL نیز گفته می‌شود، داده‌ها را مستقیماً از پایگاه داده، مورد هدف قرار نمی‌دهد. در عوض، مهاجم سرنخ‌های غیرمستقیم در رفتار را از نزدیک بررسی می‌کند. جزئیات پاسخ‌های HTTP ، صفحات وب خالی برای ورودی کاربر خاص، و مدت زمانی که پایگاه داده به ورودی کاربر خاص پاسخ می‌دهد، همه چیزهایی هستند که بسته به هدف مهاجم می‌توانند سرنخ‌هایی باشند. آن‌ها همچنین می‌توانند به یکی دیگر از راه‌های حمله SQLi اشاره کنند تا مهاجم آن را امتحان کند.

تزریق خارج از باند

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

تزریق مرتبه دوم نوعی حمله تزریق خارج از باند است. در این حالت، مهاجم یک تزریق SQL را ارائه می‌دهد که با رفتار جداگانه‌ای از سیستم پایگاه داده ذخیره و اجرا می‌شود. هنگامی که رفتار سیستم ثانویه رخ می‌دهد (ممکن است چیزی شبیه به یک کار مبتنی بر زمان یا چیزی باشد که توسط سایر مدیران یا کاربران معمولی از پایگاه داده استفاده می‌شود) و تزریق SQL مهاجم اجرا می‌شود، در آن زمان است که «دسترسی» به یک سیستم کنترل مهاجم اتفاق می‌افتد.

مثال تزریق SQL

برای این مثال تزریق SQL، از دو جدول پایگاه داده، Users و Contacts استفاده می‌کنیم. جدول کاربران ممکن است به سادگی دارای سه فیلد باشد: شناسه، نام کاربری و رمز عبور. جدول مخاطبین اطلاعات بیشتری در مورد کاربران دارد. مانند UserID، FirstName، LastName، Address1، Email، شماره کارت اعتباری و کد امنیتی.

جدول کاربران دارای اطلاعاتی است که برای ورود به سیستم استفاده می شود مانند:

1. jsmith,P@$$w0rd
2. sbrown,WinterIsComing!
3. kcharles,Sup3rSecur3Password$

توجه: رمزهای عبور باید همیشه هنگام ذخیره در پایگاه داده هش و سالت شوند و هرگز در متن شفاف نباشند.

هنگامی که شخصی می‌خواهد وارد شود، به صفحه ورود می‌رود و نام کاربری و رمز عبور خود را وارد می‌کند. سپس این اطلاعات به وب سرور ارسال می‌شود، که یک کوئری(پرس‌و‌جوی) SQL ایجاد می‌کند و آن پرس و جو را به سرور پایگاه داده ارسال می‌کند. نمونه ای از ظاهر آن پرس و جو ممکن است این باشد:

Select ID from Users where username=’jsmith’ and password=’P@$$w0rd’

روش کار SQL به این صورت است که برای هر ردیفی که پرس و جو(query) درخواست می‌کند یک مقایسه درست یا نادرست انجام می‌دهد. در مثال ما،  queryمی‎گوید که جدول کاربران را بررسی کنید و مقدار ID را برای هر ردیفی که نام کاربری jsmith و رمز عبور P@$$w0rd است، برگردانید. اغلب، وب سرور می‌بیند که چه چیزی توسط سرور پایگاه داده برگردانده می‌شود و آیا آن یک عدد است. در مورد ما، وب سرور 1 را دریافت می‌کند و به کاربر اجازه می‌دهد صفحه ورود را پشت سر بگذارد (از آن عبور کند).

اما، اگر بخواهیم با این کار در نقش مخرب ظاهر شویم، چه؟ از آنجایی که سرور پایگاه داده آن بررسی درست یا نادرست را انجام می‌دهد، می‌توانیم آن را فریب دهیم و باور کنیم که با موفقیت احراز هویت شده‌ایم. ما می‌توانیم این کار را با افزودن یک OR به رمز عبور انجام دهیم. اگر با ‘x یا 1=1 به عنوان رمز عبور وارد شویم، یک کوئری جدید SQL ایجاد می‌کند که به شکل زیر است:

Select ID from Users where username=’jsmith’ and password=’x’ or 1=1

این برای ما کارکرد خواهد داشت، زیرا در حالی که x رمز عبور jsmith نیست، سرور پایگاه داده شرط دوم را بررسی می‌کند. اگر x رمز عبور jsmith نیست، آیا 1 برابر با 1 است؟ این کار را انجام می‌دهد! شناسه به برنامه بازگردانده می‌شود و کاربر با موفقیت احراز هویت می‌شود.

اگر یک صفحه وب قادر به نمایش داده‌ها باشد، ممکن است امکان چاپ داده‌های اضافی روی صفحه نیز وجود داشته باشد. برای دسترسی به داده‌ها، می‌توانیم دو درخواست SQL را با هم زنجیر کنیم. علاوه بر «1=1or» خود، می‌توانیم عبارت دوم مانند UNION SELECT LastName، شماره کارت اعتباری، کد امنیتی مخاطبین را به آن اضافه کنیم. بندهای اضافی مانند این ممکن است کار اضافی را بخواهند، اما دسترسی به داده‌ها هدف نهایی حمله تزریق SQL است.

روش دیگری که می‌توانیم برای تزریق SQL کور استفاده کنیم، روشی است که هیچ داده‌ای به صفحه نمایش ارسال نمی‌شود، تزریق سرنخ‌های دیگر است. مشابه شرط “or 1=1” ما، می‌توانیم به سرور دستورِ خوابیدن بدهیم. می‌توانیم اضافه کنیم: « or sleep (10) » و این همان چیزی است که به نظر می‌رسد. به سرور پایگاه داده می‌گوید 10 ثانیه چرت بزند و همه پاسخ‌ها به تأخیر می‌افتد.

چگونه از حملات تزریق SQL جلوگیری کنیم؟

پیشنهادات زیر می‌تواند به جلوگیری از موفقیت آمیز بودن حمله تزریق SQL کمک کند:

از SQL پویا استفاده نکنید

• از قرار دادن ورودی‌های ارائه شده توسط کاربر به طور مستقیم در دستورات SQL خودداری کنید.
• عبارات آماده شده و کوئری‌های پارامتری را ترجیح دهید، که بسیار ایمن‌تر هستند.
• رویه‌های ذخیره شده نیز معمولاً ایمن‌تر از SQL پویا هستند.

ورودی‌های ارائه شده توسط کاربر را پاکسازی کنید

• به درستی از آن شخصیت‌هایی که باید از آن‌ها فرار کنید دور شوید.
• بررسی کنید که نوع داده ارسالی با نوع مورد انتظار مطابقت دارد یا خیر.

داده های حساس را در متن ساده رها نکنید

• رمزگذاری داده‌های خصوصی/محرمانه‌ای که در پایگاه داده ذخیره می‌شوند.
• هش های رمزگذاری شده را آماده سازی کنید.
• این همچنین سطح دیگری از محافظت را فقط در صورتی که مهاجم با موفقیت داده‌های حساس را استخراج کند، فراهم می‌کند.

محدود کردن مجوزها و امتیازات پایگاه داده

• قابلیت‌های کاربر پایگاه داده را روی حداقل مورد نیاز تنظیم کنید.
• این امر کاری را که یک مهاجم می‌تواند در صورت دسترسی به مجوز انجام دهد محدود می‌کند.

از نمایش مستقیم خطاهای پایگاه داده به کاربر خودداری کنید

• مهاجمان می‌توانند از این پیام‌های خطا برای به دست آوردن اطلاعات در مورد پایگاه داده استفاده کنند.پ

 فایروال برنامه‌های کاربردی وب (WAF) برای برنامه‌های کاربردی وب که به پایگاه‌های داده دسترسی دارند استفاده کنید

• این امر از برنامه‌های تحت وب محافظت می‌کند.
• می‌تواند به شناسایی تلاش‌های تزریق SQL کمک کند.
• بر اساس راه‌اندازی، می‌تواند به جلوگیری از تلاش‌های تزریق SQL به برنامه (و بنابراین، پایگاه داده) کمک کند.

از یک راه حل تست امنیت برنامه‌های کاربردی وب برای آزمایش معمول برنامه‌های وب که با پایگاه داده‌ها در تعامل هستند استفاده کنید

• انجام این کار می‌تواند به یافتن باگ‌ها یا رگرسیون‌های جدیدی که می‌توانند به تزریق SQL اجازه دهند کمک کند.

پایگاه داده ها را با آخرین پَچ های موجود به روز نگه دارید

• این مانع از سوء استفاده مهاجمان از ضعف ها/اشکال‌های شناخته شده موجود در نسخه‌های قدیمی می‌شود.

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

پیشنهاد ما:حمله BEC چیست و چگونه می ‌‌توان از آن جلوگیری کرد؟