مشورت در باره سناریو هایی که می تواند جلوی حملات دیکشنری یا brute force را بگیرد

با درود خدمت دوستان گرامی . این پست رو زدم هم یافته های خودمو در این مکان جمع آوری کنم و هم از مشورت شما که مهمترین عنصری هست که باعث ایجاد این پست شده است , نیز سودمند شوم .

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

راه حل هایی که من در نظر گرفتم به شرح زیر می باشد :

برای بخش ثبت نام

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

منبع : https://stackoverflow.com/a/2965775/6310900

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

دیگه ایده ای برای بخش ثبت نام ندارم که جلوی ربات یا افراد رو بگیرم برای اینکه این بخش از وب سرویس من امن بماند و دست مایه حملات زیادی برای اشغال کردن آن نشود مخصوصا ثبت نام های زیاد

برای بخش ورود به کاربر

در این بخش علاوه بر ip که بالا در مورد آن صحبت کردم . تصمیم بر این داشتم با دو الی سه بار اشتباه به صاحب اکانت ایمیل بفرستم و حملات بیشتر از ۸ عدد شد اکانت را لاک کنم و برای کاربر ایمیلی بفرستم که در آن کد فعال سازی وجود داشته باشد .

لازم به ذکر هست من کاربران خودم رو مجبور به قرارداد پسورد خوب و قوی می کنم که با چند درخواست لو نرود


حل تمام مواردی که در فکر من بود همین مقدار هست . حال نیازمند مشورت شما بزرگواران هستیم برای امن سازی وب سرویسی که نه کپچا دارد نه جایی برای CSRF که بتواند کمک حال ما شود .

1 پسندیده

چرا بخش ورود کابر csrf و ریکپچا نداره؟ این یعنی لطفا ما رو هک کنید
CSRF و کچپچا ندارد یعنی json api؟

با محدود کردن تعداد تلاش ورد ناموفق و مجبور کردن کاربر به استفاده از پسورد های پیچیده تقریبا جلوی این مشکل گرفته میشه، ip هم لازم نیست محدودیت دائم داشته باشه، میتونیم ip و یوزرو به یه مدت اول کوتاه و هرچی تعداد تلاش نا موفق بیشتر شد به مدت بلندتر به صورت موقت برای ورود بلاک کنیم.
درضمن two factor authentication یک روش خیلی کاربردی دیگست که خیلی منطق ساده ای داره اما خیلی کاربردیه.

1 پسندیده

درود توماج جان .

کاربر در اپلیکیشن موبایل هست چطور می تونه وقتی می خواد درخواستی رو به وب سرویس از اپلیکیشنش داشته باشه CSRF داشته باشه ؟

وقتی من درخواستی رو به گوگل می فرستم به وسیله json api کپچایی ندارم و همینطور CSRF

به همین منظور گفتم نداریم و جایگزینش چی هست ؟

1 پسندیده

اصلاح شد^

1 پسندیده

اولش پرسیدم که آیا json api ؟

1 پسندیده

آها ببخشید متوجه نشدم ببخشید بله برای json api می باشد

1 پسندیده

پس قسمت ریکپچا و csrf و در نظر نگیر :hugs:

1 پسندیده

این محدود سازی رو با IP می فرمایید یا موردی دیگری منظور شماست توماج جان ؟

هم ip و هم یوزر، و یک ایمیل هم به کاربر فرستاده بشه که کسی چندین بار سعی کرده وارد حسابش بشه و پسوردشو عوض کنه

1 پسندیده

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

بخش ثبت نام هست . کاربر با آیپی های مختلف ثبت نام کرده در زمان کوتاه و ایمیل های زادی هم برای فعال سازی .

برای اون چی پیشنهاد می کنید ؟

بیشتر توضیح بده، این دلیل نگرانی چیه؟

1 پسندیده

مثال کاربران زیادی در مدت زمان کمی ثبت نام کنند با آیپی های مختلف . و شروع به اسپم در بخش های متعدید با اکانت های زیاد.

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

خب این خیلی از موضوع این بحث خارجه، اما چنتا راه حل وجود داره، که کاربردی ترینش کنترل انسانیه

1 پسندیده

راستی اون بالا وقتی عرض کردم هم ip به صورت موقت بلاک بشه و هم یوزر هدفم این نبود که بگم یوزر کلا بلاک بشه، فقط برای ورد و یوزری که قبلا با دیوایس لاگین کرده به استفاده ادامه بده

1 پسندیده

ممنون توماج جان . فکر کنم باید برم دنبال اینکه ببنیم آیپی رو کجا برای مدت زمان کوتاهی بلاک کنم . به نظر شما ردیس برای مدت زمان کوتاه می تونه مکان خوبی باشه؟

1 پسندیده

میتونی بعد چند(۳-۵) بار اشتباه وارد کردن رمز در ردیس یک key برای کاربر بگذاری که بعد یک ربع از بین میره با expiration تا وقتی این key وجود داره نگذار کاربر login کنه

2 پسندیده

بله پاسخ سام بهتره، برای همین پاک کردم

1 پسندیده