شماره :IRCAR201407224
تاريخ: 27/4/93
1- مقدمه
SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‌شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد.
هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند.
اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند.
ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد.
حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است.
در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي و مديريت مجوزها با استفاده از روال‌هاي ذخيره شده پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به نوشتن SQL پوياي امن در SQL Server مي‌پردازد.
2- نوشتن SQL پوياي امن در SQL Server
تزريق SQL پروسه‌اي است كه در آن يك كاربر خرابكار، دستورات Transact-SQL را به جاي ورودي معتبر وارد مي‌كند. اگر ورودي مستقيماً و بدون اعتبارسنجي به سرور ارسال گردد و اگر برنامه به طور ناآگاهانه كد تزريق شده را اجرا نمايد، اين حمله پتانسيل آسيب زدن يا تخريب داده‌ها را دارا خواهد بود.
هر روالي كه دستورات SQL را مي‌سازد بايد از جهت آسيب‌پذيري‌هاي تزريق SQL مورد بازبيني قرار گيرد، چرا كه SQL Server تمامي پرس و جوهايي را كه از نظر قواعد زباني صحيح و معتبر هستند اجرا خواهد كرد. حتي داده‌هاي پارامتري شده مي‌توانند توسط يك مهاجم متخصص و مصمم دستكاري گردند. درصورتي‌كه شما از SQL پويا استفاده مي‌كنيد، اطمينان حاصل كنيد كه دستورات خود را پارامتري كرده باشيد و هرگز مقادير پارامتري را مستقيماً در رشته پرس و جو قرار ندهيد.
2-1- آناتومي يك حمله تزريق SQL
پروسه تزريق SQL با خروج ناگهاني يك رشته متني و الحاق يك دستور جديد كار مي‌كند. از آنجايي كه ممكن است رشته‌هاي ديگري پيش از اجرا به دستور الحاق شده باشد، فرد تبهكار رشته تزريق شده را با يك نشانه دستور «--» به پايان مي‌رساند. متن الحاقي در زمان اجرا ناديده گرفته مي‌شود. با استفاده از يك علامت نقطه ويرگول چندين دستور مي‌توانند به طور همزمان تزريق گردند.
تا زماني كه كد SQL تزريق شده به لحاظ دستوري صحيح باشد، فعاليت موذيانه مهاجم از ديد برنامه قابل تشخيص نخواهد بود. در نتيجه شما بايد تمامي ورودي‌هاي كاربر را اعتبارسنجي كرده و كدي را كه دستورات SQL ساخته شده را در سرور اجرا مي‌كند، به دقت مورد بازبيني قرار دهيد. هرگز ورودي كاربر را كه اعتبارسنجي نشده است به رشته دستور SQL متصل نكنيد. اتصال رشته‌ها نقطه اوليه تزريق SQL است.
در ادامه به چند راهكار مفيد اشاره مي‌كنيم:
- هرگز دستورات Transact-SQL را مستقيماً از ورودي كاربر نسازيد؛ از روال‌هاي ذخيره شده براي اعتبارسنجي ورودي كاربر استفاده كنيد.
- ورودي كاربر را با بررسي نوع، طول، فرمت و محدوده آن اعتبارسنجي نماييد. از تابع QUOTENAME() براي خلاصي از نام‌هاي سيستم يا از تابع REPLACE() براي خلاصي از هر كاراكتري در رشته استفاده كنيد.
- چندين لايه اعتبارسنجي در هر بخش برنامه خود قرار دهيد.
- اندازه و نوع داده‌اي ورودي را بررسي كنيد و محدوديت‌هاي لازم را اعمال نماييد. اين كار مي‌تواند به جلوگيري از سرريز بافر تعمدي كمك كند.
- محتويات متغيرهاي رشته‌اي را بررسي كرده و فقط مقادير مورد قبول را بپذيريد. از پذيرش ورودي‌هاي حاوي داده‌هاي باينري، فاصله‌هاي متوالي و كاراكترهاي كامنت خودداري كنيد.
- هنگاميكه با اسناد XML كار مي‌كنيد، تمامي داده‌ها را در مورد schema ي آن اعتبارسنجي كنيد.
- در محيط‌هاي چندبخشي، تمامي داده‌ها بايد پيش از پذيرش در محدوده مورد اعتماد، اعتبارسنجي گردند.
- رشته‌هاي زير را در فيلدهايي كه نام فايل‌ها از آن ساخته مي‌شود نپذيريد: AUX، CLOCK$، COM1 تا COM8، CON، CONFIG$، LPT1 تا LPT8، NUL و PRN.
- از شيء SqlParameter به همراه روال‌هاي ذخيره شده و دستورات براي بررسي و اعتبارسنجي نوع و طول استفاده كنيد.
- از عبارات Regex در كد سمت كلاينت براي فيلتر كردن ورودي‌هاي نامعتبر استفاده كنيد.
2-2- استراتژي‌هاي SQL پويا
اجراي دستورات SQL كه به شكل پويا توليد شده‌اند در كد روالي شما، زنجيره مالكيت را پاره مي‌كند و باعث مي‌شود كه SQL Server مجوزهاي فراخواننده را در مورد اشيايي كه از طريق SQL پويا مورد دسترسي قرار مي‌گيرند، بررسي نمايد.
SQL Server متدهايي براي تخصيص دسترسي كاربران به داده‌ها با استفاده از روال‌هاي ذخيره شده و توابع تعريف شده توسط كاربر دارد كه SQL پويا را اجرا مي‌كند.
- استفاده از جعل هويت با عبارت EXECUTE AS در زبان Transact-SQL
- امضاي روال‌هاي ذخيره شده با گواهينامه‌ها
هر دو مورد فوق به صورت مفصل در قسمت‌هاي آينده اين مجموعه مقالات توضيح داده خواهند شد. اكنون به شرح مختصر هريك ميپردازيم.
2-2-1- EXECUTE AS
عبارت EXECUTE AS مجوزهاي فراخواننده را با مجوزهاي كاربري كه در عبارت EXECUTE AS مشخص شده است جايگزين مي‌كند. روال‌هاي ذخيره شده تو در تو يا تريگرها، تحت مفاد امنيتي كاربر پراكسي اجرا مي‌گردند. اين مسأله مي‌تواند برنامه‌هايي را كه به امنيت سطح ركورد تكيه دارند يا نياز به مميزي دارند، دچار اختلال نمايد. برخي توابع كه هويت كاربر را بازمي‌گردانند، كاربر مشخص شده در EXECUTE AS را بازمي‌گردانند نه فراخواننده اصلي را. نتيجه اجرا فقط پس از اجراي روال يا هنگاميكه عبارت REVERT مورد استفاده قرار گيرد، به فراخواننده اصلي بازمي‌گردد.
2-2-2- امضاي گواهينامه
هنگاميكه يك روال ذخيره شده كه توسط يك گواهينامه امضاء شده اجرا مي‌گردد، مجوزهاي تخصيص داده شده به كاربر گواهينامه با مجوزهاي فراخواننده ادغام مي‌شوند. محيط اجرا يكسان باقي مي‌ماند و كاربر گواهينامه هويت فراخواننده را به خود اختصاص نمي‌دهد. امضاي روال‌هاي ذخيره شده نيازمند پياده‌سازي گام‌هاي مختلفي است. هر بار كه روال تغيير مي‌يابد، بايد مجدداً امضاء گردد.
2-2-3- دسترسي بين پايگاه‌هاي داده
زنجيره‌هاي مالكيت بين پايگاه‌هاي داده در شرايطي كه دستورات SQL به صورت پويا ساخته شده‌اند كار نمي‌كنند. شما مي‌توانيد اين مسأله را بدين صورت در SQL Server حل نماييد كه يك روال ذخيره شده كه به داده‌هاي پايگاه داده ديگر دسترسي دارد ايجاد كنيد و سپس آن روال را توسط يك گواهينامه كه در هر دو پايگاه داده وجود دارد امضاء نماييد. اين كار امكان دسترسي به منابع پايگاه داده مورد استفاده توسط روال را بدون تخصيص دسترسي يا مجوزهاي پايگاه داده، در اختيار كاربر قرار مي‌دهد.
منبع: http://msdn.microsoft.com/en-us/library/bb669074%28v=vs.110%29.aspx
- 8