مجموعه ها


پربازدیدترین مطالب

گوشی گم شده خود را صدا بزنید، جواب می دهد بررسی حملات تزریق SQL یا SQL INJECTION و مقابله با آن در PHP و ASP.NET گوشی گمشده خود را با Android Device Manager پیدا کنید از تصویر گوشی اندرویدی خود خسته شده اید؟ بررسی حملات سرقت نشست Session Hijacking و راههای مقابله با آن بررسی حملات تزریق کد XSS یاCSS و مقابله با آن در PHP و ASP.NET حملات محرومیت از سرویس DOS و DDOS - بخش اول اجرای کدهای مخرب در سمت سرور یا Remote Code Execution حملات محرومیت از سرویس DOS و DDOS - بخش دوم از همه جای دنیا به کامپیوتر خود وصل شوید.

آخرین مطالب

5 نکته و ترفند در جستجو با گوگل که باید بدانید از همه جای دنیا به کامپیوتر خود وصل شوید. از گوشی خود پرینت بگیرید اجرای کدهای مخرب در سمت سرور یا Remote Code Execution امنیت فایل های موقت یا Security For Temporary Files بررسی حملات سرقت نشست Session Hijacking و راههای مقابله با آن بررسی حملات تزریق SQL یا SQL INJECTION و مقابله با آن در PHP و ASP.NET بررسی حملات تزریق کد XSS یاCSS و مقابله با آن در PHP و ASP.NET حملات محرومیت از سرویس DOS و DDOS - بخش دوم حملات محرومیت از سرویس DOS و DDOS - بخش اول

5 پیشنهاد را در برنامه نویسی امن در نظر بگیرید

5 پیشنهاد را در برنامه نویسی امن در نظر بگیرید

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

به هر حال 5 پیشنهاد و موضوع وجود دارد که اگر یک برنامه نویس به آنها توجه کند مطمئنا می تواند با بحث امنیت نسبی برنامه ها کنار بیاید. این 5 مورد عبارتند از:

1-هیچ چیز 100% امن نیست

2-به ورودی های کاربران نباید اعتماد کرد

3-یک خط دفاعی قدرتمند به تنهایی کافی نیست

4-برقراری امنیت در ساختارهای ساده تر، راحتتر است

5-بررسی دقیقتر، نقدی بر امنیت سیستم است

 

هیچ چیز 100% امن نیست

شوخی قدیمی وجود دارد که می گوید اگر می خواهید کامپیوتری امن داشته باشید آنرا در صندوقی فولادی قرار داده، تمامی خطوط ارتباطی به آن را قطع نموده، در پناهگاهی قرار دهید و نگهبانانی مسلح را استخدام کنید تا از آن مراقبت نمایند! جالب اینجاست که چنین کامپیوتری غیر قابل استقاده است!!!

واقعیت این است که هیچ کس نمی تواند برنامه ای 100% امن که بتوان از آن برای ارتباط نیز استفاده کرد بسازد یا بنویسد، این ماهیت سیستم های کامپیوتری است. ما از زمانی که کامپیوتر اختراع شده است شاهد انواع حملات بوده ایم و هرگاه حمله ای متوقف شده است، حمله ای دیگر از نوع دیگر روی داده است! پس باید این نکته را درک کنیم که امنیت موضوعی نسبی و موقتی است. در چنین حالتی ما می بایستی بر اساس آخرین اطلاعات و دستاوردهای حوزه امنیت جلو رفته و سعی کنیم همواره برنامه ها را امن تر کنیم.

- به ورودی های کاربران نباید اعتماد کرد

برنامه ای که شما نوشته اید در آغاز برنامه ای امن است البته تا وقتی پای ورودی های کاربران به میان نیآید!

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

در حالت کلی شما باید ورودی های برنامه را در درجه ای از اعتبار نگه دارید؛ برای اینکار بررسی ورودی ها، کنترل منبع ورودی ها و پنهان سازی اطلاعات کلیدی؛ ساده ترین و شاید بتوان گفت موثرترین کاری است که باید انجام گیرد.

 - یک خط دفاعی قدرتمند به تنهایی کافی نیست

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

در مقابل چنین دفاعی، دفاع لایه لایه قرار دارد که برای پیاده سازی آسانتر و نسبت به دفاع تک لایه، در مقابل شکست مقاوم تر است. ایجاد موانع و تاخیرهای مختلف که حرکت یک اخلالگر را کند و از دسترسی وی به منابع و اطلاعات با ارزش جلوگیری کند؛ یک استراتژی نظامی دفاعی کلاسیک است. برای همین بسیار مهم است که شما به جای یک لایه دفاعی قدرتمند، چندین لایه دفاعی برای انواع نفوذ و حمله پیش بینی کنید. توسعه چنین سیستمی نیز راحت است چرا که شما می توانید برای هر لایه کلاسی متفاوت طراحی و در هر کجای برنامه که خواستید از آن استفاده نمایید.

برای مثال شما می توانید یک لایه که ورودی های کاربر را برای استفاده شما امن می کند داشته باشید اما در مقابل نباید به این لایه اعتماد کامل داشته باشید و لایه ای دیگر نیز طراحی کنید تا دسترسی های کاربران را کنترل کند؛ ولی باز هم نباید به این لایه اعتماد کرد و داده ها را به حال خود گذاشت! بلکه می توان با رمزنگاری[1] داده ها از افشای سریع آنها در صورت دسترسی غیر قانونی، تا حد زیادی جلوگیری کرد.

- برقراری امنیت در ساختارهای ساده، راحت تر است

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

بررسی، استفاده مجدد و امن سازی در تکه های کوچک مختلف از sql ، php و html که با هم هوشمندانه و بصورت ماژولار[2] اجرا می شوند بسیار راحتتر است نسبت به زمانی که شما تمامی این کدها را با هم دیگر مخلوط کرده باشید.

یکی دیگر از مواردی که مشاهده می شود عدم آگاهی بسیاری از توسعه دهندگان از توابع توکار[3] زبانهای برنامه نویسی است. برای همین آنها مجبور می شوند توابعی که وجود دارند را یک بار دیگر از نوع بنویسند یا به اصطلاح چرخ را دوباره اختراع کنند! در نتیجه کنترل امنیت در توابع تازه نوشته شده نیز باری بر دوش برنامه نویس می شود و کار را سخت تر می کند.

- بررسی دقیقتر، نقدی بر امنیت سیستم است

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

واقعیت این است که اگر شما می خواهید از امنیتی که برقرار ساخته اید مطمئن شوید باید همواره آن را مورد نقد قرار دهید تا ضعف هایی که شاید در گذشته (به دلیل عدم آگاهی) وجود نداشته اند را یافته و رفع کنید.

همانطور که گفته شد امنیت چاره اندیشی موقت است و شما باید همواره این را در نظر داشته باشید و با بررسی های مداوم و دقیقتر امنیت خود و برنامه ای را که نوشته و یا توسعه داده اید را بهبود ببخشید.

 

[1] encryption

[2] modular

[3] core native functions

 


, , , , , ,

نظر بدهید: