فا

‫ تزريق SQL (انواع روشهاي حمله)

IRCAR201005062

در اين بخش، ما انواع روش­هاي شناخته شده حملات تزريق SQL را بيان و تشريح خواهيم كرد. براي هر نوع حمله، يك نام، يك يا چند هدف حمله، يك توصيف از حمله، و يك مثال بيان خواهند شد.
انواع مختلف حملات بسته به اهداف مهاجم، گاهي با هم و گاهي به صورت متوالي و پشت سر هم نيز مورد استفاده قرار مي­گيرند. همچنين بايد به اين نكته نيز توجه كرد كه نسخه هاي متعددي از هر نوع حمله نيز وجود دارد.


Tautology

هدف حمله:


عبور از مكانيزم­هاي تاييد اعتبار كاربر، مشخص كردن آسيب پذيري­هاي برنامه وب يا پارامترهاي قابل تزريق، به دست آوردن داده هاي ارزشمند، حساس و مفيد از پايگاه داده.
توصيف:
هدف معمول يك حمله مبتني بر tautology اين است كه كدي را به يك يا چند جمله شرطي تزريق نمايد، به صورتي كه آن شرط­ها همواره صحيح باشند. نتيجه اين حمله به اين بستگي دارد كه نتيجه پرس و جوها چگونه در برنامه مورد استفاده قرار گيرد. موارد استفاده معمول اين حملات در عبور از صفحات تاييد اعتبار و به دست آوردن داده است. در اين نوع تزريق، يك فرد مهاجم از يك فيلد قابل تزريق كه در يك پرس و جوي شرطي WHERE مورد استفاده قرار مي­گيرد، سوء استفاده مي­كند. تبديل جمله شرطي به يك tautology باعث مي­شود كه تمامي سطرهاي جدول پايگاه داده كه هدف پرس و جو بوده اند، به عنوان نتيجه باز گردانده شوند. در كل براي اينكه يك حمله مبتني بر tautology بتواند كار كند، يك فرد مهاجم نه تنها بايد پارامترهاي قابل تزريق يا آسيب پذير را در نظر بگيرد، بلكه ساختارهاي كدگذاري كه نتايج پرس و جو را ارزيابي مي­كنند نيز بايد در نظر گرفته شوند. نوعا اين حمله زماني موفقيت آميز خواهد بود كه كد تمامي ركوردهاي برگردانده شده را نمايش دهد يا اينكه اگر حداقل يك ركورد برگردانده شده است، برخي عمليات را بر روي آن انجام دهد.
مثال:
در اين مثال حمله، يك فرد مهاجم ‘ or 1=1 - - را براي فيلد ورودي login ثبت مي­نمايد (ورودي ثبت شده براي ساير فيلدها نامربوط است). پرس و جوي نتيجه اين است:

SELECT accounts FROM users WHERE Login=’ ’ or 1=1 - - AND pass=’ ’ AND pin=


كد تزريق شده به جمله شرطي (OR 1=1) كل عبارت WHERE را به يك tautology تبديل مي­كند. اين پايگاه داده از اين جمله شرطي به عنوان مبناي ارزيابي هر سطر و تصميم گيري در مورد اينكه كداميك به برنامه برگردانده شوند استفاده مي­كند. از آنجايي­كه جمله شرطي يك tautology است، اين پرس و جو به ازاي هر سطر از جدول مقدار صحيح برمي­گرداند و تمامي آنها را برمي­گرداند. در مثال ما، مجموعه بازگردانده شده به يك مقدار غير NULL ارزيابي مي­شود، كه باعث مي­شود برنامه اين­طور نتيجه گيري كند كه تاييد هويت كاربر موفقيت آميز بوده است. بنابراين اين برنامه متد displayAccounts( ) را فراخواني كرده و تمامي حساب­هاي كاربري مجموعه بازگردانده شده توسط پايگاه داده را نمايش مي­دهد.

پرس و جوهاي نادرست غير مجاز/غير منطقي

هدف حمله:

مشخص كردن آسيب پذيري­هاي برنامه وب يا پارامترهاي قابل تزريق، مشخص كردن نوع و نسخه پايگاه داده مورد استفاده برنامه وب، به دست آوردن داده هاي ارزشمند، حساس و مفيد از پايگاه داده.

توصيف:

اين حمله به فرد مهاجم اجازه مي­دهد كه اطلاعات مهمي راجع به نوع و ساختار پايگاه داده موجود در پشت يك برنامه وب به دست آورد. اين حمله يك گام ابتدايي جمع آوري اطلاعات براي ساير حملات به شمار مي­رود. آسيب پذيري مورد استفاده در اين حمله اين است كه صفحه خطاي بازگردانده شده توسط سرورهاي برنامه، اغلب توصيفي است. در حقيقت، اين واقعيت كه يك پيغام خطاي ساده توليد شده است، اغلب مي­تواند پارامترهاي آسيب پذير و قابل تزريق را براي يك فرد مهاجم آشكار نمايد. ساير اطلاعات خطا، كه معمولا براي كمك به برنامه نويسان براي اشكال زدايي برنامه هايشان به كار مي­رود، به مهاجمان كمك مي­كند كه اطلاعاتي راجع به الگو و مدل پايگاه داده به دست آورند. فرد مهاجم در زمان انجام اين حمله سعي مي­كند دستوراتي را كه باعث يك خطاي دستوري، تبديل نوع، و يا منطقي مي­شوند به پايگاه داده تزريق نمايد. خطاهاي دستوري مي­توانند براي معرفي پارامترهاي قابل تزريق به كار روند. خطاهاي نوع مي­توانند براي به دست آوردن نوع داده هاي ستون­هاي خاص يا به دست آوردن خود داده ها مورد استفاده قرار گيرند. خطاهاي منطقي اغلب نام جداول و ستون­هايي را كه باعث خطا شده اند به دست مي آورند.

مثال:
هدف اين حمله در اين مثال اين است كه يك خطاي تبديل نوع ايجاد نمايد كه مي­تواند داده هاي مرتبط را افشا نمايد. براي انجام اين كار، فرد مهاجم متن زير را به فيلد ورودي pin تزريق مي­كند:

“convert(int,(select top 1 name from sysobjects where xtype=’u’))”

پرس و جوي نتيجه به اين شكل خواهد بود:
SELECT accounts FROM users WHERE login=’ ’ AND Pass=’ ’ AND pin= convert (int, (select top 1 name from sysobjects where xtype=’u’))

در رشته حمله، پرس و جوي تزريق شده تلاش مي­كند كه اولين جدول كاربر (xtype=’u’) را از جدول ابرداده هاي پايگاه داده بيرون بكشد (فرض كنيد كه اين برنامه از Microsoft SQL Server استفاده مي­كند كه جدول ابرداده در آن sysobjects ناميده مي­شود). آنگاه اين پرس و جو سعي مي­كند نام اين جدول را به يك عدد صحيح تغيير دهد. از آنجايي­كه اين يك تبديل نوع مجاز نيست، پايگاه داده يك پيغام خطا توليد مي­كند. در Microsoft SQL Server اين پيغام خطا چنين خواهد بود:

“Microsoft OLE DB Provider for SQL Server (0x80040E07) Error converting nvarchar value ‘CreditCards’ to a column of data type int”.


اطلاعات مفيدي كه در اين پيغام خطا براي فرد مهاجم وجود دارد دو دسته است. اول اينكه فرد مهاجم مي­تواند ببيند كه پايگاه داده از نوع SQL Server است. دوم اينكه اين پيغام خطا، مقدار رشته اي كه باعث خطاي تبديل نوع شده است را افشا مي­كند. در اين حالت، اين مقدار نام اولين جدول تعريف شده توسط كاربر در پايگاه داده نيز هست: «CreditCards». يك استراتژي مشابه مي­تواند براي استخراج سيستماتيك نام و نوع هر ستون پايگاه داده نيز به كار رود. با استفاده از اين اطلاعات درباره مدل پايگاه داده، يك فرد مهاجم مي­تواند حملات بعدي را كه اطلاعات خاصي را هدف قرار مي­دهند آغاز نمايد.

پرس و جوي Union

پرس و جوي نتيجه به اين شكل خواهد بود:

هدف حمله:

عبور از مكانيزم­هاي تاييد اعتبار كاربر، به دست آوردن داده هاي ارزشمند، حساس و مفيد از پايگاه داده

توصيف:

در حملات پرس و جوي Union، يك فرد مهاجم با سوء استفاده از يك پارامتر آسيب پذير، مجموعه داده هاي بازگردانده شده براي يك پرس و جو را تغيير مي­دهد. با اين تكنيك، يك فرد مهاجم مي­تواند برنامه را فريب داده و داده ها را از جدولي غير از جدول مورد نظر طراح پايگاه داده برگرداند. مهاجمان اين كار را با تزريق يك دستور به شكل UNION SELECT <rest of injected query> انجام مي­دهند. از آنجاييكه مهاجمان به طور كامل دومين پرس و جوي تزريق شده را كنترل مي­كنند، مي­توانند از اين پرس و جو براي بازيابي اطلاعات از يك جدول خاص استفاده نمايند. نتيجه اين حمله اين است كه پايگاه داده، مجموعه داده اي را برمي­گرداند كه اشتراك نتايج پرس و جوي اصلي و نتايج پرس و جوي تزريق شده است.

مثال:

يك فرد مهاجم مي­تواند متن

“UNION SELECT cardNO from CreditCards where acctNO=10032 - -“

را به فيلد login تزريق نمايد كه پرس و جوي زير را توليد مي­كند:
SELECT accounts FROM users WHERE login=’ ’ UNION
SELECT cardNO from CreditCards where acctNO=10032 - - AND pass=’ ’ AND pin=


با فرض اينكه هيچ لاگيني مترادف با “ “ نيست، پرس و جوي اصلي مجموعه null برمي­گرداند، در حاليكه پرس و جوي تزريق شده، داده هاي جدول CreditCards را برمي­گرداند. در اين حالت، اين پايگاه داده ستون «cardNo» را براي حساب «10032» برمي­گرداند. اين پايگاه داده ها نتايج اين دو پرس و جو را مي­گيرد، اشتراك آنها را به دست مي آورد، و آنها را به برنامه باز مي­گرداند. در بسياري از برنامه ها، تاثير اين عمليات اين است كه مقدار «cardNo» همراه با اطلاعات حساب كاربري نمايش داده مي­شود.

پردازه هاي ذخيره شده

را به فيلد login تزريق نمايد كه پرس و جوي زير را توليد مي­كند:

هدف حمله:

عبور از مكانيزم­هاي تاييد اعتبار كاربر، به دست آوردن داده هاي ارزشمند، حساس و مفيد از پايگاه داده

توصيف:

اين نوع حملات تزريق SQL سعي مي­كنند روال­هاي ذخيره شده موجود در پايگاه داده را اجرا نمايند. امروزه اغلب توليد كنندگان پايگاه­هاي داده، محصولات خود را با يك مجموعه روال استاندارد كه بر روي آن ذخيره شده است به فروش مي­رسانند. اين روال­ها كارآيي پايگاه داده را افزايش مي­دهند و امكان تعامل با سيستم عامل را ايجاد مي­نمايند. بنابراين زماني كه يك فرد مهاجم تشخيص مي­دهد كه چه نوع پايگاه داده اي مورد استفاده قرار گرفته است، حملات تزريق SQL مي­توانند طوري طراحي شوند كه روال­هاي ذخيره شده در آن پايگاه داده خاص، از جمله روال­هايي كه به تعامل با سيستم عامل مي­پردازند را اجرا نمايند.

اين يك تصور غلط و رايج است كه استفاده از روال­هاي ذخيره شده براي نوشتن برنامه هاي وب، آنها را در برابر حملات تزريق SQL آسيب ناپذير مي­سازد. برنامه نويسان اغلب از مشاهده اينكه روال­هاي ذخيره شده آنها به اندازه برنامه هاي عادي نسبت به حملات آسيب پذير است متعجب مي­شوند. به علاوه، از آنجايي­كه روال­هاي ذخيره شده معمولا به زبان­هاي اسكريپت نويسي خاص نوشته مي­شوند، مي­توانند شامل انواع ديگري از آسيب پذيري­ها مانند سرريز بافر باشند كه به مهاجمان اجازه مي­دهند كد دلخواه خود را بر روي سرور اجرا كرده و يا اولويت خود را افزايش دهند.

مثال:

روال ذخيره شده براي چك كردن اعتبارات:

CREATE PROCEDURE DBO. isAuthenticated
@userName varchar2, @pass varchar2, @pin int
AS
EXEC(“SELECT accounts FROM users
WHERE login=’ “ +@userName+ “ ’ and pass=’ “ +@password+

“ ’ and pin=” +@pin);
GO

اين مثال نشان مي­دهد كه چگونه يك روال ذخيره شده پارامتري مي­تواند توسط يك حمله تزريق SQL مورد سوء استفاده قرار گيرد. در اين مثال، ما فرض مي­كنيم كه رشته پرس و جوي ساخته شده در خطوط 5، 6 و 7 مثال ما، توسط يك فراخواني به روال ذخيره شده فوق جايگزين مي­گردد. اين روال ذخيره شده يك مقدار True/False را برمي­گرداند كه نشان مي­دهد آيا اعتبار كاربر به درستي تاييد شده است يا خير. براي راه اندازي يك حمله تزريق SQL، اين مهاجم به سادگي “ ‘ ; SHUTDOWN;--“ را به فيلدهاي username يا password تزريق مي­كند. اين تزريق باعث مي­شود كه روال ذخيره شده پرس و جوي زير را توليد نمايد:

SELECT accounts FROM users WHERE login=’doe’ AND pass=’ ’; SHUTDWON; -- AND pin=

در اينجا، اولين پرس و جو به صورت عادي اجرا مي­گردد، و سپس دومين پرس و جوي خرابكار اجرا مي­شود، كه باعث خاموش شدن پايگاه داده مي­گردد.

استنتاج

هدف حمله:

مشخص كردن آسيب پذيري­هاي برنامه وب يا پارامترهاي قابل تزريق، به دست آوردن داده هاي ارزشمند، حساس و مفيد از پايگاه داده، به دست آوردن الگوي پايگاه داده مانند نام جداول، نام ستون­ها، و نوع داده ستون­ها

توصيف:

در اين حمله، پرس و جو طوري تغيير مي­كند كه به شكل يك كنش كه بر اساس پاسخ به يك سوال True/Flase درباره ارزش­هاي داده ها در پايگاه داده اجرا مي­شود، درآيد. در اين نوع تزريق، مهاجمان معمولا سعي مي­كنند كه به يك سايت كه به اندازه كافي امن شده است حمله نمايند، بنابراين زماني كه تزريق موفق اتفاق مي افتد، هيچ فيدبك قابل استفاده اي از طريق پيغام­هاي خطاي پايگاه داده وجود ندارد. از آنجاييكه پيغام­هاي خطاي پايگاه داده فيدبكي در اختيار مهاجم قرار نمي­دهد، مهاجمان بايد از يك روش متفاوت براي به دست آوردن جواب از پايگاه داده استفاده كنند. در اين شرايط، فرد مهاجم دستورات را به سايت تزريق مي­كند و سپس مشاهده مي­كند كه چگونه تابع/پاسخ وب سايت تغيير مي­كند. با توجه به اينكه سايت چه زماني مانند هميشه و به حالت عادي و چه زماني به صورتي متفاوت رفتار مي­كند، يك فرد مهاجم مي­تواند نتيجه بگيرد كه كه كدام پارامترها آسيب پذير هستند و نيز مي­تواند اطلاعات ديگري راجع به مقادير موجود در پايگاه داده به دست آورد. دو تكنيك حمله شناخته شده مبتني بر استنتاج وجود دارند. اين دو تكنيك به فرد مهاجم اجازه مي­دهند كه داده ها را از يك پايگاه داده به دست آورده و پارامترهاي آسيب پذير را شناسايي نمايد. محققان گزارش كرده اند كه با استفاده از اين تكنيك­ها، توانسته اند با سرعتي معادل 1 B/s داده ها را استخراج نمايند.

تزريق كور:

در اين تكنيك، اطلاعات بايد از رفتار صفحه و با پرسيدن سوالاتي با پاسخ­هاي True/Flase از سرور استنتاج گردد. اگر دستور تزريق شده صحيح ارزيابي گردد، سايت به فعاليت خود به صورت عادي ادامه مي­دهد. اما اگر اين دستور غلط ارزيابي گردد، با اينكه هيچ پيغام خطايي نمايش داده نمي­شود، ولي صفحه با وضعيت عادي بسيار تفاوت دارد.

حملات زمان بندي:

يك حمله زمان بندي به فرد مهاجم اجازه مي­دهد كه با مشاهده تاخيرات زماني در پاسخ­هاي پايگاه داده، اطلاعات را از اين پايگاه داده به دست آورد. اين حمله بسيار مشابه تزريق كور است، ولي از يك متد استنتاج متفاوت استفاده مي­كند. براي انجام يك حمله زمان بندي، مهاجمان پرس و جوي تزريق شده خود را به شكل يك دستور if/then مي­سازند كه گزاره شاخه هاي then در آن، به يك پارامتر ناشناخته درباره محتويات پايگاه داده مرتبط مي­شود. مهاجم از يك ساختار SQL استفاده مي­كند كه زمان مشخصي را براي اجرا نياز دارد (براي مثال كلمه كليدي WAITFOR كه باعث مي­شود پايگاه داده به مدت زمان مشخصي پاسخ خود را به تاخير بيندازد). فرد مهاجم با اندازه گيري افزايش يا كاهش تاخير در پاسخ پايگاه داده، مي­تواند نتيجه گيري كند كه كدام شاخه then در اين تزريق به كار گرفته شده و در نتيجه پاسخ پرس و جوي تزريق شده چيست.

مثال:

دو روش براي استفاده از حملات استنتاج وجود دارد. در روش اول، پارامترهاي قابل تزريق با استفاده از تزريق كور به دست مي آيند. دو تزريق ممكن را به فيلد login در نظر بگيريد. اولي “legalUser’ and 1=0 - -” و دومي “legalUser’ and 1=1 - -”. اين تزريق­ها به دو پرس و جوي زير منجر مي­شوند:

SELECT accounts FROM users WHERE login=’legalUser’ and 1=0 - - ’ AND pass=’ ’ AND pin=0
SELECT accounts FROM users WHERE login=legalUser’ and 1=1 - - ’ AND pass=’ ’ AND pin=0

اكنون اجازه بدهيد دو سناريو را در نظر بگيريم. در اولين سناريو، ما يك برنامه امن داريم و ورودي login به صورت صحيح اعتبار سنجي شده است. در اين حالت، هر دو تزريق پيغام­هاي خطاي login باز خواهند گرداند، و فرد مهاجم خواهد دانست كه پارامتر login آسيب پذير نيست. در سناريوي دوم، ما يك برنامه غير امن داريم و پارامتر login در برابر تزريق آسيب پذير است. فرد مهاجم تزريق نخست را انجام داده، و از آنجايي كه اين تزريق هميشه به صورت غلط ارزشيابي مي­گردد، برنامه يك پيغام خطاي login بازمي­گرداند. در اين وضع، فرد مهاجم نمي­داند كه اين پيغام خطا به علت اعتبار سنجي صحيح ورودي و مسدود كردن حمله رخ داده است، يا اينكه خود حمله پيغام خطا را توليد كرده است. فرد مهاجم دومين پرس و جو را ثبت مي­كند، كه هميشه به مقدار صحيح ارزيابي مي­گردد. اگر در اين حالت هيچ پيغام خطاي ورودي وجود نداشته باشد، آنگاه فرد مهاجم نتيجه مي­گيرد كه حمله انجام شده و پارامتر login نسبت به تزريق آسيب پذير است.

روش دوم حملات مبتني بر استنتاج براي به دست آوردن داده از پايگاه داده ها مناسب است. در اينجا ما با يك مثال، نشان مي­دهيم كه چگونه از حملات زمان بندي براي به دست آوردن نام يك جدول پايگاه داده استفاده مي­كنيم. در اين حمله، دستور زير به پارامتر login تزريق مي­شود:

‘ ‘legalUser’ and ASCII (SUBSTRING((select top 1 name from sysobjects),1,1)) > X WAITFOR 5 - -’ ’.

اين تزريق، پرس و جوي زير را توليد مي­كند:
SELECT accounts FROM users WHERE login=’legalUser’ and ASCII (SUBSTRING((select top 1 name from sysobjects),1,1)) > X WAITFOR 5 - - ’ AND pass=’ ’ AND pin=0 AND pin=0

در اين حمله، تابع SUBSTRING براي به دست آوردن اولين كاراكتر نام اولين جدول استفاده مي­شود. سپس با استفاده از استراتژي جستجوي دودويي، فرد مهاجم مي­تواند مجموعه اي از پرس و جوها را در مورد اين كاراكتر انجام دهد. در اين مثال، فرد مهاجم اين پرس و جو را ايجاد مي­كند كه آيا كد اسكي كاراكتر مورد نظر، بزرگتر، كوچكتر، يا مساوي مقدار X است. اگر مقدار مورد نظر بزرگتر باشد، فرد مهاجم آن را با 5 ثانيه تاخير اضافه شده به پاسخ پايگاه داده متوجه خواهد شد. سپس فرد مهاجم مي­تواند با استفاده از يك جستجوي دودويي با تغيير مقدار X، مقدار آن كاراكتر را پيدا نمايد.

اين تزريق، پرس و جوي زير را توليد مي­كند:


نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 18 مرداد 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها: 0