‫ اخبار

شماره :IRCAR201409233

تاريخ: 29/6/93

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 مجوزهاي شيء مقصد را مورد بررسي قرار نمي‌دهد.

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

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

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

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

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

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

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

2-3- SQL پويا

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

شماره : IRCAR201409232

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

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

Sh –c ‘ls dummy & echo bad’

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

شماره :IRCAR201409231

• جدول را ايجاد كرده و ستون اضافه‌اي براي ذخيره كردن نام به آن بيفزاييد.
• View ي ايجاد كنيد كه داراي يك عبارت WHERE بر اساس ستون نام كاربر باشد. اين كار ركوردهاي بازگشت داده شده را به ركوردهايي كه اين ستون آنها داراي مقدار مورد نظر شماست محدود مي‌سازد. از يكي از توابع دروني براي مشخص كردن نام كاربري يا لاگين پايگاه داده استفاده كنيد. اين كار نياز به ايجاد view هاي مختلفي براي كاربران مختلف را از بين مي‌برد.

• روال‌هاي ذخيره شده را براي انتخاب، افزودن، به روز رساني و حذف داده‌ها بر اساس view و نه بر اساس جداول پايه ايجاد كنيد. اين view فيلتري را فراهم مي‌كند كه ركوردهاي بازگشتي يا تغيير يافته را محدود مي‌سازد.
• براي روال‌هاي ذخيره شده‌اي كه داده‌ها را اضافه مي‌كنند، نام كاربري را با استفاده از همان تابع مشخص شده در عبارت WHERE به دست آورده و مقدار آن را به ستون UserName اضافه كنيد.
• تمامي مجوزها بر روي جداول و مشاهده‌ها را براي نقش عمومي ابطال نماييد. كاربران قادر نخواهند بود مجوزها را از ساير نقش‌هاي پايگاه داده به ارث ببرند، زيرا عبارت WHERE بر اساس نام‌هاي كاربري يا لاگين و نه بر اساس نقش‌ها ساخته شده است.
• مجوز EXECUTE را بر روي روال‌هاي ذخيره شده براي نقش‌هاي پايگاه داده تخصيص دهيد. كاربران فقط مي‌توانند از طريق روال‌هاي ذخيره شده ارائه شده به داده‌ها دسترسي پيدا كنند.

• برخلاف نقش‌هاي پايگاه داده، نقش‌هاي برنامه كاربردي شامل هيچ عضوي نيستند.
• نقش‌هاي برنامه كاربردي زماني فعال مي‌شوند كه يك برنامه كاربردي، نام نقش برنامه كاربردي و يك كلمه عبور را براي روال ذخير شده سيستمي sp_setapprole تأمين نمايد.
• كلمه عبور بايدروي سيستم كلاينت ذخيره شده و در زمان اجرا ارائه گردد. يك نقش برنامه كاربردي نمي‌تواند از درون SQL Server فعال گردد.
• كلمه عبور رمز شده نيست. كلمه عبور پارامتر به صورت يك hash يك طرفه ذخيره مي‌گردد.
• زماني كه نقش برنامه كاربردي فعال مي‌شود، مجوزهاي بدست آمده از طريق نقش برنامه كاربردي در طول مدت اتصال باقي مي‌مانند.
• نقش برنامه كاربردي مجوزهاي تخصيص يافته به نقش عمومي را به ارث مي‌برد.
• اگر يك عضو نقش سروري ثابت sysadmin، يك نقش برنامه كاربردي را فعال كند، بستر امنيتي براي مدت اتصال به بستر نقش برنامه كاربردي تغيير مي‌يابد.
• اگر شما يك حساب مهمان در يك پايگاه داده ايجاد كنيد كه يك نقش برنامه كاربردي داشته باشد، نيازي به ايجاد يك حساب كاربر پايگاه داده براي نقش برنامه كاربردي يا براي هريك از لاگين‌هايي كه آن را خواسته‌اند نداريد. نقش‌هاي پايگاه داده فقط درصورتي مي‌توانند مستقيماً به پايگاه داده ديگري دسترسي يابند كه يك حساب مهمان در پايگاه داده دوم وجود داشته باشد.
• توابع دروني كه نام‌هاي لاگين را بازمي‌گردانند (مانند SYSTEM_USER)، نام لاگيني را كه نقش برنامه كاربردي را درخواست كرده است بازمي‌گردانند. توابع دروني كه نام‌هاي كاربر پايگاه داده را بازمي‌گردانند، نام نقش برنامه كابردي را بازمي‌گردانند.

• از تغيير بستر با عبارت EXECUTE AS به همراه عبارات NO REVERT و WITH COOKIE استفاده نماييد. شما مي‌توانيد يك حساب كاربري در پايگاه داده‌اي ايجاد كنيد كه به هيچ لاگيني نگاشت نشده است. سپس شما مجوزها را به اين حساب تخصيص مي‌دهيد. استفاده از EXECUTE AS با يك كاربر بدون لاگين امن‌تر است، چرا كه مبتني بر مجوز است نه مبتني بر كلمه عبور.
• روال‌هاي ذخيره شده را با گواهينامه‌ها امضا كنيد و صرفاً مجوز اجراي روال‌ها را صادر كنيد.