# زبان های اسکریپتی > PHP > امنیت در PHP >  نیاز به اسکن امنیتی برنامهء وب من

## eshpilen

یه سیستم رجیستر و لاگین نوشته بودم.

این آدرسش: www.hamidreza-mz.tk/reg8log/

واسه نمونه و تست گذاشتم.

میخوام اسکن امنیتی و تست نفوذ بشه.

کسی میتونه؟

حالا چه خودکار چه دستی.

ضمنا این برنامه بازمتن است.
بنابراین میتونید کد منبعش رو هم دریافت و بررسی کنید: http://www.hamidreza-mz.tk/files/reg8log-v1.8.zip

----------


## eshpilen

چی شد؟
هیچکس جرات نداشت حمله کنه؟  :لبخند گشاده!: 

فکر کنم باید ببرم توی فروم آشیانه ای چیزی مطرح کنم  :متفکر:

----------


## abolfazl-z

خدایی خیلی زمان بر هست!

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

درضمن اگر میومدی درباره هر تابع و خط و ... توضیح می دادید بهتر میشد.  :لبخند:

----------


## eshpilen

حداقل یه سایت اسکن آنلاین فری معرفی کنید بدم اسکن کنه بصورت خودکار.

----------


## navid3d_69

با برنامه acunetix یه چک بکن خودت فکر نکنم کسی اینجا تست کنه برات

----------


## abolfazl-z

من اسکن کردم ولی نمیدونم چرا اینقدر طول میکشه !

در چند درصد اول چند تا خطای medium  داشتید.

----------


## eshpilen

> من اسکن کردم ولی نمیدونم چرا اینقدر طول میکشه !


واسه خودمم همینطور بود روی لوکال. حتی کپچا رو غیرفعال کردم بازم همینطور بود. بخاطر همین دیگه ادامه ندادم.
البته PC بنده هم قدیمی و ضعیف است.




> در چند درصد اول چند تا خطای medium  داشتید.


جزییاتش رو بذار ببینم.

با چه نرم افزاری اسکن کردی؟

----------


## abolfazl-z

ربطی به pc نداره!
باید دوباره اسکن کنم.

----------


## abolfazl-z

scan.png

ٍٍٍٍٍAcunetix WVS Scan Wizard

----------


## eshpilen

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

----------


## abolfazl-z

ولی چرا اینقدر دیر اسکن میشه ؟

----------


## eshpilen

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

----------


## eshpilen

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

----------


## abolfazl-z

نه والله !

اصلا پیش نمیره.

کنسل اش کردم  :لبخند گشاده!:

----------


## engmmrj

یه فرم register و login ساده که دیگه نیاز به scan نداره !

----------


## navid3d_69

کند توی لوکال معمولا برای phpmyadmin هست که می تونه اسکن اونو چون یوزر و پس وردش دیفالت هست

----------


## eshpilen

> یه فرم register و login ساده که دیگه نیاز به scan نداره !


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

ضمنا شما احتمالا طرز کار همین برنامه های امنیتی رو هم کامل و دقیق نمیدونید.
بطور مثال این نرم افزارها حتی انواع نفوذ از طریق کوکی های برنامهء شما رو هم تست میکنن.
یعنی مثلا توی کوکی ها اگر کدهای HTML/JS و SQL باشه، بسته به برنامه ممکنه ضعفی در این زمینه وجود داشته باشه.
یعنی فقط بحث دوتا فرم و اینترفیس و text box که به چشم دیده میشن و در دسترس کاربران عادی هستن نیست.

----------


## abolfazl-z

> مثلا برای لاگین اولش کپچا نداره، ولی چند بار تلاش لاگین اشتباه بعدش منجر  میشه به اینکه کپچا هم وارد عمل بشه، با کپچا هم چند بار لاگین اشتباه  صورت بگیره در نهایت قفل میشه.


یک اشتباه جالب ولی واقعی !

با یکبار  ورود اشتباه شما علاوه بر وارد نمودن نام کاربری و رمز عبور شما باید کد کپچا را هم وارد کنید. تا اینجا درست !

ولی زمانی که دوباره به آدرس http://www.hamidreza-mz.tk/reg8log بروید دیگر لزومی ندارد کد کپچا وارد کنید ! و به راحتی و به دفعات تکراری حمله را آغاز کنید !
یعنی هر دفعه به صفحه اصلی وارد میشیم و حمله می کنیم.

----------


## eshpilen

البته من یه سیستمی توی این برنامه گذاشتم بخاطر user friendly و دقت منطق برنامه.
با خودم فکر کردم کاربر مثلا چند دفه اشتباه وارد میکنه، بعد بالاخره موفق میشه و وارد میشه، و طبیعتا ثابت شده/یعنی ما باید فرض کنیم که کاربر بوده و نه هکر و فقط پسورد رو اشتباه تایپ کرده یا درست یادش نبوده و یا به هر علت مشابه دیگری خلاصه چند باری رو اشتباه وارد کرده.
در این موارد بنده فکر کردم خب چون این اشتباهات ثابت شدن که کار نفوذگر نبودن، پس ما باید اونا رو از سیستم حذف کنیم.
بخاطر همین بنده این کار رو میکنم. یعنی مثلا کاربر 5 بار اشتباه وارد کرده، در بار ششم با موفقیت وارد میشه، همون موقع که وارد شد تاریخچهء ورودهای اشتباه قبلی (فقط ورودهای اشتباه همون کاربر و برای همون اکانت و نه دیگرانی که میتونن هکر بوده باشن) از سیستم حذف میشه. یعنی همون موقع که کاربر با موفقیت لاگین شد اگر لاگ آوت کنه و دوباره بخواد لاگین کنه، کپچا نمیاد و انگار هیچ تلاش اشتباهی در کار نبوده.
بنده این کار رو با ذخیرهء لاگین های اشتباه در کوکی انجام میدم. یعنی هر بار که کاربر مشخصات اشتباه وارد میکنه، این در کوکی مرورگر کاربر در سمت کلاینت هم ثبت میشه، وقتی کاربر با موفقیت وارد شد اونوقت به همون تعداد که در کوکی ثبت شده از تعداد لاگین های اشتباه برای اون اکانت خاص (اکانتی که کاربر موفق شده بهش وارد بشه) کم میشه.
تاجاییکه یادمه، در کوکی برای هر لاگین اشتباه، نام کاربری وارد شده و timestamp مربوطه ذخیره میشن. بعدا که لاگین موفق بود، رکوردهای متناظر با این زوج ها از لاگ سیستم پاک میشن.

خیلی روشن و دقیق نگفتید، اما فکر کنم شما با نتیجهء عملکرد همین سیستم مواجه شدید. درسته؟

البته این سیستم تاجاییکه یادمه نه تنها در این بخش، بلکه در بخش محدودیت بر اساس IP هم بکار رفته.
این خودش یه ابتکار و باریک بینی بود که در این پروژه پیاده کردم. بخاطر اینکه میخواستم الگوریتم و منطق اون بی نقص و دقیق باشه.

----------


## eshpilen

فرض کنید در سیستم ما مثلا بعد از 6 بار تلاش لاگین ناموفق، اکانت کاربر قفل میشه.
خب فرضا کاربر واقعی میاد و 3 بار تلاش لاگین اشتباه میکنه، بعد وارد میشه، خب تا اینجا درست، بعد از مدتی دوباره خارج میشه، بعد دوباره از روی همون سیستم یا جای دیگه میخواد لاگین کنه و 3 بار دیگه اشتباه وارد میکنه، و اینجاست که اکانتش قفل میشه، درحالیکه از نظر منطقی نباید قفل میشد.
همینطور برای نیاز به کپچا.
من بخاطر همین مسائل این سیستم رو اینطور طراحی کردم.
این هوشمندی خاصی رو به سیستم اضافه میکنه.
چرا سیستم باید اینقدر خنگ باشه که اینطور منطقش از نظر user friendly ضعیف عمل کنه؟
کسی که با وجود تمام محدودیت های امنیتی و تعداد تلاشهای محدودی که در اختیارش بوده در نهایت با موفقیت وارد شده، هکر نبوده، اگر هم هکر بوده شانس زیادی داشته یا به هر دلیل دیگری مثل خیلی ضعیف بودن پسورد کاربر با موفقیت به اکانت نفوذ کرده (پسوردش رو بدست آورده) و بنابراین دیگه دلیلی نداره بخوایم اون لاگین های اشتباه قبلی طرف رو در سیستم نگه داریم.
سیستم قفل فقط برای جلوگیری از Brute-force پسورد کاربر توسط دیگران است. اگر خود کاربر بوده باشه، این سیستم نباید جلوش رو بگیره، و اگر این سیستم نتونست از کشف شدن پسورد کاربر جلوگیری کنه، دیگه کاری که نباید میشده انجام شده و نفوذ صورت گرفته. اینکه بخوایم بعدش دوباره اکانت رو قفل کنیم، دیگه مزیتی از نظر امنیتی نداره یا مزیت خیلی کمی داره، و درمقابل یوزرفرندلی رو کم میکنه و میتونه برای خیلی از کاربران مشکل ساز بشه.

----------


## MMSHFE

نه ببینید، توی صفحه ای که CAPTCHA میاد کافیه توی آدرس بار یکبار کلیک کنید و Enter رو بزنید تا CAPTCHA حذف بشه. این نشون میده که CAPTCHA وابسته به Requestهای مکرر هست. خوب اگه طرف بخواد Bruteforce بزنه و هربار جداگانه Request بفرسته (با cURL یا هر روش دیگه)، اصلاً با CAPTCHA مواجه نمیشه چون درخواستهاش Independent هستن. حالا ممکنه سایر بحثها مثل IP Block و... رو گذاشته باشین ولی بهرحال CAPTCHA شما قابل غیرفعال شدنه.

----------


## eshpilen

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

مهندس چرا تست دقیق نکرده بهتون میزنی؟  :لبخند گشاده!: 

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

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

----------


## eshpilen

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

----------


## MMSHFE

من فقط توضیح مشکلی که دوستمون بهش برخورده بودن رو گذاشتم که بدونید منظورشون چی بوده. بطور کلی توی این سیستمها روال کار اینه که وقتی یکنفر چندبار سعی در ورود اشتباه داشت، به محض ورود، CAPTCHA رو ببینه. اینکار هم یا با IP و یا با هر روش دلخواه دیگه انجام میشه ولی بهرحال CAPTCHA باید فوراً بیاد. بد نیست نگاهی به سیستمهای بانکی بندازین. حتی مدیریت این سیستم با کوکی هم نقص محسوب میشه چون میتونه حذفش کنه. اتفاقاً اینکه با واردکردن نام و رمز صحیح، بازهم CAPTCHA بیاد خودش نقص بدتریه. اگه قراره بهرحال CAPTCHA رو وارد کنه، چرا از اول نشونش ندیم؟ قصدمون که اذیت کردن کاربر نیست.

----------


## MMSHFE

دقت کنید که در Bruteforce یا Dictionary Attack یا هر روش دیگه، معمولاً نام کاربری ثابته و رمز عوض میشه. بخاطر همینه که اکثراً IP یا Agent رو بلاک میکنن و CAPTCHA میگذارن. حالا اگه کاربر نام کاربری دیگری رو هم میخواد چک کنه، چون چند بار اشتباه وارد کرده، باید CAPTCHA رو هم وارد کنه یا مثل سیستمهای مؤدب امروزی، یک لینک بگذارین (Try a different user account) و اونجا CAPTCHA نیاد (اگه دوباره همین User رو وارد کرد، باز CAPTCHA بیاد). بهرحال این سیستم شما الآن User Friendly نیست و اصولی هم نیست چون براساس User account کار میکنه، درحالی که الآن اگه User accountها تغییر کنن، تا 3 بار میشه برای هر User Account بدون مواجه شدن با CAPTCHA رمز چک کرد و یک سرور Bot Net با چک کردن تعداد زیادی زوج Username / Password بطوری که در هر روز Username تکراری بیش از سه بار چک نشه، هیچوقت با CAPTCHA مواجه نمیشه. تازه طبق توضیحاتتون میتونه با پاک کردن Cookieها دوباره Username قبلی رو چک کنه.

----------


## eshpilen

> دقت کنید که در Bruteforce یا Dictionary Attack یا هر روش دیگه، معمولاً نام کاربری ثابته و رمز عوض میشه. بخاطر همینه که اکثراً IP یا Agent رو بلاک میکنن و CAPTCHA میگذارن. حالا اگه کاربر نام کاربری دیگری رو هم میخواد چک کنه، چون چند بار اشتباه وارد کرده، باید CAPTCHA رو هم وارد کنه


خب منم این سیستم کپچا و بلاک بر اساس IP رو هم گذاشتم. هر دوی سیستم بر اساس اکانت و بر اساس IP رو داره برنامهء بنده. تنظیماتشون هم کاملا از هم جداست. میشه دوتاش فعال باشه، میشه یکیش فعال باشه، و تنظیمات تعداد لاگین اشتباه برای کپچا و قفل شدن هم در هر دوی اینها کاملا جدا از هم و قابل تغییره.




> تازه طبق توضیحاتتون میتونه با پاک  کردن Cookieها دوباره Username قبلی رو چک کنه.


نه اینطور نیست.
شاید اشتباه متوجه شدید.
اون کوکی فقط برای کاربری هست که در نهایت قبل از اینکه تعداد تلاشهای لاگین اشتباه به حداکثر ممکن در بازهء زمانی خاص برسه، موفق به لاگین میشه. پاک کردنش هم هیچ سودی برای هکر نداره. برای کاربر هم هیچ سودی نداره. چون فقط برای کاربرانی که موفق به لاگین میشن، یعنی کاربران واقعی، سودمندی از نظر یوزرفرندلی داره و لاغیر. حتی اگر هکر کوکی جعلی ایجاد کنه، نمیتونه باهاش کاری بکنه.
بنده تمام این موارد رو تحلیل کردم و درنظر گرفتم.
الکی نیست که! خیلی حساب شده کار کردم؛ مواردی که بنظرم میرسید رو هم کاملا تست کردم  :چشمک: 
تلاشهای لاگین اشتباه در دیتابیس در سمت سرور هم ذخیره میشن. اون کوکی فقط یه مکمل هست برای یوزرفرندلی و سیستم از نظر امنیتی بهش اتکا نداره. چه پاکش بکنه کسی، چه جعلیش رو ایجاد کنه، نمیتونه باهاش امنیت سیستم رو دور بزنه.
محدودیت های امنیتی فقط با چک کردن رکوردهای دیتابیس در سمت سرور اعمال میشن. کوکی فقط مال موقعی هست که کاربر موفق به لاگین میشه و اونوقت فقط همون تلاشهای لاگین اشتباه برای همون اکانت که کاربر قبل از لاگین داشته رو حذف میکنیم، که اینم تقریبا خطری برای امنیت نداره. اون کوکی اگر حذف شده باشه هیچی نمیشه از نظر امنیتی، و فقط سطح امنیت بیخودی در «تحت حمله» باقی میمونه.
دقت کنید که این کوکی تنها بعد از لاگین موفق استفاده میشه. قبلش هیچ تاثیری در محدودیت های امنیتی سیستم نداره و اصلا استفاده نمیشه ازش در جایی.

----------


## MMSHFE

خوب این خیلی خوبه ولی مشکل User Friendly بودن همچنان پابرجاست. بهتره اون رو هم رفع کنید. توی سیستمهای لاگین، معمولاً IP یا Agent بلاک میشه نه اکانت و اگه قراره اکانت بلاک بشه، باید با AJAX یا هر روش دیگه، به محض اینکه دیدین Account واردشده توی فهرست Block هست، CAPTCHA رو ظاهر کنید. اینکه کاربر حتی با واردکردن رمز صحیح، مجبور بشه اطلاعات رو بخاطر اینکه شما بهش CAPTCHA رو نشون نداده بودین، دوباره وارد کنه اصلاً خوب نیست.

----------


## eshpilen

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

البته بعضی موارد رو قبول دارم که بهتره اضافه بشن. مثل همین که همون موقع که نام کاربری وارد شد، بصورت ایجکس با سمت سرور چک بشه که کپچا لازمه یا نه، نه اینکه فرم سابمیت بشه و بعد با پیام خطا دوباره به کاربر برگشت داده بشه و کاربر مجبور به وارد کردن مجدد پسوردش باشه.
ولی خب این مورد اساسی ای نبود و شاید عجله داشتم و به همین خاطر انجامش ندادم. شایدم به ذهنم نرسید اون موقع. یادم نیست. خلاصه سرم شلوغ بود با خیلی افکار و مسائل دیگه.

----------


## eshpilen

> معمولاً IP یا Agent بلاک میشه نه اکانت


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

اگر بلاک بر اساس اکانت نباشه، نمیشه محافظت حداکثری در برابر Brute-force داشت. چون بقول خودتون Botnet و این حرفا و تازه افراد معمولی هم معمولا میتونن به تعداد قابل توجهی IP دسترسی داشته باشن اگر یخورده وارد باشن و به خودشون زحمت بدن.
ولی باید سیستم بلاک بر اساس اکانت قابل تنظیم و خاموش کردن هم باشه تا در مواردی که خودش مورد سوء استفاده جهت حمله های DOS قرار میگیره بشه از شرش خلاص شد.

در سیستم بنده هم تنظیمات کپچا و بلاکش از هم جداست. میتونیم تعیین کنیم هر اکانتی که مثلا 3 بار پسورد اشتباه وارد میشه بعد از اون کپچا بخواد، ولی هیچوقت قفل نشه. بازهء زمانی هم قابل تنظیمه که این 3 بار در چه بازهء زمانی باشه.

راستی استفاده از Agent راه اصولی ای نیست.

----------


## abolfazl-z

> فرض کنید در سیستم ما مثلا بعد از 6 بار تلاش لاگین ناموفق، اکانت کاربر قفل میشه.
> خب فرضا کاربر واقعی میاد و 3 بار تلاش لاگین اشتباه میکنه، بعد وارد میشه،  خب تا اینجا درست، بعد از مدتی دوباره خارج میشه، بعد دوباره از روی همون  سیستم یا جای دیگه میخواد لاگین کنه و 3 بار دیگه اشتباه وارد میکنه، و  اینجاست که اکانتش قفل میشه، درحالیکه از نظر منطقی نباید قفل میشد.
> همینطور برای نیاز به کپچا.
> من بخاطر همین مسائل این سیستم رو اینطور طراحی کردم.
> این هوشمندی خاصی رو به سیستم اضافه میکنه.
> چرا سیستم باید اینقدر خنگ باشه که اینطور منطقش از نظر user friendly ضعیف عمل کنه؟
> کسی که با وجود تمام محدودیت های امنیتی و تعداد تلاشهای محدودی که در  اختیارش بوده در نهایت با موفقیت وارد شده، هکر نبوده، اگر هم هکر بوده  شانس زیادی داشته یا به هر دلیل دیگری مثل خیلی ضعیف بودن پسورد کاربر با  موفقیت به اکانت نفوذ کرده (پسوردش رو بدست آورده) و بنابراین دیگه دلیلی  نداره بخوایم اون لاگین های اشتباه قبلی طرف رو در سیستم نگه داریم.
> سیستم قفل فقط برای جلوگیری از Brute-force پسورد کاربر توسط دیگران است.  اگر خود کاربر بوده باشه، این سیستم نباید جلوش رو بگیره، و اگر این سیستم  نتونست از کشف شدن پسورد کاربر جلوگیری کنه، دیگه کاری که نباید میشده  انجام شده و نفوذ صورت گرفته. اینکه بخوایم بعدش دوباره اکانت رو قفل کنیم،  دیگه مزیتی از نظر امنیتی نداره یا مزیت خیلی کمی داره، و درمقابل  یوزرفرندلی رو کم میکنه و میتونه برای خیلی از کاربران مشکل ساز بشه.


چرا از مهندس بگیر میشین  :لبخند گشاده!:  ایشون اومدن فقط گفته های من (noob) را توضیح بیشتری دادن.
خوب دوست عزیز من که کد ها را نخوندم (:O) حجم اش بالا است و خیلی وقت گیر هست. توضیح هم که ندادید! خودم هم یکم به این مضوع شک کردم. 
ولی حرکت قشنگی زدین.

----------


## eshpilen

بنده از شما تشکر میکنم  :بوس: 
چون همینکه تست میکنید و نظرتون رو میگید واسه من هم به رایگان کاری انجام دادید  :چشمک: 
حتی اگر اشتباه کرده باشید، بازم این حرکت شما میتونه مفید باشه؛ خیلی وقتا اینطوره!

----------

