خطرناک ترین 25 خطای برنامه نویسی- قسمت سوم

در بخش اول گزارش اشاره کردیم که متخصصان 30 شرکت فعال در زمینه امنیت رایانه با یکدیگر همکاری کرده اند تا لیستی از مهم ترین و خطرناک ترین خطاهای برنامه نویسی را تهیه کنند.
25 خطای خطرناک به سه گروه تقسیم شده اند:

1. تعامل نا امن بین اجزای برنامه (9 خطا)
   کاستی های این قسمت مربوط به روش های نا امن ارسال و دریافت داده بین اجزا، ماژول ها، برنامه ها، پردازه ها و رشته های یک نرم افزار و یا در تعامل با سیستم است.
2. مدیریت پر خطر منابع (9 خطا)
   کاستی های این قسمت مربوط به مدیریت نامناسب ایجاد، استفاده، انتقال و یا از بین بردن منابع مهم سیستمی است.
3. دفاع پرخلل (7 خطا)
   کاستی های این قسمت مربوط به استراتژی های دفاعی است که اغلب بد استفاده می شوند و یا به راحتی نادیده انگاشته می شوند.

در قسمت اول به خطاهای بخش اول یعنی تعامل ناامن بین اجزای برنامه پرداختیم و در قسمت دوم گزارش بخش مدیریت پرخطر منابع را بررسی کردیم. در این قسمت به بررسی خطاهای بخش سوم یعنی دفاع پرخلل خواهیم پرداخت.

دفاع پرخلل

• کنترل دسترسی نامناسب (تأیید کردن)
  در صورتی که مطمئن نشوید کاربران شما دقیقاً توانایی همان کاری را دارند که برای آنها در نظر گرفته شده است و نه بیشتر، آنگاه مهاجمان از کنترل دسترسی نامناسب شما سوء استفاده کرده و به کارهایی دست می زنند که شما تنها به کاربران محدودی اجازه اجرای آنها را داده اید.
• استفاده از الگوریتمهای رمزگذاری پرخطر یا شکسته شده
  در صورتی که کار شما با داده های حساس است و یا لازم است از یک کانال ارتباطی محافظت به عمل آورید، نیاز به رمز گذاری پیدا می کنید تا دست مهاجمان را از برنامه تان کوتاه کنید. شما هم مانند بسیاری از نرم افزار نویسان علاقه دارید خودتان یک الگوی رمزگذاری را اختراع کنید تا احتمال حدس زدن آن توسط مهاجمان را کاهش دهید. این کار شما یک جور خوشامدگویی به مهاجمان محسوب می شود. رمزگذاری کار بسیار سختی است و جایی که نابغه های ریاضی و دانشمندان کامپیوتر در این کار صددرصد موفق نمی شوند، مطمئن باشید شما هم موفق نخواهید شد. ممکن است فکر کنید یک الگوریتم کاملاً جدید کشف کرده اید که هیچ کس آن را حدس نمی زند، ولی در واقع شما دوباره چرخی را اختراع کرده اید که قبلاً سقوط کرده است. بنابراین همواره هوشیار بوده و از مجموعه ای از الگوهای رمزگذاری که فعلاً شکسته نشده اند استفاده کنید.
• آوردن رمز در کد برنامه
  آوردن نام کاربری ورمز عبور محرمانه در کد برنامه و در ماژول تأیید هویت نرم افزارتان کار بسیار راحتی است و شما را از نوشتن کدهای بیشتر و اعمال بررسی ها خلاصی می دهد، ولی این کار امنیت کاربران شما را تا حد صفر کاهش می دهد و در صورتی که این رمز به طریقی لو رود دیگر مفهومی به نام امنیت برای نرم افزار شما بی معنی خواهد بود. در ضمن کشف و اصلاح این خطا برای مدیران سیستم کار راحتی نیست و مشتریان هم با این موضوع به هیچ وجه کنار نمی آیند. بنابراین اگر قادرید عصبانیت مدیر سیستم در ساعت 2 نیمه شب، زمانی که سیستمش هک شده و یا بد و بیراه مشتریان پشت خط تلفن را تحمل کنید بازهم به قرار دادن رمز عبور در کد برنامه ادامه دهید.
• مدیریت دسترسی نا امن برای منابع مهم
  درست است که برداشتن بی اجازه وسایل دیگران گستاخانه است ولی در صورتی که خود شما فایلهای تنظیمات، داده ها و برنامه های مهم را بدون محافظ رها کنید و هرکسی بتواند آنها را بخواند یا تغییر دهد، مطمئن باشید که بدون اجازه و یا حتی آگاهی شما خوانده خواهند شد و تغییر خواهند کرد. این مسئله معمولاً در زمان طراحی و پیاده سازی نادیده انگاشته می شود در حالی که برخی از اوقات تنها راه حل مشکلات ایجاد شده است. در ضمن گذاشتن مسؤولیت این امر به عهده مدیر سیستم و توقع اینکه وی تنظیمات لازم را برای حقوق دسترسی انجام دهد, کاری غیر عملی است و نتایج خوبی ندارد.
• استفاده ناقص از مقادیر تصادفی
  در صورتی که بتوان مقدار تصادفی بعدی را به درستی حدس زد، مقدار تصادفی مفهوم و کارایی خود را از دست خواهد داد. اگر شما از الگوهای امنیتی استفاده کنید که نیاز به مقادیر تصادفی دارند ولی شما آنها را به خوبی تأمین نکنید، راه مهاجمان را هموار ساخته اید. بعضی اوقات ممکن است بدون اینکه متوجه باشید از مقادیر تصادفی استفاده کنید، برای مثال زمانی که Session ID یا نام یک فایل موقتی را تولید می کنید. غالب برنامه نویسان از PRNGها یا Pseudo-Random Number Generator استفاده می کنند ولی اگر مهاجم متوجه شود شما از چه الگوریتمی استفاده کرده اید، قادر است مقدار تصادفی بعدی را حدس بزند و یک حمله موفق را با آزمایش کردن مقادیری محدود سازماندهی کند.
• اجرا با اولویتهای غیر ضروری
  شعار مرد عنکبوتی را به خاطر آورید: "قدرت بیشتر مسؤلیت بیشتر می آورد"، این مسئله در مورد برنامه های شما نیز صادق است. ممکن است نرم افزار شما برای انجام کار خاصی نیاز به حق دسترسی بالایی داشته باشد، ولی نگهداری این حق دسترسی بیشتر از حد لزوم خطراتی را متوجه کاربرانتان خواهد کرد. زمانی که شما با حق دسترسی بالا کار می کنید، برنامه شما اجازه دسترسی به منابعی را دارد که یک کاربر معمولی ندارد و مهاجم با استفاده از این امکان به منابع غیرمجاز دسترسی پیدا می کند. برای مثال اگر برنامه شما یک برنامه دیگر را بالا می آورد که در آن کاربر فایلی را باز می کند، با استفاده از حق دسترسی برنامه شما می توان به فایلهای حفاظت شده دسترسی پیدا کرد، همچنین امکان اجرای دستورات به همین ترتیب وجود دارد. حتی اگر برنامه دیگری را اجرا نکنید، آسیب پذیری های دیگری که در نرم افزار شما وجود دارند با حق دسترسی بالا عواقب ناگوارتری به بار خواهند آورد.
• اجرای امنیت طرف سرور توسط طرف کاربر
  زمانی که به طرف کاربر نرم افزار اجازه اجرای وارسی های امنیتی طرف سرور را می دهید، در واقع مهاجمان را قویتر و مشتریانتان را ضعیف تر می کنید. به یاد داشته باشید که در زیر ظاهر زیبای واسط کاربر، فقط مقداری کد قرار دارد. مهاجمان می توانند بخش کاربر برنامه شما را مهندسی معکوس کرده و برنامه خود را به جای آن قرار دهند، به طوری که ظواهر امر حفظ شود به خصوص قسمتهایی که مربوط به کنترلهای امنیتی است. نتایج این امر بسته به اینکه چه مقدار کنترل امنیتی را در طرف کاربر انجام می دهید، متفاوت است. اما هدف مهاجمان معمولاً بخشهای تأیید هویت، اجازه دادن ها و اعتبار سنجی ورودی است. از طرفی اگر بخشهای امنیتی را در طرف سرور پیاده سازی کرده اید، باید مطمئن شوید اجرای آنها فقط از طرف کاربر انجام نمی شود.