فا

‫ اخبار

صفحات: «« « ... 31 32 33 34 35
نتایج جستجو براساس برچسب: "مستندات مرجع"
تزريق 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 برچسب‌ها: مستندات مرجع
اصول برنامه نويسي امن
IRCAR20100563

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

  1. اعتبارسنجي ورودي
    تمام ورودي ها از منابع داده نامطمئن را اعتبارسنجي كنيد. اعتبارسنجي صحيح ورودي، گستره وسيعي از آسيب پذيري ها نرم افزار را حذف مي كند. بهتر است به اكثر منابع داده خارجي همچون خط دستور، واسطهاي شبكه، متغيرهاي محيطي و فايل هاي تحت اختيار كاربر، مشكوك باشيد. اعتبار سنجي ورودي تا حد زيادي از بروز حملات تزريق SQL جلوگيري به عمل مي آورد.
  2. جدي گرفتن هشدارهاي كامپايلر
    كد خود را با استفاده از بالاترين سطح هشدار ممكن، كامپايل كنيد و هشدارها را با اعمال تغييرات در كد از بين ببريد.
  3. معماري و طراحي براي به كارگيري سياست هاي امنيتي
    يك معماري نرم افزار ايجاد كرده و نرم افزار خود را به گونه اي طراحي كنيد كه سياست هاي امنيتي در آن پياده سازي و اجرا شود. براي مثال، در صورتي كه سيستم شما نيازمند حقوق دسترسي متفاوت در زمان هاي متفاوتي است، سيستم را به زيرسيستم هاي مجزا تقسيم كنيد به طوري كه هر زير سيستم داراي حق دسترسي مناسب باشد.
  4. سادگي
    تا جايي كه امكان دارد طراحي را ساده و كوچك نگاه داريد. طراحي هاي پيچيده احتمال بروز خطا را در پياده سازي، تنظيمات و به كارگيري افزايش مي دهند. به علاوه طراحي پيچيده تلاش لازم براي رسيدن به سطح مطلوب تضمين امنيت را به طرز قابل توجهي بالا مي برد، زيرا مكانيزم هاي امنيتي نيز به همان نسبت پيچيده تر مي شوند.
  5. انكار پيش فرض
    اساس همه دسترسي ها را بر مبناي اجازه دادن به افراد مجاز به جاي مستثني كردن افراد غيرمجاز قرار دهيد. يعني به صورت پيش فرض از دسترسي ها جلوگيري شود و تنها تعيين كننده شرايطي كه تحت آنها اجازه دسترسي صادر مي شود، الگوي حفاظت باشد.
  6. وفادار بودن به اصل حداقل حق دسترسي
    هر پردازه اي بايد با كمترين حقوق دسترسي كه براي كامل كردن آن مورد نياز است، اجرا شود. هر حق دسترسي بالاتري بايد در كمترين زمان ممكن در اختيار پردازه قرار گيرد. اين راهكار فرصت هاي مهاجم را براي اجراي كد دلخواه با حق دسترسي ارتقا يافته، كاهش مي دهد.
  7. محافظت از داده هايي كه به سيستم هاي ديگر فرستاده مي شوند
    از تمام داده هايي كه به زيرسيستم هاي پيچيده همچون واسط هاي فرمان، پايگاه داده هاي رابطه اي و برنامه هاي آماده فرستاده مي شوند، محافظت به عمل آوريد. مهاجمان ممكن است بتوانند از قابليت هاي استفاده نشده در زير سيستم هاي مذكور، با استفاده از SQL، دستور (command) و يا ديگر حمله هاي تزريق، سوءاستفاده كرده و زيرسيستم هاي مذكور را فراخواني كنند. البته دقت كنيد كه اين مشكل لزوماً مشكل اعتبار سنجي داده هاي ورودي نيست زيرا زيرسيستم هاي پيچيده قادر به تشخيص زمينه اي كه در آن درخواست ها انجام مي شود، نيستند. از آنجايي كه پردازه اي كه زيرسيستم ها را فراخواني مي كند، قادر به تشخيص زمينه است، بنابراين پردازه مذكور، مسئول محافظت از داده ها، قبل از فراخواني زير سيستم هاي پيچيده است.
  8. اجراي دفاع در عمق
    مديريت خطر را با استفاده از استراتژي دفاع چندلايه انجام دهيد، در اين صورت اگر يكي از لايه هاي دفاعي نتواند به خوبي كار كند، لايه دفاعي ديگري از تبديل شدن يك نقص امنيتي به يك آسيب پذيري قابل سوءاستفاده جلوگيري به عمل مي آورد و يا نتايج سوء يك حمله موفق را كاهش مي دهد. براي مثال، تركيب تكنيك هاي برنامه نويسي امن با محيط اجراي امن منجر به كاهش احتمال سوءاستفاده از آسيب پذيري هاي باقيمانده در كد، در زمان اجراي برنامه و در محيط عملياتي مي شود.
  9. استفاده از روش هاي موثر تضمين كيفيت
    تكنيك هاي تضمين كيفيت خوب، در شناسايي و حذف آسيب پذيري ها بسيار مؤثر عمل مي كنند. تست نفوذ، تست fuzz (يك تكنيك تست نرم افزار كه در آن از ورودي هاي دور از انتظار، غيرمعمول و تصادفي استفاده ميشود) و مميزي هاي كد منبع همگي بايد به عنوان قسمتي از يك برنامه تضمين كيفيت مؤثر در نظر گرفته شوند. همچنين مرور امنيتي نرم افزار توسط يك گروه كه مستقل از توليد كنندگان هستند، مي تواند منجر به امنيت بالاتر سيستم شود. در واقع مرورگران بيروني ديدگاه جديدي را با خود مي آورند و در نتيجه براي حل برخي مشكلات همچون شناسايي و اصلاح پيش فرض هاي نادرست بسيار مفيد واقع مي شوند.
  10. اتخاذ يك استاندارد كدنويسي امن
    لازم است يك استاندارد كدنويسي امن را بر مبناي زبان برنامه نويسي و سكويي كه براي توسعه نرم افزار استفاده مي شود، ايجاد كرده و يا از انواع موجود آن استفاده كنيد. در سري مقالات بعدي در مورد استاندارد CERT براي كدنويسي امن با زبان هاي برنامه نويسي C، C++ و جاوا صحبت خواهيم كرد.
  11. تعريف نيازمندي هاي امنيتي
    نيازمندي هاي امنيتي را هر چه زودتر در چرخه حيات توسعه نرم افزار مشخص كرده و وارد كنيد. سپس در مراحل بعدي توليد نرم افزار از همخواني آنها با نيازمندي هاي امنيتي اطمينان حاصل كنيد. زماني كه نيازمندي هاي امنيتي تعريف نشده اند، امنيت سيستم توليد شده نمي تواند به صورت مؤثر ارزيابي شود.
  12. مدلسازي تهديدها
    از مدلسازي تهديد براي پيش بيني تهديدهايي كه نرم افزار در آينده با آن مواجه خواهد شد استفاده كنيد. مدلسازي تهديد شامل مشخص كردن دارايي هاي كليدي، تجزيه برنامه كاربردي، تعيين و دسته بندي تهديدهاي مربوط به هر دارايي و بخش، درجه بندي تهديدها بر اساس يك معيار درجه بندي خطر و سپس توسعه استراتژي هاي كاهش تهديدها مي شود كه بايد در قسمت هاي طراحي، كد و تست پياده سازي شوند.
18 مرداد 1393 برچسب‌ها: مستندات مرجع
آشنايي با استاندارد CERT براي برنامه نويسي امن
IRCAR201006064

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

از استانداردهاي معروف در اين زمينه مي توان به استانداردCERT براي كدنويسي امن اشاره كرد كه يك سري از قوانين و پيشنهادات را براي كد نويسي امن با زبان هاي برنامه نويسي C، C++ و جاوا ارائه مي دهد. هدف از اين قوانين و پيشنهادات، حذف عادت هاي كدنويسي ناامن و رفتارهاي تعريف نشده است كه منجر به آسيب پذيري هاي قابل سوءاستفاده مي شود. به كارگيري استانداردهاي مذكور منجر به توليد سيستم هاي با كيفيت بالاتر مي شود كه در برابر حملات بالقوه، پايدارتر و مقاوم تر هستند.


قوانين در برابر پيشنهادات


استانداردهاي CERT براي كدنويسي امن شامل يك سري قوانين و پيشنهادات مي شوند. در زير تعريف هر كدام از آنها آورده شده است.

قوانين


يك روش برنامه نويسي زماني به عنوان قانون تعريف مي شود كه داراي خصوصيات زير باشد:
سرپيچي از روش فوق احتمالاً منجر به يك نقص امنيتي شده و ممكن است به يك آسيب پذيري قابل سوءاستفاده تبديل شود.
پيروي از روش فوق را بتوان توسط تحليل اتوماتيك، راهكارهاي رسمي يا تكنيك هاي بازرسي دستي تشخيص داد.
پياده ‌سازي قوانيني كه در استاندارد CERT براي برنامه نويسي امن آورده شده، براي اطمينان از امنيت سيستم هايي كه با زبان برنامه نويسي مربوطه ايجاد شده اند، شرط لازم است ولي كافي نيست. در اين استانداردها قوانين با برچسب rule مشخص مي شوند.


پيشنهادات


پيشنهادات در حقيقت يك سري از راهنمايي ها و توصيه ها است. يك روش كدنويسي زماني به عنوان يك پيشنهاد در نظر گرفته مي شود كه شرايط زير را دارا باشد:

  1. به كارگيري روش كدنويسي مذكور، باعث ارتقاي امنيت سيستم شود.
  2. شرايطي كه براي در نظر گرفتن روش مذكور به عنوان يك قانون لازم است، در مورد اين روش كدنويسي صدق نكند.

در هر تجربه كدنويسي، مجموعه اي از پيشنهادات با توجه به نيازمندي هاي امنيتي محصول نهايي مورد استفاده قرار مي گيرد. پروژه هايي كه نيازمند سطح امنيتي بالايي هستند، مي توانند منابع بيشتري را به امنيت اختصاص دهند و در نتيجه مجموعه بيشتري از پيشنهادات را نيز به كار گيرند.
در استانداردهاي CERT براي كدنويسي امن، از برچسب recommendation براي نشان دادن پيشنهادات استفاده مي شود.


استثناءها


هر قانون يا پيشنهادي ممكن است حاوي مجموعه كوچكي از استثناءها باشد كه نشان مي دهد تحت چه شرايطي به كار بردن قانون يا پيشنهاد مذكور براي بالا بردن سطح امنيتي محصول ضروري نيست. استثناءها فقط براي اطلاع كاربر عنوان مي شوند و پيروي از آنها لازم نيست. استثناء ها در استاندارد CERT براي برنامه نويسي امن با برچسب exceptions مشخص مي شوند.

شناسه ها


در استانداردهاي مذكور، هر قانون يا پيشنهاد، داراي يك شناسه يكتا است.(براي مثال PRE30-C ) اين شناسه ها از سه قسمت تشكيل شده اند:

  1. يك بخش سه حرفي كه نشان دهنده بخش استاندارد است براي مثال PRE كه نشان دهنده preprocessor است. اين بخش نشان دهنده روش هاي كدنويسي مشابه در يك گروه است.
  2. يك عدد دو رقمي بين 00 تا 99 كه براي يكتا سازي شناسه به كار مي رود. شماره هاي 00 تا 29 براي پيشنهادات و شماره هاي 30 تا 99 براي قانون ها ذخيره شده اند.
  3. قسمت سوم مربوط به نام زبان است براي مثال C.

به كارگيري استاندارد


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


معيار سنجش آسيب پذيري


معيار آسيب پذيري CERT، عددي بين 0 و 180 است كه ميزان اهميت يك آسيب پذيري را نشان مي دهد. در نگاشت يك عدد به آسيب پذيري، معيارهاي متفاوتي همچون ميزان شناخته شده بودن آن، وجود كد سوءاستفاده موفق از آن، در خطر قرار گرفتن زيرساخت هاي شبكه، تعداد رايانه هايي كه در خطر آسيب پذيري مذكور قرار دارند و غيره دخيل هستند. البته معيار مذكور خطي نبوده و به اين معني نيست كه يك آسيب پذيري با درجه 40 دو برابر يك آسيب پذيري با درجه 20 خطرناك است.

ارزيابي خطر


در استانداردهاي كدنويسي امن CERT، هر راهنما داراي بخشي به نام ارزيابي خطر يا Risk Assessment است كه به برنامه نويسان نشان مي دهد در صورت رسيدگي نكردن به يك آسيب پذيري خاص در كد برنامه، ممكن است چه نتايج بالقوه اي به بار آيد. اين اطلاعات در اولويت بندي آسيب پذيري هايي كه بايد رسيدگي شوند، توسط تيم برطرف كننده آسيب پذيري ها به كار گرفته مي شود.
ناديده انگاشتن هر قانون منجر به ايجاد آسيب پذيري هايي مي شود كه هر كدام از آنها از لحاظ جديت خطر (severity)، احتمال سوءاستفاده (likelihood) و هزينه ترميم (Remediation Cost) متفاوت هستند. در بخش ارزيابي خطر هر راهنما، موارد مذكور نشان داده مي شود. در جداول زير دسته بندي هاي مذكور نشان داده شده اند.

جديت يا Severity



احتمال سوءاستفاده يا likelihood



هزينه ترميم



سه مقدار مذكور در يكديگر ضرب خواهند شد تا ميزان اهميت به كارگيري هر قانون را نشان دهند. عدد به دست آمده مقداري بين 1 تا 27 خواهد بود كه تنها ده رقم 1، 2، 3، 4، 6، 8، 9، 12، 18 و 27 مجاز هستند. قوانين و پيشنهاداتي كه داراي اولويت بين 1 تا 4 باشند سطح 3، 6 تا 9 سطح 2 و 12 تا 27 سطح 1 در نظر گرفته مي شوند. در جدول زير اين سه سطح نشان داده شده اند.



به دليل ميزان جديت حملات ايجاد شده و احتمال بالاي سوءاستفاده در صورت رعايت نكردن قوانين سطح 1 ، اين قوانين از اهميت بيشتري برخوردار است. لذا در سري مقالات مرتبط با استاندارد كدنويسي امن، تنها به قوانين و پيشنهادات سطح اول خواهيم پرداخت.

در مقاله هاي بعدي در مورد كد نويسي امن در C، C++ و جاوا با توجه به استاندارد برنامه نويسي امن CERT صحبت خواهيم كرد.

18 مرداد 1393 برچسب‌ها: مستندات مرجع
تزريق SQL (مقابله با حملات)
IRCAR201006066

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


كد نويسي دفاعي


علت اصلي آسيب پذيري­هاي تزريق 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، مدل به طور مستقل توسط برنامه نويس مشخص مي­شود. هر دو روش از يك كليد محرمانه براي محدود كردن ورودي كاربر در طول تجزيه توسط چك كننده زمان اجرا استفاده مي­كنند، بنابراين امنيت روش به اين بستگي دارد كه مهاجمان قادر نباشند كليد را كشف كنند. علاوه بر اين، استفاده از اين دو روش نيازمند اين است كه برنامه نويس كد را دوباره نويسي كند تا از كتابخانه واسط استفاده نمايد، يا اينكه به طور دستي نشانه هاي خاص را به كد اضافه نمايد.
همچنين استفاده از سيستم­هاي فيلترينگ پروكسي كه قوانين اعتبار سنجي ورودي­ها را بر روي داده هاي ورودي به يك برنامه وب اعمال مي­كنند از ديگر راه­هاي جلوگيري از حملات تزريق SQL است. برخي سيستم­هاي تشخيص نفوذ (IDS) نيز مي­توانند حملات تزريق SQL را شناسايي نمايند.

18 مرداد 1393 برچسب‌ها: مستندات مرجع
برنامه نويسي امن با زبان C – پيش پردازشگرها
IRCAR201006067

عنصر اصلي در كدنويسي امن با زبان هاي مختلف برنامه نويسي، مستند سازي خوب و استفاده از استانداردهاي قابل اجرا است. استانداردهاي كدنويسي، برنامه نويسان را ترغيب به پيروي از مجموعه اي واحد از قوانين و راهنماييها مي كند كه بر اساس نيازمندي هاي پروژه و سازمان تعيين شده است، نه بر اساس سلايق و مهارت هاي مختلف برنامه نويسان. به محض تعيين استانداردهاي مذكور، مي توان از آن به عنوان معياري براي ارزيابي كدهاي منبع، چه به صورت دستي و چه به صورت اتوماتيك استفاده كرد. از استانداردهاي معروف در اين زمينه مي توان به استانداردCERT براي كدنويسي امن اشاره كرد كه يك سري از قوانين و پيشنهادات را براي كد نويسي امن با زبان هاي برنامه نويسي C، C++ و جاوا ارائه مي دهد. هدف از اين قوانين و پيشنهادات، حذف عادت هاي كدنويسي ناامن و رفتارهاي تعريف نشده است كه منجر به آسيب پذيري هاي قابل سوءاستفاده مي شود. به كارگيري استانداردهاي مذكور منجر به توليد سيستم هايي با كيفيت بالاتر مي شود كه در برابر حملات بالقوه، پايدارتر و مقاوم تر هستند. در مقاله "آشنايي با استاندارد CERT براي برنامه نويسي امن"، كليات استاندارد CERT در زمينه مزبور را توضيح داديم و در اين مقاله به صورت تخصصي تر شيوه برنامه نويسي امن با زبان C را مورد بررسي قرار مي دهيم. قابل ذكر است كه در اين استاندارد 89 قانون و 132 پيشنهاد براي برنامه نويسي امن با زبان C ارائه شده است كه در سري مقالات كدنويسي امن با زبان C، مهمترين آنها را كه در سطح يك قرار دارند، شرح خواهيم داد. براي كسب اطلاعات بيشتر در مورد سطح بندي قوانين و پيشنهادات به مقاله "آشنايي با استاندارد CERT براي برنامه نويسي امن" مراجعه فرماييد.


حوزه استاندارد CERT براي كدنويسي امن با C

استاندارد CERT براي كد نويسي امن با زبان برنامه نويسي C، به طور اختصاصي براي نسخه هايي كه توسط موسسات زير تعريف شده اند، تهيه شده است:

  • ISO/IEC 9899:1999 ويرايش دوم براي زبان C
  • Technical corrigenda TC1, TC2 and TC3
  • گسترش ISO/IEC TR 24731-1 براي كتابخانه C، قسمت اول: رابط هاي كاربر Bounds-checking
  • گسترش ISO/IEC PDTR 24731-2 براي كتابخانه C، قسمت دوم: Dynamic Allocation Functions

البته بسياري از موارد مطرح شده در اين استاندارد، قابليت اعمال بر نسخه هاي قديمي تر C را نيز دارد. همچنين هر چند كه بهترين راه حل ها براي مشكلات كدنويسي امن غالباً وابسته به سكو هستند، اما استاندارد مذكور مستقل از سيستم عامل و سكو است. البته در بسياري از موارد، استاندارد CERTبراي كدنويسي امن با C با سيستم هاي ويندوز و POSIX سازگاري دارد و همچنين در برخي از موارد داراي راه حل هاي اختصاصي براي سكوهايي همچون لينوكس و OpenBSD است.


دسته بندي قوانين و پيشنهادات


قوانين و پيشنهادات برنامه نويسي امن با زبان C به 14 زيرگروه تقسيم مي شوند. در زير دسته بندي مذكور و تعداد قوانين و پيشنهادات ارائه شده در هر زيرگروه آورده شده است.

رديف دسته بندي قوانين پيشنهادات
1 Preprocessor)PRE) 2 11
2 Declarations and Initialization)DCL) 7 16
3 Expressions)EXP) 9 13
4 Integers)INT) 6 16
5 Floating Point)FLP) 5 4
6 Arrays)ARR) 9 3
7 Characters and Strings 8 9
8 Memory Management)MEM) 6 11
9 Input Output)FIO) 15 17
10 Environment)ENV) 3 5
11 Signals)SIG) 5 3
12 Error Handling)ERR) 3 7
13 Miscellaneous)MSC) 2 16
14 POSIX)POS) 8 3
مجموع 88 134


در ادامه قوانين و پيشنهادات سطح يك (L1) از هر بخش را توضيح مي دهيم.


Preprocessor)PRE)

  1. پيشنهاد PRE01-C
    درون ماكروها، پرانتز به دور نام پارامترها قرار دهيد. براي مثال كد زير با اين پيشنهاد همخواني ندارد:
    #‫define CUBE(I) (I * I * I)

    براي همخواني با پيشنهاد مذكور بايد آن را به شكل زير تغيير داد:
    #‫define CUBE(I) ( (I) * (I) * (I) )

  2. پيشنهاد PRE02-C
    ليست هاي جايگزيني ماكروها بايد داراي پرانتز باشند. در زير نمونه اي را كه از پيشنهاد مذكور پيروي نكرده است مشاهده مي كنيد:
    #‫define CUBE(X) (X) * (X) * (X)

    براي همخواني با پيشنهاد مذكور بايد آن را به شكل زير تغيير داد:
    #‫define CUBE(X) ((X) * (X) * (X))

  3. پيشنهاد PRE09-C
    نام توابع امن را با نام توابع قديمي (deprecated) مانند gets() و يا از پيش ذخيره شده (obsolescent) مانند strcpy() جايگزين نكنيد. يكي از كاربردهاي ماكروها، اصلاح يك كد موجود جهت جايگزيني يك شناسه با شناسه ديگر است. براي مثال براي تغيير API هاي موجود مي توان از ماكروها استفاده كرد. با وجودي كه همواره خطراتي همراه با اين كار وجود دارد، اما اين روش زماني واقعاً خطرناك مي شود كه نام يك تابع با نام توابعي كه در زير آمده است، جايگزين شود.
  4. پيشنهاد PRE10-C
    در صورتي كه بيش از يك دستور در ماكرو وجود دارد، آن را درون حلقه do-while قرار دهيد. به اين ترتيب ماكروها مي توانند به صورت امن در درون دستورات شرطي ( if clauses ) يا ديگر مكان هايي كه بايد دستورات درون ماكرو به صورت يك كل ديده شود، قرار گيرند.
    #‫define SWAP(x, y)
    do {
    tmp = x;
    x = y;
    y = tmp; }
    while (0)
  5. پيشنهاد PRE11-C
    در انتهاي ماكروها علامت ";" را قرار ندهيد. ماكروها معمولاً براي بالا بردن قابليت خوانايي كد منبع مورد استفاده قرار مي گيرند. دقت داشته باشيد كه ماكروها صرف نظر از اينكه داراي تنها يك دستور و يا بيشتر باشند نبايد با علامت "; " تمام شوند. اضافه كردن ";" در انتهاي ماكروها به صورت غيرمنتظره روند اجراي برنامه را تغيير مي دهد. براي مثال، در كد زير در حالي كه برنامه نويس انتظار سه بار چاپ "inside for loop" را دارد ولي به علت وجود ";" روند اجراي برنامه تغيير كرده و متن مزبور تنها يك بار در خروجي چاپ مي شود.
    #‫define FOR_LOOP(n) for(i=0; i<(n); i++);>
    int i;
    FOR_LOOP(3)
    {
    puts("Inside for loopn"); }
    براي اصلاح كد مزبور كافي است كه علامت ";" از انتهاي تعريف ماكرو برداشته شود.

    در قسمت بعدي سري مقالات "برنامه نويسي امن با زبان C"، پيشنهادات و قوانين سطح 1 زير گروه هاي Expressions(EXP) و Integers(INT) را بررسي خواهيم كرد.


18 مرداد 1393 برچسب‌ها: مستندات مرجع
آشنايي با برخي ويژگي‌هاي راهكار مديريت دستگاه همراه

شماره :IRCAR201409234

تاريخ: 29/06/93

فروش تلفن‌هاي هوشمند و تبلت‌ها در طي پنج سال گذشته رو به رشد بوده است. هم چنين استفاده از اين دستگاه‌هاي همراه در محل كار رو به افزايش است.

اما استفاده از دستگاه‌ همراه، مخاطرات امنيتي را با خود دارد. از اين دستگاه‌ها مي‌توان براي دسترسي به شبكه‌هاي شركت و ذخيره داده‌هاي حساس آن استفاده كرد؛ اما اينكار باعث مي شود تا داده هاي شركت هنگام كار با دستگاه در خارج از آن به مخاطره بيفتند. اگر دستگاه همراه گم شود يا كاربر هنگام استفاده از دستگاه شغل خود را تغيير دهد، مي توان با استفاده از راهكار مديريت دستگاه همراه (MDM) مخاطرات امنيتي را به حداقل رساند.

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

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

مديريت دستگاه همراه به سازمان‌ها در كاهش مخاطرات امنيتي مرتبط با BYOD كمك مي‌كند. در اين مقاله به برخي خصوصياتي كه بايد در هنگام خريد سيستم‌ MDM در نظر گرفت اشاره مي‌شود.

خصوصيات مديريت دستگاه همراه

سيستم مديريت دستگاه همراه، معمولاً محدود به پيكربندي تنظيماتي است كه سيستم عامل دستگاه همراه در دسترس قرار مي‌دهد، و به همين دليل بيشتر MDMها مجموعه يكساني از خصوصيات امنيتي كه روي هر پلتفرم دستگاه همراه وجود دارد را فراهم مي كنند. اين ويژگي‌ها ممكن است از دستگاهي به دستگاهي ديگر متفاوت باشد اما معمولاً موارد زير را شامل مي‌شود:

1- اجبار به استفاده از كلمه عبور يا PIN دستگاه: حصول اطمينان از دسترسي به دستگاه بعد از وارد كردن 4رقم PIN يا ترجيحاً كلمه عبور يا عبارتي كه قابل حدس زدن نباشد، توسط اين خصوصيت تامين مي‌شود. كلمه عبور، PIN دستگاه يا عبارت عبور در صورت فراموشي، از طريق MDM قابل ريست شدن است.

2- قفل كردن يا پاك كردن دستگاه از راه دور: اين خصوصيت به مديران امكان قفل كردن يا حذف داده‌ها را از دستگاهي كه گم شده يا دزديده شده است مي‌دهد. بسياري از سيستم‌هاي مديريت دستگاه همراه امكان پيدا كردن منطقه جغرافيايي دستگاه را دارند. اين امكان به كاربران در پيداكردن دستگاه‌هاي گم شده يا دزديده شده و كاهش هزينه‌هاي مرتبط با آن كمك مي‌كند.

3- رمزنگاري داده: اين خصوصيت شامل فعال كردن رمزنگاري داده دستگاه در پلتفرم iOS يا اضافه كردن اين عملكرد در پلت فرم هايي مانند اندرويد كه ممكن است آن را نداشته باشند است.

4- شناسايي Jailbreak/root: شكستن قفل (jailbreak) يا روت كردن (root) دستگاه همراه منجر به حذف بسياري از محدوديت‌هاي امنيتي سطح سيستم عامل مي‌شود و ممكن است به كاربر امكان دور زدن كنترل‌هاي امنيتي اعمال شده توسط MDM را بدهد. به همين دليل، شناسايي شكسته شدن قفل يا روت شدن دستگاه، توسط MDM ضروري است.

علاوه بر پيكربندي اين نوع از تنظيمات امنيتي، بيشتر پلت فرم‌هاي مديريت دستگاه همراه به مديران دستگاه‌ها امكان ديدن وضعيت دروني دستگاه همراه را از راه دور (از جمله تنظيمات پيكربندي و برنامه‌هاي كاربردي نصب شده) مي دهد. برنامه كاربردي و سيستم عامل دستگاه مي‌تواند از طريق MDM به روز رساني شود و خط مشي‌هايي مبتني بر اكتيو دايركتوري يا ديگر دايركتوري‌ها طوري اعمال شود كه دسترسي كاربران به منابع شركت محدود به گروه‌هايي كه كاربر در آن است باشد.

بيشتر MDMها ويژگي‌هاي ديگري را نيز فراهم مي‌كنند. اين ويژگي‌ها شامل جلوگيري از استفاده از دوربين دستگاه (يا جلوگيري از استفاده در مكان‌هاي جغرافيايي خاص)، منع نصب برنامه‌هاي كاربردي كه در ليست سياه است، بلوكه كردن خريدهاي جانبي برنامه هاي كاربردي مانند بازي ها (in-app purchases) يا جلوگيري از نصب هر برنامه كاربردي مگر اينكه از سايت يا محلي معتبر دانلود شده باشد، مي‌تواند باشد.

منبع:

www.Esecurityplanet.com

1 آذر 1387 برچسب‌ها: مستندات مرجع
امنيت SQL Server – قسمت يازدهم – فعالسازي دسترسي بين پايگاه‌هاي داده

شماره :IRCAR201409233

تاريخ: 29/6/93

1- مقدمه

SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد.

هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند.

اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند.

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

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

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

2- فعالسازي دسترسي بين پايگاه داده‌ها در SQL Server

زنجيره مالكيت بين پايگاه‌هاي داده زماني اتفاق مي‌افتد كه يك روال در يك پايگاه داده به شيئي در يك پايگاه داده ديگر وابسته باشد. يك زنجيره مالكيت بين پايگاه‌هاي داده به همان روشي كار مي‌كند كه زنجيره مالكيت در يك پايگاه داده منفرد كار مي‌كند، به جز اينكه يك زنجيره مالكيت كه شكسته نشده باشد نياز دارد كه تمامي مالكان اشياء به حساب لاگين يكساني نگاشت گردند. درصورتي‌كه شيء منبع در پايگاه داده منبع و شيء مقصد در پايگاه داده مقصد توسط حساب لاگين يكساني مالكيت گردند، SQL Server مجوزهاي شيء مقصد را مورد بررسي قرار نمي‌دهد.

2-1- پيش‌فرض غيرفعال

زنجيره مالكيت بين پايگاه‌هاي داده به طور پيش‌فرض غيرفعال است. مايكروسافت توصيه مي‌كند كه زنجيره مالكيت بين پايگاه‌هاي داده را غيرفعال نماييد، چرا كه شما را در برابر تهديدات امنيتي ذيل آسيب‌پذير مي‌سازد:

  • مالكان پايگاه داده و اعضاي نقش‌هاي پايگاه داده db_ddladmin يا db_owners مي‌توانند اشيايي ايجاد كنند كه توسط ساير كاربران مالكيت مي‌شود. اين اشياء مي‌توانند به طور بالقوه اشياي پايگاه‌هاي داده ديگر را هدف قرار دهند. اين بدان معناست كه درصورتي‌كه شما زنجيره مالكيت بين پايگاه‌هاي داده را فعال نماييد بايد به اين كاربران در مورد داده‌هاي تمامي پايگاه‌هاي داده اعتماد داشته باشيد.
  • كاربراني با مجوز CREATE DATABASE مي‌توانند پايگاه‌هاي داده جديدي ايجاد نمايند و آنها را به پايگاه‌هاي داده موجود متصل كنند. درصورتي‌كه زنجيره مالكيت بين پايگاه‌هاي داده فعال باشد، اين كاربران مي‌توانند از پايگاه‌هاي داده جديد به اشياي ساير پايگاه‌هاي داده كه مجوز آنها را در اختيار ندارند، دسترسي پيدا كنند.

2-2- فعال‌سازي زنجيره مالكيت بين پايگاه‌هاي داده

زنجيره مالكيت بين پايگاه‌هاي داده بايد فقط در محيط‌هايي فعال گردد كه شما مي‌توانيد به طور كامل به كاربران داراي سطح دسترسي بالا اطمينان نماييد. اين مسأله مي‌تواند در طول تنظيمات و پيكربندي براي تمامي پايگاه‌هاي داده تنظيم گردد يا اينكه به طور انتخابي با استفاده از دستورات sp_configure و ALTER DATABASE درTransact-SQL براي يك پايگاه داده خاص تنظيم شود.

براي تنظيم انتخابي زنجيره مالكيت بين پايگاه‌هاي داده، ابتدا از دستور sp_configure براي غيرفعال كردن آن براي سرور استفاده كنيد. سپس از دستور ALTER DATABASE به همراه SET DB_CHAINING ON براي تنظيم زنجيره مالكيت بين پايگاه‌هاي داده براي پايگاه‌هاي داده مورد نظر خود استفاده كنيد.

مثال زير زنجيره مالكيت بين پايگاه‌هاي داده را براي تمامي پايگاه‌هاي داده فعال مي‌كند:

EXECUTE sp_configure 'show advanced', 1;
RECONFIGURE;
EXECUTE sp_configure 'cross db ownership chaining', 1;
RECONFIGURE;

مثال زير زنجيره مالكيت بين پايگاه‌هاي داده را براي پايگاه‌هاي داده خاص Database1 و Database2 فعال مي‌كند:

ALTER DATABASE Database1 SET DB_CHAINING ON;
ALTER DATABASE Database2 SET DB_CHAINING ON;

2-3- SQL پويا

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

1 آذر 1387 برچسب‌ها: مستندات مرجع
برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS07-J

شماره : IRCAR201409232

تاريخ: 24/06/93

اولين موضوعي كه به طور كلي در برنامه نويسي امن (رجوع شود به مقاله اصول برنامه نويسي امن) و همچنين در برنامه نويسي امن با زبان جاوا مورد توجه قرار مي گيرد مربوط به اعتبار سنجي ورودي و پاكسازي داده ها است. در اين موضوع چهارده قانون معرفي مي گردد كه سطوح امنيتي مختلفي دارند (رجوع شود به مقاله برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها - آشنايي). هشتمين قانون از اين موضوع داراي سطح امنيتي يك (L1) بوده و از اولويت (P12) برخوردار مي باشد.

قانون IDS07-J – داده نامطمئن و پاكسازي نشده را به متد Runtime.exec() ارسال نكنيد.

عموماً برنامه‌هاي بيروني براي اجراي عملياتي كه كل سيستم نيازمند آن است فراخواني مي‌شوند. اينكار شكلي از استفاده مجدد است و حتي ممكن است شكلي ناپخته از مهندسي نرم افزار مبتني بر اجزاء درنظر گرفته شود. آسيب پذيري‌هاي تزريق آرگومان و يا تزريق فرمان زماني اتفاق مي افتند كه برنامه كاربردي ورودي‌هاي نامطمئن را به درستي پاكسازي ننمايد و از آنها در اجراي برنامه‌هاي بيروني استفاده كند.

هر برنامه كاربردي جاوا، نمونه‌اي از كلاس Runtime را دارد كه به برنامه امكان برقراري ارتباط با محيطي را كه برنامه در آن درحال اجرا است مي‌دهد. زمان اجراي فعلي مي‌تواند از طريق متد Runtime.getRuntime() گرفته شود. معاني Runtime.exec() به خوبي تعريف نشده‌اند؛ بنابراين بهتر است جز در موارد ضروري به رفتار اين متد اعتماد نشود ولي معمولاً دستور مذكور مستقيماً و بدون پوسته(shell) فراخواني مي شود. در صورت نياز به پوسته‌ ، از /bin/sh –c در POSIX يا cmd.exe در ويندوز استفاده كنيد. نسخه ‌هاي مختلفي از exec() كه خط دستور را به عنوان يك رشته تنها دريافت مي‌كنند، رشته را با استفاده از StringTokenizer تجزيه مي‌كنند. در ويندوز، اين توكن‌ها قبل از اجرا با هم تركيب شده و تشكيل يك رشته آرگومان را مي‌دهند.

در نتيجه، حملات تزريق فرمان به جز در مواردي كه مفسر فرمان صراحتاً فراخواني شود، نمي‌توانند موفق باشند. در حالي كه حملات تزريق آرگومان زماني اتفاق مي افتند كه آرگومان‌ها حاوي كاراكتر فاصله، نقل قول (double quotes)، و غيره باشند يا زماني كه براي نشان دادن يك سوييچ با كاراكتر "– "يا "/" آغاز شده باشند.

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


يك نمونه ناسازگار با قانون (ويندوز)

برنامه زير، مثالي از فهرست كردن دايركتوري با استفاده از دستور cmd است. اينكار با استفاده از Runtime.exec() براي فراخواني دستور dir پياده سازي شده است.

بدليل اينكه Runtime.exec() داده پاكسازي نشده‌اي را از محيط مي‌گيرد، اين برنامه مستعد حمله تزريق فرمان است. مهاجم مي‌تواند با استفاده از دستور زير از برنامه سوء استفاده كند.

Java –Ddir= ‘dummy & echo bad’ Java

برنامه‌اي كه اجرا مي‌شود دو دستور دارد:

Cmd.exe /C dir dummy & echo bad

كه ابتدا تلاش بر فهرست كردن فولدر dummy كه وجود ندارد مي‌كند و سپس bad را در كنسول مي‌نويسد.

يك نمونه ناسازگار با قانون (POSIX)

برنامه ناسازگار زير عملكرد مشابهي با نمونه بالا دارد و فقط از دستور ls در POSIX استفاده شده است. تنها تفاوت نسبت به نسخه ويندوزي، آرگوماني است كه به Runtime.exec() ارسال گرديده است.


دستوري كه اجرا مي‌شود به صورت زير است:

Sh –c ‘ls dummy & echo bad’

راه حل سازگار با قانون (پاكسازي)

اين راه حل سازگار، ورودي نامطمئن كاربر را پاكسازي ميكند و اين كار را از طريق پذيرش گروهي از كاراكترهاي ليست سفيد در آرگومان ارسالي به Runtime.exec() انجام ميدهد؛ ساير كاراكترها در نظر گرفته نمي‌شوند.


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

راه حل سازگار با قانون (محدوديت در انتخاب كاربر)

اين راه حل سازگار، از طريق ارسال رشته‌هاي مورد اعتماد به Runtime.exec()، از تزريق فرمان جلوگيري مي‌كند. كاربر روي اينكه كدام رشته استفاده شده است كنترل دارد اما نمي تواند مستقيماً رشته اي براي Runtime.exec() فراهم كند.

در اين راه حل سازگار، دايركتوري‌هايي كه ممكن است فهرست شود در متن برنامه قرار گرفته است.

اين راه حل، درصورتي كه تعداد زيادي دايركتوري وجود داشته باشد به سرعت غيرقابل مديريت خواهد شد. راه حل ديگر، خواندن تمام دايركتوري‌هاي مجاز از properties file در شي java.util.Properties است.

راه حل سازگار با قانون (اجتناب از Runtime.exec())

زماني كه فعاليت انجام شده توسط دستور سيستمي (system command) قابليت انجام از طرق ديگر را نيز دارد، توصيه مي شود از روشهايي به جز دستور سيستمي استفاده شود.

اين راه حل سازگاري از متد File.list() براي فهرست كردن دايركتوري و حذف احتمال حملات تزريق آرگومان و فرمان استفاده مي‌كند.

ارزيابي خطر

ارسال داده نامطمئن و پاكسازي نشده به متد Runtime.exec() مي‌تواند منجر به حملات تزريق آرگومان و فرمان شود.


تشخيص اتوماتيك

مطالب مرتبط:
برنامه‌نويسي امن با زبان جاوا - آشنايي

برنامه‌نويسي امن با زبان جاوا - اعتبارسنجي ورودي و پاكسازي داده‌ها

برنامه‌نويسي امن با زبان جاوا – نشت اطلاعات حساس
برنامه‌نويسي امن با زبان جاوا – نشت قابليت ها
برنامه‌نويسي امن با زبان جاوا – انكار سرويس
برنامه‌نويسي امن با زبان جاوا – ارتقاي حقدسترسي

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجيورودي و پاكسازي داده‌ها - آشنايي

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS00-J – قسمت دوم

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS00-J – قسمت اول

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS01-J

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS02-J

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS03-J

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS04-J

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS05-J

برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون IDS06-J

منبع:

1 آذر 1387 برچسب‌ها: مستندات مرجع
امنيت SQL Server – قسمت دهم – تخصيص مجوزهاي سطح ركورد و ايجاد نقش‌هاي برنامه كاربردي

شماره :IRCAR201409231

تاريخ: 18/6/93
1- مقدمه
SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد.
هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند.
اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند.
ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد.
حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است.
در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي، مديريت مجوزها با استفاده از روال‌هاي ذخيره شده، نوشتن SQL پوياي امن و امضاي روال‌هاي ذخيره شده و جعل هويت در SQL Server پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به تخصيص مجوزهاي سطح ركورد و ايجاد نقش‌هاي برنامه كاربردي مي‌پردازد.
2- تخصيص مجوزهاي سطح ركورد در SQL Server
در برخي سناريوها، نياز به كنترل دسترسي در سطح ريزتر و پايين‌تري وجود دارد. براي مثال، يك برنامه پايگاه داده بيمارستاني ممكن است اطلاعات تمامي بيماران را در يك جدول ذخيره كند. در عين حال ممكن است نياز باشد كه پزشكان فقط به مشاهده اطلاعات مربوط به بيمار خودشان محدود باشند. سناريوهاي مشابهي در محيط‌هاي مختلف از جمله برنامه‌هاي مالي، قانوني، دولتي و نظامي وجود دارند. البته SQL Server پياده‌سازي امنيت سطح ركورد را پشتيباني نمي‌كند. در نتيجه شما بايد ستون‌هاي اضافه‌اي در جداول خود ايجاد كنيد كه مكانيزم‌هاي فيلتر كردن ركوردها را تعريف نمايند.
2-1- پياده‌سازي مجوزهاي سطح ركورد
مجوزهاي سطح ركورد براي برنامه‌هايي مورد استفاده قرار مي‌گيرند كه اطلاعات را در يك جدول ذخيره مي‌نمايند. هر ركورد داراي ستوني است كه پارامتري را تعريف مي‌كند كه بين ركوردهاي مختلف تفاوت ايجاد مي‌كند. اين پارامتر مي‌تواند كلمه كاربري، برچسب يا هر شناسه ديگري باشد. سپس شما روال‌هاي ذخيره شده پارامتري را ايجاد مي‌كنيد و مقادير مناسب را به آنها ارسال مي‌نماييد. كاربران مي‌توانند صرفاً ركوردهايي را مشاهده نمايند كه با مقدار مورد نظر تطابق داشته باشند.
مراحل زير نحوه پيكربندي مجوزهاي سطح ركوردرا بر اساس نام كاربري يا نام لاگين شرح مي‌دهد:
  • جدول را ايجاد كرده و ستون اضافه‌اي براي ذخيره كردن نام به آن بيفزاييد.
  • View ي ايجاد كنيد كه داراي يك عبارت WHERE بر اساس ستون نام كاربر باشد. اين كار ركوردهاي بازگشت داده شده را به ركوردهايي كه اين ستون آنها داراي مقدار مورد نظر شماست محدود مي‌سازد. از يكي از توابع دروني براي مشخص كردن نام كاربري يا لاگين پايگاه داده استفاده كنيد. اين كار نياز به ايجاد view هاي مختلفي براي كاربران مختلف را از بين مي‌برد.
نام شناسه لاگين كاربر را باز مي‌گرداند:
WHERE UserName = SUSER_SNAME()
USER_NAME يا CURRENT_USER، نام كاربر پايگاه داده را بازمي‌گرداند:
WHERE UserName = CURRENT_USER()
  • روال‌هاي ذخيره شده را براي انتخاب، افزودن، به روز رساني و حذف داده‌ها بر اساس view و نه بر اساس جداول پايه ايجاد كنيد. اين view فيلتري را فراهم مي‌كند كه ركوردهاي بازگشتي يا تغيير يافته را محدود مي‌سازد.
  • براي روال‌هاي ذخيره شده‌اي كه داده‌ها را اضافه مي‌كنند، نام كاربري را با استفاده از همان تابع مشخص شده در عبارت WHERE به دست آورده و مقدار آن را به ستون UserName اضافه كنيد.
  • تمامي مجوزها بر روي جداول و مشاهده‌ها را براي نقش عمومي ابطال نماييد. كاربران قادر نخواهند بود مجوزها را از ساير نقش‌هاي پايگاه داده به ارث ببرند، زيرا عبارت WHERE بر اساس نام‌هاي كاربري يا لاگين و نه بر اساس نقش‌ها ساخته شده است.
  • مجوز EXECUTE را بر روي روال‌هاي ذخيره شده براي نقش‌هاي پايگاه داده تخصيص دهيد. كاربران فقط مي‌توانند از طريق روال‌هاي ذخيره شده ارائه شده به داده‌ها دسترسي پيدا كنند.
3- ايجاد نقش‌هاي برنامه كاربردي در SQL Server
نقش‌هاي برنامه كاربردي راهي براي تخصيص مجوزها به يك برنامه كاربردي به جاي نقش يا كاربر پايگاه داده فراهم مي‌كنند. كاربران مي‌توانند به پايگاه داده وصل شوند، نقش برنامه كاربردي را فعال نمايند، و مجوزهاي تخصيص داده شده به برنامه كاربردي را دريافت نمايند. مجوزهاي تخصيص يافته به نقش برنامه كاربردي در طول مدت ارتباط اعمال مي‌شوند.
نكته امنيتي
نقش‌هاي برنامه كاربردي هنگامي فعال مي‌شوند كه يك برنامه كلاينت، يك نام نقش برنامه كاربردي و يك كلمه عبور را در رشته اتصال خود بگنجاند. از آنجاييكه كلمه عبور بايد بر روي سيستم كلاينت ذخيره گردد، يك آسيب‌پذيري امنيتي در برنامه كاربردي دو طرفه ايجاد مي‌شود. در يك برنامه سه طرفه، شما مي‌توانيد كلمه عبور را طوري ذخيره نماييد كه كاربران برنامه كاربردي به آن دسترسي نداشته باشند.
3-1- ويژگي‌هاي نقش برنامه كاربردي
نقش‌هاي برنامه كاربردي داراي ويژگي‌هاي زير هستند:
  • برخلاف نقش‌هاي پايگاه داده، نقش‌هاي برنامه كاربردي شامل هيچ عضوي نيستند.
  • نقش‌هاي برنامه كاربردي زماني فعال مي‌شوند كه يك برنامه كاربردي، نام نقش برنامه كاربردي و يك كلمه عبور را براي روال ذخير شده سيستمي sp_setapprole تأمين نمايد.
  • كلمه عبور بايدروي سيستم كلاينت ذخيره شده و در زمان اجرا ارائه گردد. يك نقش برنامه كاربردي نمي‌تواند از درون SQL Server فعال گردد.
  • كلمه عبور رمز شده نيست. كلمه عبور پارامتر به صورت يك hash يك طرفه ذخيره مي‌گردد.
  • زماني كه نقش برنامه كاربردي فعال مي‌شود، مجوزهاي بدست آمده از طريق نقش برنامه كاربردي در طول مدت اتصال باقي مي‌مانند.
  • نقش برنامه كاربردي مجوزهاي تخصيص يافته به نقش عمومي را به ارث مي‌برد.
  • اگر يك عضو نقش سروري ثابت sysadmin، يك نقش برنامه كاربردي را فعال كند، بستر امنيتي براي مدت اتصال به بستر نقش برنامه كاربردي تغيير مي‌يابد.
  • اگر شما يك حساب مهمان در يك پايگاه داده ايجاد كنيد كه يك نقش برنامه كاربردي داشته باشد، نيازي به ايجاد يك حساب كاربر پايگاه داده براي نقش برنامه كاربردي يا براي هريك از لاگين‌هايي كه آن را خواسته‌اند نداريد. نقش‌هاي پايگاه داده فقط درصورتي مي‌توانند مستقيماً به پايگاه داده ديگري دسترسي يابند كه يك حساب مهمان در پايگاه داده دوم وجود داشته باشد.
  • توابع دروني كه نام‌هاي لاگين را بازمي‌گردانند (مانند SYSTEM_USER)، نام لاگيني را كه نقش برنامه كاربردي را درخواست كرده است بازمي‌گردانند. توابع دروني كه نام‌هاي كاربر پايگاه داده را بازمي‌گردانند، نام نقش برنامه كابردي را بازمي‌گردانند.
3-2- اصل حداقل دسترسي
نقش‌هاي برنامه كاربردي بايد فقط مجوزهاي مورد نياز را دريافت كنند. مجوزهاي نقش عمومي بايد در هر پايگاه داده‌اي كه از نقش برنامه كاربردي استفاده مي‌كند ابطال گردند. حساب مهمان را در هر پايگاه داده‌اي كه نمي‌خواهيد فراخوانندگان نقش برنامه كاربردي به آن دسترسي يابند، غير فعال نماييد.
3-3- بهبودهاي نقش برنامه كاربردي
بستر اجرا مي‌تواند پس از فعال سازي يك نقش برنامه كاربردي به فراخواننده اصلي بازگردد تا نيازي به غيرفعال كردن connection pooling نباشد. روال sp_setapprole داراي گزينه جديدي است كه يك كوكي ايجاد مي‌كند كه شامل اطلاعات بستر در مورد فراخواننده است. شما مي‌توانيد با فراخواني روال sp_unsetapprole، نشست را بازگردانيد و كوكي را به آن ارسال نماييد.
3-4- جايگزين‌هاي نقش برنامه كاربردي
نقش‌هاي برنامه كاربردي به امنيت كلمه عبور بستگي دارند كه يك آسيب‌پذيري امنيتي بالقوه را ايجاد مي‌كند. ممكن است كلمات عبور با جاسازي شدن در كد برنامه كاربردي يا ذخيره شدن بر روي ديسك افشا گردند.
ممكن است شما مايل باشيد از روش‌هاي جايگزين ذيل استفاده نماييد:
  • از تغيير بستر با عبارت EXECUTE AS به همراه عبارات NO REVERT و WITH COOKIE استفاده نماييد. شما مي‌توانيد يك حساب كاربري در پايگاه داده‌اي ايجاد كنيد كه به هيچ لاگيني نگاشت نشده است. سپس شما مجوزها را به اين حساب تخصيص مي‌دهيد. استفاده از EXECUTE AS با يك كاربر بدون لاگين امن‌تر است، چرا كه مبتني بر مجوز است نه مبتني بر كلمه عبور.
  • روال‌هاي ذخيره شده را با گواهينامه‌ها امضا كنيد و صرفاً مجوز اجراي روال‌ها را صادر كنيد.
1 آذر 1387 برچسب‌ها: مستندات مرجع
صفحات: «« « ... 31 32 33 34 35