SQL Injection چیست؟

SQL Injection چیست؟

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

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

این نوع حمله مستقل از فناوری به کار رفته در اپلیکیشن عمل میکنه و به همین دلیل، این تکنیک حمله خیلی رایجه.

چطور مهاجم ها از SQL Injection سوء استفاده میکنن؟

SQL Injection یه مشکل جدی موقع توسعه برنامه های تحت وبه. این حمله زمانی اتفاق میفته که اپلیکیشن ورودی مخرب کاربر رو قبول میکنه و ازش به عنوان بخشی از یه دستور SQL برای پرس و جو از پایگاه داده استفاده میکنه.

مهاجم میتونه کاراکترهای کنترلی و کلمات کلیدی دستوری SQL رو (مثل: تک کوتیشن '، دابل کوتیشن "، علامت مساوی =، یا کامنت -- و غیره) تزریق کنه تا ساختار کوئری رو تغییر بده. با استفاده از این کاراکترهای کنترلی و دستورات رایج SQL مثل SELECT, FROM, DELETE و … میشه به داده های موجود توی پایگاه داده دسترسی پیدا کرد یا اون ها رو بازیابی کرد.

برای موفقیت این حمله، لازمه که اپلیکیشن وب کد مخرب مهاجم رو توی یه دستور SQL وارد کنه. این کد مخرب معمولا از یه منبع غیرقابل اعتماد میاد. البته گاهی اوقات هم ممکنه پایگاه داده های داخلی سیستم منبع این داده های مخرب باشن.

وقتی دستورات SQL مخرب روی پایگاه داده اجرا میشن، مهاجم میتونه اون پایگاه داده رو تغییر بده یا بهش دسترسی پیدا کنه. این بستگی داره به این که مهاجم چطور داده های مخرب رو طراحی کرده باشه.

بیاید یک مثال از حمله SQL رو با جزئیات بیشتری بررسی کنیم

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

توی این پایگاه داده، یک جدول به نام “user” وجود داره که شامل ستون هایی برای name و password هست

بیاید یه سناریو رو بررسی کنیم که توش کاربر قصد داره به یه اپلیکیشن لاگین کنه. این کاربر از “admin” به عنوان نام کاربری و “xDK9&GoP1” به عنوان رمز عبور استفاده میکنه. این اطلاعات کاملا معتبر هستن.

SELECT name FROM user WHERE name=’admin’ AND passwd=’xDK9&GoP1′

این کوئری روی پایگاه داده اجرا میشه و به دلیل معتبر بودن اطلاعات، کاربر با موفقیت احراز هویت میشه.

حالا چطور یه مهاجم میتونه از این ساختار سوء استفاده کنه؟

فرض کنید یه مهاجم قصد داره به اپلیکیشن نفوذ کنه و برای رمز عبور به جای مقدار واقعی از یه بار مخرب مثل “password’ OR ‘a’=’a” استفاده میکنه.

در این صورت، کوئری SQL به این شکل تغییر پیدا میکنه:

SELECT name FROM user WHERE name=’admin’ AND passwd=’password’ OR ‘a’=’a’

وقتی این کوئری اجرا میشه، شرط ‘a’=’a’ همیشه درست برمیگرده. این یعنی مهاجم میتونه احراز هویت رو دور بزنه و بدون داشتن اطلاعات معتبر وارد سیستم بشه.

حمله موفق چی در اختیار مهاجم قرار میده؟

1. دسترسی غیرمجاز به اپلیکیشن
   مهاجم میتونه با موفقیت سیستم احراز هویت رو دور بزنه و به طور نامشروع وارد اپلیکیشن بشه
2. افشای اطلاعات
   این حمله میتونه منجر به نشت کامل اطلاعات از پایگاه داده بشه
3. از بین رفتن دسترسی به داده ها
   مهاجم میتونه رکوردها رو از پایگاه داده حذف کنه و باعث از بین رفتن اطلاعات بشه
4. به خطر افتادن یکپارچگی داده ها
   چون دستورات SQL میتونن برای تغییر یا اضافه کردن رکوردها هم استفاده بشن، مهاجم میتونه با استفاده از SQL Injection داده های موجود توی پایگاه داده رو تغییر بده یا اطلاعات جدیدی وارد کنه که باعث از بین رفتن یکپارچگی اطلاعات میشه

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

یکی از موثرترین روش ها برای جلوگیری از حملات SQL Injection استفاده از دستورات آماده با کوئری های پارامتری (Prepared Statements with Parameterized Queries) هست.

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

این روش باعث میشه مفسر SQL همیشه بتونه به درستی بین کد و داده تفاوت قائل بشه و جلوی اجرای کدهای مخرب گرفته بشه.

بیاید دوباره متد (authenticate) رو بازنویسی کنیم، اما این بار با استفاده از قابلیت پارامتری سازی توسط شیء PreparedStatement

صرف نظر از ورودی کاربر، متغیرهای زمان اجرا مثل name و pass نباید روی رفتار کوئری تاثیر بذارن. توجه داشته باشید که استفاده از شیء PreparedStatement به تنهایی دفاع مناسبی در برابر حملات SQL Injection نیست. این شیء باید همراه با قابلیت پارامتری سازی (یعنی استفاده از علامت “?” برای همه عناصر ورودی) استفاده بشه.

بدون این قابلیت، اتصال رشته ها (String Concatenation) میتونه همچنان منجر به حملات SQL Injection بشه، حتی اگر از PreparedStatement هم استفاده شده باشه.

Stored Procedures

Stored Procedures دستوراتی از SQL هستن که به صورت از پیش تعریف شده توی خود پایگاه داده ذخیره میشن و بعدا از سمت اپلیکیشن فراخوانی میشن. معمولا توسعه دهنده ها فقط نیاز دارن که دستورات SQL رو با پارامترهایی که به صورت خودکار پارامتری میشن بسازن.

با این حال، این امکان وجود داره که یه توسعه دهنده توی Stored Procedure ها کوئری های داینامیک بنویسه. بنابراین برای استفاده امن از Stored Procedure ها باید از تولید کوئری های داینامیک درون اون ها اجتناب بشه.

اعتبارسنجی ورودی (Input Validation)

یکی از رایج ترین منابع حملات SQL Injection ورودی های مخربیه که از منابع خارجی به اپلیکیشن داده میشن. به همین دلیل، همیشه باید فقط ورودی های تایید شده رو قبول کنید. این روش با عنوان اعتبارسنجی ورودی شناخته میشه.

برای محافظت در برابر این حمله، دو نوع اعتبارسنجی وجود داره:

اعتبارسنجی با لیست سیاه (Avoid List Validation)

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

مشکل این روش اینه که مهاجم ها میتونن ورودی های مخرب جدیدی بسازن که توی این لیست موجود نباشه و از فیلترها عبور کنن.

اعتبارسنجی با لیست سفید (Preferlist Validation)

این روش بسیار ایمن تر و موثرتره. در این حالت، ورودی کاربر با یه لیستی از ورودی های مجاز و تایید شده مقایسه میشه.

اپلیکیشن دقیقا میدونه چه ورودی هایی باید پذیرفته بشن و هر ورودی که این معیارها رو نداشته باشه، رد میشه. این روش ریسک حملات رو به حداقل میرسونه.

اصل کمترین سطح دسترسی (Principle of Least Privilege)

این یک اصل امنیتی استاندارد و مهمه که به کم کردن آسیب های احتمالی حملات موفق کمک میکنه.

حساب های کاربری اپلیکیشن نباید دسترسی DBA یا Admin به سرور پایگاه داده داشته باشن. علاوه بر این، هر حساب کاربری باید فقط دسترسی لازم برای عملکرد مورد نیازش رو داشته باشه.

مثلا، حساب هایی که فقط نیاز به دسترسی خواندن دارن، باید فقط به همون جداول خاص دسترسی Read-Only داشته باشن.

این کار باعث میشه که حتی اگه اپلیکیشن آسیب ببینه یا هک بشه، مهاجم نتونه از اون طریق به پایگاه داده دسترسی پیدا کنه و صدمه بزنه.

اگر این مطلب برای شما مفید بود، نظراتتون رو با ما به اشتراک بگذارین.