امنیت وب 2 - بررسی چند اصل در امنیت نرم افزار

در این بلاگ خواهیم دید برای تامین امنیت سیستم نرم افزاری خود چه اصولی را باید رعایت کنیم. یعنی همواره در تصمیم گیری ها و ارائه و پیاده سازی راهکارهای نرم افزاری باید این اصول را برای رسیدن به سطوح بالای امنیت، مبنای کار خود قرار دهیم. اما نکته مهمی که لازم است در ایجاد امنیت، مد نظر قرار دهیم این حقیقت است که:

اصل اول: امنیت کامل، دست نیافتنی است

دنیس هیوز اولین رئیس بخش تحقیقات کامپیوتری FBI، زمانی در گفتگویی اشاره کرد: «تنها کامپیوتر امنی که وجود دارد، همان است که از برق کشیده شده، قفل محکمی به آن زده شده و در قبری در عمق 6 متری زمین در یک مکان مخفی خاک شده است... و من باز هم خیالم از بابت امنیتش راحت نیست.»
شاید تاکنون حداقل یکی از فیلم های سینمایی ژانر سرقت را دیده باشید. 11 یار اوشن (Ocean’s 11)، مخمصه (Heat) و شغل ایتالیایی (The Italian Job) فیلم های مشهور این ژانر هستند. نکته ای در تمام این فیلم ها به طور مشترک می بینید، عده ای هستند، که تصور می کنند تمام نکات امنیتی لازم را پوشش داده اند و هیچ راهی برای نفوذ سارقان باقی نمانده است. اما در نهایت، همیشه نقطه ای از دید آن ها جا مانده که باعث انبساط هیجانات ما می شود. سکانس مشهور آویزان شدن تام کروز از سقف یک اتاق فوق امنیتی، برای دستیابی به کامپیوتر CIA را به یاد بیاورید. درست مانند همین فیلم ها هیچ گاه امنیت 100% برقرار نخواهد شد.

Zero-Day Exploit

نوع جدیدی از آسیب پذیری با نام Zero-day Exploit وجود دارد که این آسیب پذیری ها در شبکه های ارتباطی میان هکرها به اشتراک گذاشته شده است اما تا حد امکان از دسترس برنامه نویسان، مخفی نگه داشته می شوند. این اکسپلویت (کدی که هکر بعد از کشف یا ایجاد حفره امنیتی، برای سوء استفاده از حفره های امنیتی نرم افزار می نویسد.) درست مانند یک راه مخفی به سیستم است. در صورتی که برنامه نویسان از وجود این آسیب پذیری آگاه شوند، فورا در مخفی را می بندند. قطعا در حال حاضر ماموران CIA حواسشان به سقف اتاق کامپیوتر هست که تام کروزی از آن آویزان نباشد. اما پیش از آن نمی دانستند چنین راهی هم وجود دارد. نام Zero-Day Exploit بر این حقیقت استوار است که برنامه نویسان تاکنون از وجود این آسیب پذیری ها مطلع نشده اند و فقط صفر روز فرصت داشته اند تا آن را اصلاح کنند.

ضعیف ترین حلقه

وقتی می گوییم یک سیستم امن است، یعنی تمام اقدامات پیشگیرانه را در مقابل تمام نفوذهایی که تاکنون شناخته ایم، انجام داده ایم. امنیت، موضوع ضعیف ترین حلقه اتصال در یک زنجیره از حلقه هاست. در امنیت وب 1 به این موضوع اشاره شد که سطح قدرت ایمنی یک زنجیره به اندازه ضعیف ترین حلقه اتصال است. در زمینه وب، این زنجیره دائما در حال تغییر است.
اگر در یک وب سایت، امنیت بخش های مختلف را از 1 تا 10 نمره دهید و اغلب بخش ها دارای نمره 9 باشند و برخی از قسمت ها 7، آن وقت، امتیاز امنیت وب سایت شما از 10 نمره، 7 است.

اگر زمانی تصمیم بگیرید از تکنولوژی جدیدی استفاده کنید که تسلط کافی روی آن ندارید، ممکن است امنیت آن را 4 تخمین بزنید. اما متاسفانه امنیت وب سایت شما هم در مجموع 4 است.

تازه این در مورد دانسته های شماست. اگر جنبه ای از وب سایت را به نسخه ای upgrade کنید که دارای یک Zero-Day Exploit باشد، آن وقت امنیت کلی وب سایت شما تا حد آن اکسپلویت کاهش می یابد.

تا چه حد ایمنی نیاز است؟

اگر شما 100 هزار تومان داشته باشید، همین که آن را در کمد خانه بگذارید و از قفل بودن درب ها مطمئن شوید، برایتان کافیست و نیازی به ساختن یک بنای امنیتی برای آن ندارید. اما وقتی صحبت از 100 میلیون تومان شود، آن وقت باید به فکر یک مکان امن تر برای آن باشید.

• پس پیش از هر چیز باید میزان امنیت مورد نیاز خود را بسنجید. هزینه نفر/ساعت صرف شده بر روی ایجاد امنیت را در مقابل ضرری که در ازای عدم امنیت آن و شکستن سیستم در آن نقطه متحمل می شوید، قرار دهید تا ببینید چه میزان امنیت نیاز دارید.
• وقتی میزان امنیت مورد نظر را یافتید، از اجرای کامل آن مطمئن شوید.
• میزان امنیت مورد نیاز خود را هر چند وقت یک بار، مجدد بررسی کنید.

اصل دوم: حداقل دسترسی یا least privilege

به آپارتمان خود فکر کنید. کلید آپارتمانتان را به چه کسانی می دهید؟

قطعا در میان آشنایان و دوستان شما کسانی هستند که ممکن است ما کلید خانه خود را با آسودگی در اختیار ایشان قرار دهیم. اما قطعا آن را به تمام دوستان و آشنایانمان نمی دهیم. این روش را به صورت یک قاعده برای تمام دارایی هایمان به کار می بریم. اما وقتی در وب با مقوله مشابه این برخورد می کنیم، آنقدرها آن را جدی نمی گیریم. تا جاییکه به همه دسترسی کامل می دهیم. ما این کار را می کنیم به دلیل رفتار دوستانه ای که با آن ها داریم و اینکه می دانیم آن ها قصد آسیب زدن به ما را ندارند. در حالیکه در مورد کلید خانه چنین عرفی نداریم.
طبق اصل حداقل دسترسی یا همان Least Privilege «هر برنامه و هر کاربر سیستم باید حداقل دسترسی ممکن را برای انجام عملیات خود داشته باشد». این یعنی هر کاربر فقط باید دسترسی لازم برای انجام کار خودش را داشته باشد. کاربری که قرار است ورود محتوا کند، نباید به اطلاعات جداول سیستم دسترسی داشته باشد و کاربری با دسترسی محدود نباید بتواند دسترسی خود را افزایش دهد. اما اصل حداقل دسترسی علاوه بر کاربر، به برنامه هم اشاره دارد. کد ها باید در دسترسی به اطلاعات و در نمایش آن ها محدود شوند.
 به عنوان مثال در تصویر بالا، دو متغیر و یکی از توابع نباید به صورت public تعریف شوند، زیرا فقط قرار است داخل کلاس استفاده شوند. تنها تابعی که از کلاس های دیگر یا نمونه های ایجاد شده از این کلاس باید قابل دسترسی باشد، تابع authenticate است که می تواند public در نظر گرفته شود. بنابراین تنها کاری که باید کرد این است که سایر public ها را به private تغییر دهیم.
مزیت رعایت اصل حداقل دسترسی یا Least Priviledge این است که:

1. پایداری کد بیشتر می شود: چرا که دسترسی به داده ها کنترل شده است و تست عملیات و تعاملات سیستم راحت تر انجام می شود.
2. امنیت سیستم بالاتر می رود: زیرا آسیب پذیری در مقیاس محدود رخ داده و ایرادات به صورت local بروز می دهند. هم چنین در صورتی که هکر به توابع دسترسی پیدا کند، گزینه های او را محدودتر کرده ایم.

پس «هر برنامه و هر کاربر سیستم باید حداقل دسترسی ممکن را برای انجام عملیات خود داشته باشد». این اصل به شکل یک راهنما در تمامی مباحث امنیتی قابل استفاده است و توجه به آن بسیار ضروری است.

اصل سوم: هر چه ساده تر، امن تر

امنیت کدام یک ازین دو خانه راحت تر برقرار می شود؟ یک خانه با یک درب در کنار خانه ای با چندین درب و پنجره؟
 واضح است که خانه ای با یک درب را راحت تر می توان ایمن کرد. در سیستم هم به همین شکل هر چقدر یک سیستم بزرگ تر و پیچیده تر باشد، برقراری امنیت آن دشوارتر خواهد بود. در سیستم های بزرگ بخش هایی که باید نگران امنیت آن باشیم بیشتر است و سیستم های پیچیده، احتمال بروز خطا و اشتباه را بیشتر می کنند. پس ساده تر همواره امن تر است.
این قاعده به KISS (Keep It Simple, Stupid!) هم شهرت دارد.
در برنامه نویسی راه های مختلفی برای تولید برنامه ساده تر وجود دارد:

• استفاده از عناوین واضح و ساده برای توابع و متغیرها که خوانایی کد را بالاتر ببرد و قابل فهم تر شود.
• کامنت گذاری در کد. ممکن است بخواهید دلیل استفاده از راهکار پیش رو را بنویسید و یا در مورد دغدغه های امنیتی قابل توجه در آن بخش برای توسعه دهندگان بعدی توضیح دهید.
• بخش های طولانی کد را به توابع کوتاه تر تبدیل کنید.
• از تکرار بپرهیزید. برنامه نویسی شی گرا راه حل مناسبی برای جلوگیری از تکرار است. اگر در قسمتی خطایی مشاهده شود، احتمال آنکه خطا را فقط در یکی از بخش ها برطرف کنید و اصلاح آن در سایر بخش ها را فراموش کنید، وجود دارد.
• کدهای موروثی (کدهایی که برای پشتیبانی کردن پلتفرم های قدیمی تر، در برنامه خود می گنجانیم)، یکی از دغدغه های امنیتی است که ممکن است یک backdoor باشند.
• استفاده از توابع built-in. برای مثال در کنتیکو استفاده از api های موجود در solution، امنیت سیستم را نسبت به آنکه بخواهیم خودمان یک تابع را از ابتدا بنویسیم، بیشتر تامین می کند.
• پاکسازی یا غیرفعال کردن feature های بلااستفاده. اگر library ای در کد بارگذاری شده که مدت هاست در کد استفاده نشده است، بهتر است آن را یک تهدید امنیتی تلقی نمایید و حذف کنید. در نصب windows یا IIS یا SQL server اگر قرار نیست از ویژگی ای استفاده نماییم، بهتر است آن را غیرفعال باقی بگذاریم. اگر به مثال خانه بازگردیم؛ چه چیزی امن تر از یک درب بسته است؟ طبیعتا نبود درب.

پس بهتر است این اصل را هم در ذهن خود نهادینه کنیم که «Simple is more secure».
در آینده با ادامه مباحث امنیت وب با ما همراه باشید...