رتبه موضوع:
  • 0 رای - 0 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
آشنایی با استاندارد CERT برای برنامه نویسی امن
#1
در این ازسال ها در باره برنامه نویسی امن با زبان برنامه نویسی C صحبت خواهیم کرد

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

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

منبع
[عکس: <a href=www.Mojsazan.com.gif]" class="mycode_img" />
پاسخ
سپاس شده توسط علی عرفانی ، pishdad
#2
عنصر اصلی در كدنویسی امن با زبان های مختلف برنامه نویسی، مستند سازی خوب و استفاده از استانداردهای قابل اجرا است. استانداردهای كدنویسی، برنامه نویسان را ترغیب به پیروی از مجموعه ای متحدالشكل از قوانین و راهنماییها می كند كه بر اساس نیازمندی های پروژه و سازمان تعیین شده است، نه بر اساس سلایق و مهارت های مختلف برنامه نویسان. به محض تعیین استانداردهای مذكور، می توان از آن به عنوان معیاری برای ارزیابی كدهای منبع، چه به صورت دستی و چه به صورت اتوماتیك استفاده كرد.

از استانداردهای معروف در این زمینه می توان به استاندارد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
[عکس: severity.jpg]


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

[عکس: likelihood.jpg]

هزینه ترمیم

[عکس: remedation%20costs.jpg]

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

[عکس: levels_circle.jpg]

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

در مقاله های بعدی در مورد كد نویسی امن در C، C++ و جاوا با توجه به استاندارد برنامه نویسی امن CERT صحبت خواهیم كرد.
منبع
[عکس: <a href=www.Mojsazan.com.gif]" class="mycode_img" />
پاسخ
سپاس شده توسط علی عرفانی


موضوعات مشابه ...
موضوع نویسنده پاسخ بازدید آخرین ارسال
Tongue برنامه‌نویسی امن با زبان جاوا – ارتقای حق دسترسی علی عرفانی 0 2,726 09-14-2013, 10:13 PM
آخرین ارسال: علی عرفانی
Tongue برنامه‌نویسی امن با زبان جاوا – انكار سرویس علی عرفانی 0 2,749 09-14-2013, 10:07 PM
آخرین ارسال: علی عرفانی
Tongue برنامه‌نویسی امن با زبان جاوا – نشت قابلیت ها علی عرفانی 0 2,802 09-14-2013, 10:01 PM
آخرین ارسال: علی عرفانی
Tongue برنامه‌نویسی امن با زبان جاوا – نشت اطلاعات حساس علی عرفانی 0 2,742 09-08-2013, 02:19 PM
آخرین ارسال: علی عرفانی
Tongue برنامه‌نویسی امن با زبان جاوا - اعتبارسنجی ورودی و پاكسازی داده‌ها علی عرفانی 0 2,682 09-02-2013, 02:11 AM
آخرین ارسال: علی عرفانی
Tongue برنامه‌ نویسی امن با زبان جاوا - آشنایی علی عرفانی 0 2,841 08-29-2013, 04:27 PM
آخرین ارسال: علی عرفانی
  پیاده سازی برنامه client و server با زبان C آیناز محمدی 1 5,501 12-22-2010, 11:31 PM
آخرین ارسال: مهرداد عباسی

پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان