انتشار نسخهء 1.3 پروژه سیستم رجیستر و لاگین

دانلود نسخهء جدید (1.3)

البته از اون موقعی که نسخهء 0.7.7 این پروژه رو توی این وبلاگ گذاشتم، چند نسخهء دیگه ازش منتشر کردم، ولی در وبلاگ درج نکردم و فقط در دو فروم برنامه نویسی ای که در اونها فعالیت دارم درج کردم.
حالا بعد از مدتی که پروژه به حد کمال نزدیک شده (تاحدی که به ذهن من میرسیده و میخواستم روش وقت صرف کنم)، این نسخه رو هم درج میکنم. آخرین نسخه این برنامه الان 1.3 است.

خب در این مدت کارهای زیادی روی پروژه صورت دادم. باگهای متعددی رو کشف و برطرف کردم، هم از نوع امنیتی و هم از نوع غیرامنیتی. امکانات مفید متعددی به برنامه اضافه شده، یکسری تمیزکاری در کد و ساختار دایرکتوری ها و همچنین بهینه سازیهایی در کدها انجام شده. یک دور بخش اعظم کدهای برنامه رو مرور کردم که منجر به بخشی از تغییرات ذکر شده شد. همچنین با یک اسکنر امنیتی (Acunetix) هم پروژه رو تاحدی که میتونستم اسکن کردم.

ضمنا حالا برنامه روی هاست واقعی (لینوکس) در اینترنت هم تست شده. چند مشکل در روی هاست واقعی بوجود آمد که روی لوکال وجود نداشتن، و این مشکلات رو برطرف کردم تا برنامه راه افتاد.

امکاناتی که به برنامه اضافه شده:

- الان تنظیمات سیستم محافظت از اکانتها دربرابر Brute-force برای اکانت ادمین و اکانت کاربران عادی کاملا از هم جدا هستن. این باعث انعطاف زیادی میشه و میتونیم سیستم قفل بر اساس اکانت و IP رو برای ادمین و کاربران عادی بطور کاملا مستقل فعال و غیرفعال کنیم و تنظیم پارامترهای اونها هم از هم کاملا جدا هستند. منظورم از پارامترها، تنظیم فعال و غیرفعال بودن قفل بر اساس اکانت یا IP، تنظیم تعداد لاگین اشتباهی که بعد از اون کپچا نیازه، تنظیم تعداد لاگین اشتباهی که بعد از اون اکانت و/یا IP قفل میشه، و بازهء زمانی ای که در اون حداکثر تعداد لاگین اشتباه تعیین شده رو میشه داشت هست.

- سیستم Block-bypass (سیستمی که کاربری که امکان لاگین کردن رو به علت قفل شدن اکانتش از دست داده میتونه با ارسال لینک مخصوصی به ایمیلش ازش برای لاگین استفاده کنه) رو هم الان میشه فقط برای ادمین یا فقط برای کاربران عادی یا برای هر دو فعال کرد. اینم آخر انعطاف!!

- از خیلی پیشتر در این فکر بودم که تعداد لاگین ناموفق حتی در حالت Block-bypass باید محدود بشه، منتها قبلا بخاطر کاهش حجم و فشار کار این خصوصیت رو پیاده سازی نکردم. الان این امکان وجود داره که برای تعداد لاگین ناموفق در حالت Block-bypass هم محدودیت تعیین کرد.
فرض کنید مثلا هکری ایمیل کسی رو هک کرده، اما میخواد پسورد واقعی اکانت کاربر رو در یک سایتی که کاربر عضوش هست به هر دلیلی کشف کنه (مثلا میخواد دسترسی مخفیانه به اکانت کاربر در اون سایت داشته باشه). اگر محدودیتی روی تعداد لاگین ناموفق در حالت Block-bypass نباشه، هکر میتونه از سیستم Block-bypass برای تست دستی حدسهاش یا Brute-force سنگین تر با استفاده از برنامه های خودکار، سوء استفاده کنه.

- امکان دیگری که اضافه کردم اینه که الان میشه از سیستم Block-bypass برای دور زدن قفل IP هم استفاده کرد (قبلا فقط برای دور زدن قفل اکانت بود). البته این امکان هم قابل فعال و غیرفعال کردن است.
فرضا کاربری که به سایت مراجعه میکنه اما بخاطر اینکه کس دیگری از همون IP اقدام به Brute-force روی بخش لاگین سایت کرده بوده و اون IP حالا برای مدتی بلاک شده، حالا میتونه درصورت نیاز با استفاده از سیستم Block-bypass به اکانت خودش لاگین کنه.
میدونید که استفادهء چند نفر از یک IP بصورت همزمان یا با فاصلهء زمانی نسبتا کم، امر بعیدی نیست.

- امکان دیگر اضافه شده اینه که ادمین میتونه این اختیار رو به کاربران بده که سیستم قفل اکانت و قفل IP رو برای اکانت خودشون غیرفعال کنن. اینم باز نهایت انعطاف و قابلیت پیکربندی برای تقریبا هر شرایطی پیشبینی شده و نشده ای هست که در پروژه گذاشتم. البته این قابلیت رو بصورت پیشفرض خاموش گذاشتم و بنظرم تا نیاز واقعی پیش نیاد نباید فعالش کرد. ضمنا میشه تعیین کرد که کاربران بتونن قفل اکانت، قفل IP، و یا هردو رو برای اکانت خودشون فعال و غیرفعال کنن (البته اکانت ادمین از تمام محدودیتها بر روی این تنظیم مستثنی است). البته این تنظیمات نمیتونن تنظیمات موجود در فایل کانفیگ (config_brute_force_protection.php) رو Override کنن. این تنظیمات در سطح بعد از تنظیمات فایل کانفیگ عمل میکنن. یعنی مثلا اگر تنظیم سیستم قفل IP در فایل کانفیگ برابر خاموش باشه، کاربران (و همینطور ادمین) نمیتونن برای اکانت خودشون قفل IP رو فعال (یا غیرفعال) کنن، چون این سیستم برای کل سایت خاموش تعیین شده. گزینه هایی هم که در صفحهء تنظیم به کاربران نمایش داده میشن بر اساس تنظیمات فعلی فایل کانفیگ هستند.
ضمنا یک ویژگی دیگری که در این سیستم گذاشتم اینه که، اگر بعد از تنظیمات کاربران، تنظیمات فایل کانفیگ تغییر کنن، سیستم بصورت هوشمندانه ای تنظیمات جدیدی رو تعیین میکنه تا مقدار حفاظت از اکانت کاربر کم نشه (اما میتونه زیاد بشه). مثال: فرض کنید هر دوی سیستم قفل اکانت و قفل آیپی در فایل کانفیگ فعال باشن، فرض کنید کاربران اجازهء غیرفعال کردن هردو رو برای اکانت خودشون دارن، فرض کنید کاربری میاد و قفل اکانت رو برای اکانت خودش غیرفعال میکنه؛ در این صورت، اکانت این کاربر هنوز توسط سیستم قفل IP مورد محافظتی گرچه کمتر از محافظتی که قفل اکانت ایجاد میکنه قرار میگیره (که کاربر هم احتمالا این رو میدونه و روش اتکا کرده). حالا ادمین بعدا میاد و سیستم قفل IP رو در فایل کانفیگ خاموش میکنه. حالا اکانت اون کاربر هیچ محافظتی دربرابر Brute-force نداره! ولی سیستم میاد و خودش بصورت خودکار این پایین آمدن درجهء حفاظت رو تشخیص میده، و سیستم قفل اکانت رو برای اون کاربر فعال میکنه.
طراحی و پیاده سازی این سیستم که به کاربران امکان تعییر تنظیمات سیستم ضد Brute-force برای اکانت خودشون رو میده پیچیده بود و حجم کاری قابل توجهی داشت، اما بهرحال فکر کردم بهتره وجود داشته باشه و شاید نیاز بشه. بعدش هم که باید تبعاتش رو درنظر میگرفتم و اصولی طراحی میشد تا برعکس باعث کاهش امنیت نشه؛ بخاطر همین مجبور شدم الگوریتمش رو کامل و هوشمند کنم.

- قبلا گفته بودم و در فکرش بودم که یک جوری جلوی سوء استفاده از سیستم ایجکس چک کردن ثبت شده بودن نامهای کاربری رو که در بخش ثبت نام سایت استفاده میشه بگیرم؛ چون از این سیستم خیلی راحت و سریع میشه برای تست موجود بودن نامهای کاربری در سایت استفاده کرد (که نمونهء متداولی از Information leakage است). البته احتمالا ما نمیتونیم جلوی این رو 100% بگیریم، اما میشه تاحد قابل توجهی محدود/دشوارش کرد. بنابراین بنده یک محدودیت قابل تنظیم در تعداد استفاده از این سیستم به ازای هر IP در یک بازهء زمانی مشخص گذاشتم که میشه فعال و غیرفعال و تعدادش (و بازهء زمانی) رو تنظیم کرد. ضمنا این امکان هم وجود داره که اگر از یک IP یک ثبت نام موفق صورت گرفت، که به معنای پاس کردن تست کپچا است (که معمولا بدین معناست که طرف مقابل روبات نیست)، تعداد استفاده از سیستم ایجکس برای اون IP توسط اون کلاینت ریست بشه تا جلوی استفاده های بعدی یا کاربران احتمالی بعدی اون IP از این سیستم بی دلیل سد نشه. البته این کار با ذخیرهء یک کوکی در مرورگر کاربر انجام میشه تا مطمئن باشیم فقط تعداد استفاده های همون کاربر رو کاهش دادیم.

- سیستم لاگ کردن وقایع قفل شدن اکانت و IP رو هم که در پست قبلی گفته بودم طراحی و پیاده سازی کردم. مشتمل بر امکان آگاه سازی ادمین از طریق ایمیل و/یا موقعی که در سایت فعالیت میکنه. این سیستم هم انعطاف خوبی داره و تنظیمات متعددی برای پارامترهای مختلف اون گنجانده شدن. مثلا میشه تعیین کرد که فقط موقعی که حمله نسبت به اکانت ادمین بوده به ادمین خبر داده بشه. یا میشه تعیین کرد که وقتی تعداد حمله ها در 24 ساعت به تعداد خاصی رسید ادمین رو خبر کنه. همینطور میشه تعیین کرد که فاصلهء زمانی ارسال ایمیل ها کمتر از یک حدی نباشه (مثلا اگر حمله های زیادی صورت میگیره که باعث میشه ایمیل های زیادی با فاصلهء زمانی کم به ایمیل ادمین ارسال بشن و این امر ایجاد مشکل میکنه). ضمنا بخاطر اهمیت اکانت ادمین، میشه اکانت ادمین رو از این محدودیتها مستنثنی کرد.

- امکان تغییر کلید لاگین کاربر موقعی که لاگ آوت میکنه رو به برنامه اضافه کردم.
تغییر کلید لاگین (که در کوکی احراز هویت خودکار ذخیره میشه) موقع لاگ آوت باعث میشه که تمام سیستمها/افراد دیگری که ممکنه در اکانت کاربر لاگین باشن، از لاگین خارج بشن. این برای امنیت خیلی خوب بنظر میرسه!

- امکان Logging فعالیت های کاربران رو هم اضافه کردم که میشه هرکدام رو جداگانه فعال و غیرفعال کرد: فعالیت در سایت، لاگین، لاگ آوت.
البته فقط زمان آخرین این فعالیت ها برای هرکاربری ثبت میشه (در همون جدول accounts و در رکورد مربوطه هر کاربر).
این اطلاعات رو ادمین میتونه در صفحه ای که مشخصات اکانتهای ثبت شده در سیستم رو نشون میده مشاهده کنه.

- میشه تعیین کرد که موقعی که کسی رجیستر میکنه، با ایمیل به ادمین اطلاع داده بشه. این امکان بخصوص در مواقعی که رجیسترها نیاز به تایید شدن دستی توسط ادمین هم دارن میتونه خیلی مفید باشه. تنظیماتش هم مثل همیشه دارای انعطاف زیادیه (کامنت های فایل کانفیگ رو بخونید متوجه میشید).

- یکسری آمار راجع به مثلا تعداد اکانتهای رجیستر شده، تعداد اکانتهای و آیپی های بلاک شده و اینا حالا در همون صفحهء مدیریت ادمین در جلوی گزینه ها نمایش داده میشن. البته این گزینه رو میشه فعال و غیرفعال کرد (گفتم شاید در شرایطی به مشکل پرفورمنس بخوره و لود صفحه زیادی کند بشه).

- یه امکان جدید به سیستم اضافه کردم و اونم اینه که میشه لاگین (و در نتیجه کلید ذخیره شده در کوکی autologin) رو وابسته به IP کرد.
طبیعتا این کار منجر به امنیت افزوده میشه. حتی اگر کسی کوکی احراز هویت کاربر رو سرقت کنه، نمیتونه از IP دیگری خودش رو بجای کاربر احراز هویت کنه.
این سیستم هم تنظیماتش باز آخر انعطاف هست. مثلا میشه تعیین کرد که فقط برای ادمین اینطور باشه، یا برای کاربران عادی، یا برای همه.
ضمنا یک آپشن هم گذاشتم که اگر فعال بشه اصلا کاربران میتونن بدون توجه به تنظیم قبلی، خودشون موقع لاگین تعیین بکنن که لاگین اونها به IP شون وابسته بشه یا نه.

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

ضمنا سیستم بلاک IP رو یه تغییرات مهمی دادم، چون بنظرم سیستم قبلی قابل سوء استفاده بود.
سیستم قبلی برای جلوگیری از بلاک شدن IP هایی که بصورت مشترک توسط عده ای استفاده میشن میامد و نسبت تعداد لاگین های ناموفق به موفق رو درنظر میگرفت. البته در این سیستم هر تعداد لاگین موفق به یک اکانت فقط یک بار شمرده میشد تا به این طریق کسی نتونه سوء استفاده کنه و به ازای هر بار تلاش ناموفق یک بار به اکانتی که خودش رجیستر کرده لاگین کنه. اما این سیستم هنوزم یک ضعفی داشت و اون اینکه اگر مثلا هکر 100 اکانت در سیستم رجیستر میکرد اونوقت میتونست از هر آیپی 100 برابر حالت مجاز تلاش لاگین ناموفق داشته باشه.
سیستم فعلی دیگه اون طوری نیست و به روش Proportional عمل نمیکنه. ولی خب کار برنامه نویسیش بیشتر و پیچیده تر شد چون هم میخواستم مشکلی برای کاربران ایجاد نکنه و یوزرفرندلی هم باشه و هم امنیت کافی داشته باشه و به هیچ وجه قابل دور زدن نباشه.

یک نکته ای رو باید توجه کنید در سیستمهای بلاک این پروژه و اونم اینه که فرضا اگر شما 3 بار تلاش لاگین ناموفق به اکانت خودتون داشته باشید و در بار چهارم موفق به لاگین بشید، اون 3 تلاش ناموفق قبلیتون از سیستم حذف میشن (چون مشخص میشه که جهت حمله نبودن). این نظر یوزرفرندلی و جلوگیری از مشکلاتی هست که در غیراینصورت ممکنه پیش بیان. سیستم بلاک IP مشابه همین روش رو داره ولی طراحی و پیاده سازیش پیچیده تر بود.
البته اینم بگم که این زیرسیستم ریزه کاریهای مهمی داره که باید درنظر گرفته بشن تا خودش راهی برای سوء استفاده و دور زدن سیستم ضد Brute-force نشه.

یه ریزه کاریها و حمله های پیچیده ای رو در این پروژه درنظر گرفتم که به فکر کسی نمیرسه؛ چون میدونم شدنی هستند (ولو با نیاز به یک هکر دانشمند و کلی برنامه نویسی سفارشی).

این نسخهء برنامه رو تاحدی که حوصله داشتم و برام اولویت داشت روی لوکال و اینترنت و در FF و IE تست و رفع باگ کردم، ولی بعید نیست بخاطر کدهای تغییر کرده و افزوده ای که داره هنوزم باگهایی توش باشن که از زیر دستم در رفته باشن. اگر موردی دیدید لطفا گزارش کنید تا برطرف کنم.

راستی برای یکسری توضیحات بیشتر، مثل نحوهء نصب برنامه، میتونید به توضیحات درج شده در انتشار نسخهء 0.7.7 این پروژه مراجعه کنید.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>