فا

‫ اخبار

صفحات: «« « ... 32 33 34 35 36
برنامه‌نويسي امن با زبان جاوا – قوانين اعتبارسنجي ورودي و پاكسازي داده‌ها – قانون 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 برچسب‌ها: مستندات مرجع
صفحات: «« « ... 32 33 34 35 36