نكات برنامه نويسى سيستم امنيتى ورود و شناسايى كاربر

نام نویسنده: على كريم آبادى

بخش مقاله ITiran – سيستم ورود و شناسايى كاربر مهمترين بخش يك سايت ميباشد كه سطح دسترسى و هويت كاربرى اعضا را مشخص ميكند هميشه مشكلات امنيتى در عدم توجه به نكات ريز در برنامه نويسى اين قسمت است چون سايت با اطمينان به اين سيستم ورود و شناسايى امكانات و سطح دسترسى ها سايت را تعريف ميكند و مدير سايت و يك كاربر معمولى توسط اين سيستم شناسايى و محدوديت ها و امكانات در اختيارشان قرار ميگيرد در نوشتن يك سيستم ورود و شناسايى نكاتى وجود دارد كه بايد رعايت بشوند.
اولين نكته ثبت نام است در ثبت نام هر عضو جديد بايد توجه شود كه چه اطلاعاتى لازم است گرفته شود و بيشتر از حد نياز از كاربر اطلاعات گرفته نشود ولى مهمتر از ان انتخاب نام كاربرى و كلمه عبور است توجه به اين نكته كه نام كاربرى هر عضو جديد بهتر است براى شناسايى بهتر شباهت زيادى به اسم حقيقى شخص داشته باشد در انتخاب كلمه عبور نيز دقت فراوان نياز است ساده ترين نكته توجه به اين مورد است كه عضو جديد پسورد را مشابه نام خود يا نام كاربر انتخاب نكند در يك حمله ساده اولين تركيبات پسوردى كه امتحان ميشوند مخلوطى از نام كاربر با پسوند هاى ساده و تكرارى است كه اكثرا استفاده ميكنند مثلا اگر شخصى به نام ali مورد نظر باشد اولين تركيبات ساده پسورد ميتواند ali123 – ali12345 – alipassword – alilogin و مشابه اين باشد پس بايد دقت كرد در هنگام ثبت نام پسورد از اسم كوچك يا اسم بزرگ كاربر انتخاب نشود – ali1363
بعد از ثبت نام نكته مهم نگهدارى اطلاعات است صحبت ما روى استفاده از بانك اطلاعاتى خاصى نيست حتى يك فايل نوشتارى هم ميتواند مطمئن ترين بانك اطلاعات كاربران باشد در صورتيكه برنامه نويس ساده ترين احتياط ها را انجام بدهد در نگهدارى اطلاعات كاربران بايد اولين نكته توجه به طبقه بندى اطلاعات باشد در صورت امكان بهتر است كاربران با سطح دسترسى برابر را در يك محل نگهدارى كنيد و كاربران با سطح دسترسى بالاتر را در محل ديگرى نگهدارى كنيد هميشه اولين گزينه سرقت اطلاعات امتحان محل قرار گرفتن بانك اطلاعات است اگر شما اطلاعات را در فايل هاى بانك اطلاعاتى نگهدارى ميكنيد اين نكته را فاموش نكنيد فايل هاى اطلاعات را خارج از محيط صفحات وب قرار بدهيد تا يك كاربر معمولى امكان دسترسى و گرفتن اين فايل ها را نداشته باشد.
در سرور هاى Win شما بايد از دايركتورى هايى كه توسط ميزبان براى نگهدارى بانك اطلاعات اختصاص يافته اند استفاده كنيد و در سرور ها Linux,Unix شما ميتوانيد از امكان تعريف محدوديت استفاده كنيد با استفاده از فايل .htaccess فايل بانك اطلاعاتى را حفاظت كنيد يك نمونه اين فايل به صورت زير است :

در مثال بالا تمام فايل هايى كه باپسوند تكست هستند از طريق وب قابل دريافت نمى باشند و اگر شخصى سعى به دانلود اين فايل بكند با پيغام خطايى كه مشخص شده است در قمت ErrorDocument 403 روبرو ميشود پس مى بينيد كه با رعايت يك نكته كوچك چقدر مشكلات كم خواهد شد.
بعد از فايل ها بانك اطلاعاتى به سرويس هاى انلاين بانك اطلاعاتى مثل Mssql , Mysql ميرسيم نوع سرويس خاصى مورد نظر ما نيست ولى با رعايت چند نكته ساده حتى اجازه كمترين ريسكى را هم به سرور خود ندهيد يك پورت باز كه متصل به بانك اطلاعاتى است هميشه توجه اكثر حمله كنندگان را جلب ميكند تا شانس خود را براى سرقت اطلاعات امتحان كنند ولى با استفاده از يك قابليت ساده سرور ميتوانيم جلوى حمله كنندگان را بگيريم و حتى شانس حدس زدن ورود به سرور را هم به انها ندهيم .
كافيست به يك نكته ظريف توجه كنيد اگر قرار است استفاده مجاز از اطلاعات توسط برنامه از روى سرور باشد پس ورود هر اتصال غير از ادرس سرور غير ضرورى ميباشد ما بايد تعريف كنيم كه تنها ارتباط Local مجاز است و Ip مورد استفاده ما براى ورود مجاز چه ip ميباشد پس بطور مثال اگر بر روى سرور Mysql يك بانك اطلاعاتى ايجاد ميكنيم و بعد ميخواهيم يك User&pass براى ارتباط براى سرور تعريف كنيم حتما بايد اين نكته را در نظر بگيريم كه در هنگام تعريف User به اين نكته اشاره كنيم كه فقط ارتباط از ip server براى ورود با اين user مجاز است و اگر اين user از ip‌غير از Ip server اقدام به ورود كرد سريعا از سرور بيرون انداخته شود و حتى بهتر است كه به افراد پشت سرر هم اطمينان نكنيد و دسترسى كاربرى كه از سرور مجاز به اتصال است بيش از حد مورد نياز نباشد.
بعد از انجام اين اقدامات ميرسيم به ادامه ثبت نام مهمترين بخش يك ثبت نام ذخيره پسورد در بانك اطلاعات است توجه كنيد يك سيستم ورود بر مبناى يك نام كاربر و يك پسورد بنا ميشود و بقيه اطلاعات يك كاربر همه تابعى از پسورد هستند يعنى اگر پسورد يك كاربر را داشته باشيم همه اطلاعات ان را داريم ولى برعكس ان عملى نيست با دانستن مثلا نام يك كاربر و سن ان به نتيجه خاصى نخواهيم رسيد در نگهدارى پسورد بايد دقت فراوانى صورت بگيرد اول اينكه اگر به سيستم رمز گذارى Code&Decode آشنا هستيد بهتر است پسود را كد كنيد در رمز گذارى شما دو روش را ميتوانيد در نظر بگيريد اولين روش توجه به اين نكته است كه با روشى پسورد را رمز كنيد كه مجدد قابل بازيابى باشد و روش دوم رمزگذارى پسورد با روشى است كه قابل بازيابى نباشد هر كدام از اين روش ها بنا به استفاده سايت بايد انتخاب شوند ولى با يك مثال كوتاه متوجه مطلب خواهيد شد :
اگر پسورد : ali-k باشد به دو صورت زير رمزگذارى ميكنيم
ali-k—Code–> XzxaqweERTdfc —Decode—>ali-k
در اين روش پسورد ali-k توسط كاربر انتخاب ميشود و بعد از كد شدن به صورت XzxaqweErtdfc وارد بانك اطلاعاتى ميشود و نگهدارى ميشود و هر زمانيكه نياز باشد مجدد Decode ميشود و به همان كلمه انتخبى كه ali-k بود بر ميگردد
ali-k—code—> QwErTyUiop—Decode—>??????
ولى در روش دوم پسورد انتخابى كاربر كه ali-k بود رمزگذارى ميشود و بصورت QwErTyUiop در بانك اطلاعاتى ذخيره ميشود اما اين پسورد ذخيره شده در بانك اطلاعاتى ديگر قابل رمزگشايى نيست و به كلمه اوليه تبديل نخواهد شد .
در اينجا نحوه رمزگذارى و روش مورد نظر ما نيست فقط تفاوت دو نوع ذخيره مهم است در نوع اول كه روش بهترى است اگر زمانى نياز به زنده كردن پسورد باشد مثلا اگر كاربر پسورد خود را فراموش كند ميتواند پسورد را از بانك اطلاعاتى خارج و به صورت اول در اختيار كاربر گذاشت در صورتيكه در روش دوم نميتوان پسورد انتخابى كاربر ا زنده كرد و تنها راه اين است كه مدير سايت يك پسورد جديد براى كاربر انتخاب كند ولى توجه به اين نكته كه در روش اول اگر بانك اطلاعاتى به سرقت برود در هر صورت امكان بازگشايى پسورد ها وجود دارد ولى در روش دوم بدست اوردن پسورد ها كارى به مراتب سخت تر خواهد بود .
بعد از انتخاب روش ذخيره پسورد در هر صورت لازم است مايك روش رمز گذارى انتخاب كنيم در انتخاب روش رمزگذارى توجه زيادى داشته باشيد اگر با روش هاى رمزگذارى اشنا نمى باشيد حداقل وقت را صرف كنيد و از روش هايى كه اكثرا از ان استفاده ميكنند بهره ببريد ولى يك نكته ساده در رمز گذارى اين است كه اگر از روش هاى ضعيف استفاده كنيد با مشكلاتى در اينده روبرو خواهيد شد مثلا در تابع رمزگذارى زبان perl:

اگر توجه بكنيد با دستور خط اول و دستور خط سوم ما يك نتيجه در رمزگذارى داشتيم ولى در خط پنجم نتيجه متفاوت بود حالا تصورش را بكنيد اين مشكل چقدر حاد خواهد بود در اين تابع رمز گذارى از 8 حرف به بالا هيچ تفاوتى در رمز گذارى ندارد يعنى مثلا اگر كسى 8 حرف پسورد را بداند با كسى كه يك پسورد 12 حرفى را استفاده ميكند هيچ تفاوتى نخواهد كرد در اصل از هشت حرف بيشتر به حساب نخواهد امد علاوه بر اين مشكل 8 حرف پسورد بيشتر در حمله تاثير ندارد يعنى زمانيكه يك حمله كننده بداند كه فقط 8 حرف پسورد براى ورود به سايت لام است از برنامه هاى جستجو براى 8 پسورد استفاده ميكند در مدت يك يا دو ساعت راحت پسورد را ميشكند پس شناختن توابع رمزگذارى و استفاده صحيح از انها بسيار مهم است .در سرور هاى بانك اطلاعاتى شما ميتوانيد از دستوراتى براى ساده كردن مراحل رمز گذارى استفاده كنيد مثلا در سرور Mysql به راحتى ميتوانيد از روش MD5 براى رمز گذارى استفاده كنيد.
بعد از ذخيره پسورد ما اولين قدم را برداشتيم و يك كاربر را ثبت نام كرديم ولى قدم بعدى كه بسيار مهمتر است ورود و خروج كاربران ثبت نام شده است از اين قسمت به بعد وارد مبحث كمى پيچيده روش هاى گرفتن پسورد و تاييد و نحوه ذخيره و بازيابى و غيره ميشويم پس بهتر است قدم به قدم روش هاى مختلف را بشناسيم اولين نكته چك كردن پسورد است در چك كردن پسورد هميشه بايد قسمت ورود از قسمت چك كردن ورود جدا باشد يعنى بايد يك الگوريتم براى زمانيكه كاربر اولين بار user&pass را مينويسد و ارسال ميكند داشته باشيم و يك الگوريتم براى چك كردن ورود الگوريتمى كه در هر قسمتى كه نياز بود چك كند كه كاربر ايا دسترسى دارد يا خيز ايا user&pass صحيح است يا خير و امكانات كنترلى ديگر را در اختيار ما بگذاريد .
براى الگوريتم اول ساده ترين راه اين است كه كاربر در يك From صفحه وب user&pass وارد كند و پسورد وارد شده بعد از رمزگذارى با پسورد رمزشده كه در بانك اطلاعات است مقايسه شود و اگر صحيح بود كاربر مجاز به ورود شود در اين ميان نكات بسيارى ظريفى وجود دارد مثلا سيستم ورود بايد نسبت به پسورد خالى يا نزدن پسورد حساس باشد باور اينكه اولين باگ يك برنامه نويس همين مورد است شايد براى شما جاى تعجب داشته باشد دوم اينكه هيچوقت پسورد ثابتى را در سورس برنامه به عنوان پسورد اوليه كه جايگزين پسورد خروجى از بانك اطلاعاتى ميشود در نظر نگيريد در برخى موارد ديده شده است كه براى اينكه متغير پسورد خروجى بانك اطلاعاتى خالى نباشد يك كلمه براى ان در نظر گرفته شده و هكر با خواندن سورس برنامه و استفاده از همان كلمه وارد سيستم شده اند نكته سوم اولي گام بعد از گرفتن پسورد از كاربر رمزگذارى ان است به هيچوجه از پسورد ارسالى كاربر در برنامه استفاده نكنيد در مشكل كوچكى ممكن است پسورد را به بيرون بدهيد ولى اگر اولين قدم بعد ازدريافت پسورد كد گذارى باشد بسيارى از ضعف ها پوشيده خواهد شد بعد از اينكه دسترسى كاربر و صحيح بودن پسورد تاييد شد ما نياز به الگوريتم چك كردن داريم .
ما روش هاى مختلفى داريم اولين روش اين است كه در هر قسمتى كه نياز به user&pass باشد بر روى url اين دو كلمه مهم فرستاده ميشود مثلا http://www.site.com/login.cgi?username=ali&pwd=alik اين روش بسيار نا مطمئن است حتى از نظر امنيتى فرمى كه كربر user&pass را در ان مينويسد و ارسال ميكند هم يك ريسك محسوب ميشود حالا فرض كنيد ما اين اطلاعات را هر چند كدگذارى شده روى url به اين طرف و ان طرف سايت بفرستيم پس اگر امنيت برنامه انقدر ارزش ندارد كه از روش هاى ديگر استفاده كنيد به اين روش روى بياوريد .
روش بعد استفاده از cookie در استفاده از cookie هم ما دو نوع ذخيره اطلاعات در cookie داريم يك ذخيره دائم و يك ذخيره موقت كه بعد از بسته شدن صفحه اطلاعات cookie هم از بين خواهد رفت اول اينكه وقتى ميخواهيد اطلاعات user&pass را در cookie ذخيره كنيد هيچوقت رمزگذارى را فراموش نكنيد cookie ها بر خلاف استفاده فراونى كه در ذخيره اطلاعات بر روى دستگاه ازديد كنندگان دارند از امنيت جالبى برخوردار نيستند در مقايسه دو نوع ذخيره دائم و موقتى بايد گفت كه برخلاف انچه تصور برنامه نويسان است ذخيره موقتى كه بعد از بسته شدن پنجره اطلاعات cookie حذف خواهند شد ذخيره مناسبى نمى باشد در ذخيره موقت اگر مثلا من اول به سايت شما به آدرس www.site.com و بعد با يك لينك ساده به سايت www.site222.com بروم اطلاعاتى كه از سايت شما همراه دارم را به سايت دوم منتقل ميكنم !!! پس همان توصيه قبلى اگر انقدر امنيت سيستم مهم نيست كه به روش هاى بعد روى بياوريد از اين نوع ذخيره استفاده كنيد …
در ذخيره دائم ما ميتوانيم يك cookie روى هارد دستگاه بازديد كننده بنويسيم و از جمله مشخصات user&pass مشخصات بازديد يا دفعاتى كه به سايت امده است يا هر نوع اطلاعات ديگرى را مختص به ادرس domain خودمان روى دستگاه بازديد كننده داشته باشيم در نوشتن cookie دائم يك نكته نبايد فراموش نشود يك برنامه نويس بايد اين مطلب را بداند وقتى يك user&pass را روى دستگاه بازديد كننده ذخيره كرديم امكان كپى بر دارى از اين cookie وجود دارد يعنى اگر يكنفر همين cookie را روى يك دستگاه ديگر كپى كند چه اتفاقى مى افتد ؟؟ مشكلى كه بعد از اين كار بوجود مى ايد ان است كه بدون وارد كردن user&pass كسى كه كپى cookie را دارد وارد سايت ميشود براى حل اين مشكل ما دو اه داريم اول برنامه نويس بايد بداند يك user&pass چقدر اعتبار نياز دارد يعنى اگر يك كاربر وارد سايت شد تا چه زمانى به چه مدتى لازم است كه user&pass داشته باشد مثلا ما ميدانيم كه يك كاربر مثلا 30 دقيقه وقت نياز دارد براى خواند نامه هاى شخصيش و بعد از 30 دقيقه از سايت خارج ميشود پس بهتر است ما يك زمانى براى فاسد شدن cookie تعريف كنيم يعنى بعد از 30 دقيقه از ورود اطلاعات ورود باطل بشوند و ارزشى ديگر ندارند حالا اگر كپى هم از روى اين cookie زده بشود بعد از 30 دقيقه هيچ ارزشى نخواهد داشت روش دوم نيز محكم كارى است اگر فرض كنيم كه كپى از روى cookie هنوز اعتبار داشت يعنى مثلا از 30 دقيقه زمان براى فاسد شدن 10 دقيقه مانده بود و شخصى خواست از اين كپى استفاده كند با محدوديت دوم جلوى ورود را خواهيم گرفت
محدوديت دوم اين است كه علاوه بر user&pass شما بايد ip بازديد كننده زمان ورود به سايت را در cookie بنويسيد اين عمل باعث ميشود شخصى كه cookie را كپى كرده است چون ip متفاوت نسبت صاحب اصلى cookie ‌دارد نتواند وارد سايت بشود خوب خلاصه :
اگر cookie دائم استفاده كنيم با زمان فاسد شدن بعد يك مدت اطلاعات فاسد خواهند شد وامكان كپى و استفاده از انها نخواهد بود و اگر هم قبل از فاسد شدن cookie كپى بشود چون دو نفر همزمان نمى توانند يك ip ‌داشته باشند شخصى كه كپى كرده نمى تواند وارد سايت بشود
بعد از نوشتن الگوريتم ورود الگوريتم چك كردن ورود بسيار مهم است اولين نكته اينكه هيچوقت از پارامتر هاى كلى استفاده نكنيد مثلا بعد از اينكه user&pass درست بود با يك پارامتر مشخص نكنيد كه ورود انجام شد بلكه هميشه جز به جز عمل كنيد در هربار چك كردن ورود Usr&pass را بگيريد و با بانك اطلاعات چك كنيد گرفتن user&pass بايد از داخل cookie باشد يعنى يكبار كاربر user&pass صحيح را وارد كرد و ما در cookie نوشتيم و هر بار نياز بود به cookie ‌مراجعه ميكنيم و حتما چك ميكنيم كه صحيح باشد در تمام مواردى كه شما با نام user در رائه خدمات كار داريد يعنى حتما بايد به x يك دسترسى ‌خاصى داده بشود فقط به اوردن user‌از cookie اكتفا نكنيد وقتى user x را از cookie گرفتيد براى اطمينان چك كنيد كه پسورد داخل cookie هم براى user x هست يا نه ممكن است با يك user&pass وارد شده باشد و با تغيير نام user ‌در cookie بخواهد سيستم را فريب بدهد تا حدى كه ممكن است به اطلاعات ذخيره شده بر روى cookie به عنوان مرجع كار برنامه مراجعه نكنيد بهتر است اطلاعات بعد از ￔ￤ￇￓￇ￭￭ كامل از روى سرور در برنامه استفاده بشوند .

[email protected]