WSTG-ATHN-03

بررسی Weak Lock Out Mechanism

در این بخش از دوره آموزشی OWASP-WSTG به چهارمین بخش از استاندارد WSTG با شناسه WSTG-ATHN-03 می پردازیم که مربوط به بررسی Weak Lock Out Mechanism می باشد.

خلاصه

مکانیزم‌های مسدودسازی حساب برای کاهش حملاتbrute force استفاده می‌شوند. برخی از حملاتی که می‌توان با استفاده از مکانیزم مسدودسازی، آن‌ها را شکست داد:

• حمله حدس زدن نام کاربری یا کلمه عبور
• حدس کد مربوط به احراز هویت دو مرحله‌ای یا سوالات امنیتی.

مکانیزم‌های مسدودسازی حساب نیاز به تعادل بین حفاظت از حساب‌ها در برابر دسترسی غیرمجاز و حفاظت از کاربران در برابر عدم دسترسی مجاز دارد. حساب‌ها معمولا پس از ۳ تا ۵ تلاش ناموفق قفل می‌شوند و تنها پس از یک دوره زمانی از پیش تعیین‌شده، از طریق یک مکانیزم آزاد سازی خدمات خودکار، یا مداخله یک مدیر، از حالت قفل، خارج می‌شوند.

با وجود آسان بودن انجام حملات Brute Force، نتیجه یک حمله موفق خطرناک است زیرا مهاجم دسترسی کامل به حساب کاربری و تمام امکانات و خدماتی که به آن دسترسی دارد را خواهد داشت.

اهداف تست

• بررسی قابلیت مکانیزم مسدودسازی حساب برای کاهش حدس کلمه عبور و حملات Brute Force
• ارزیابی مقاومت مکانیزم باز کردن قفل حساب غیرمجاز

چگونه تست را انجام دهیم

مکانیسم Lockout

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

برای ارزیابی توانایی مکانیزم قفل کردن حساب در کاهش حدس زدن کلمه عبور قوی، سعی کنید قبل از استفاده از کلمه عبور صحیح برای تایید این که حساب قفل شده‌است، با استفاده از کلمه عبور نادرست چند بار وارد سیستم شوید. یک تست نمونه ممکن است به شرح زیر باشد:

  1. تلاش برای ورود با گذرواژه نادرست ۳ بار.
  2. با رمز عبور صحیح وارد سیستم شوید، در صورت ورود موفقیت آمیز، نشان دهنده این موضوع است که مکانیزم قفل کردن پس از سه تلاش تایید هویت نادرست اجرا نمی‌شود.
  3. تلاش برای ورود با گذرواژه نادرست ۴ بار.
  4. با رمز عبور صحیح وارد سیستم شوید، در صورت ورود موفقیت آمیز، نشان دهنده این موضوع است که مکانیزم قفل کردن پس از چهار تلاش تایید هویت نادرست اجرا نمی‌شود.
  5. تلاش برای ورود با گذرواژه نادرست ۵ بار.
  6. تلاش کنید با گذرواژه صحیح وارد سیستم شوید. برنامه پیام “حساب شما قفل شده‌است.” را باز می‌گرداند، در نتیجه تایید می‌کند که حساب پس از ۵ تلاش احراز هویت نادرست قفل شده‌است.
  7. ۵ دقیقه بعد تلاش کنید با کلمه عبور صحیح وارد سیستم شوید.
  8. برنامه پیام “حساب شما قفل شده‌است.” را باز می‌گرداند، در نتیجه نشان می‌دهد که مکانیزم قفل کردن به طور خودکار بعد از ۵ دقیقه باز نمی‌شود.
  9. تلاش کنید ۱۰ دقیقه بعد با کلمه عبور صحیح وارد سیستم شوید. برنامه پیام “حساب شما قفل شده‌است.” را باز می‌گرداند، در نتیجه نشان می‌دهد که مکانیزم قفل کردن به طور خودکار بعد از ۱۰ دقیقه باز نمی‌شود.
  10. ۱۵ دقیقه بعد مجدد تلاش کنید، مشاهده می کنید که با موفقیت با رمز عبور صحیح وارد سیستم شدید، این موضوع نشان می‌دهد که مکانیزم قفل به طور خودکار بعد از ۱۰ تا ۱۵ دقیقه باز خواهد شد.

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

آشنایی با WSTG-ATHN-02

یک مکانیزم کپچا را اگر به درستی پیاده‌سازی نشود، می‌توان Bypass نمود. نقص‌های مربوط به کپچا عبارتند از:

  1. چالش‌هایی که به راحتی شکست می‌خورند، مانند مجموعه سوال محدود یا قابل محاسبه.
  2. در صورتی که کپچا، کد پاسخ HTTP را به جای موفقیت آمیز بودن پاسخ بررسی کند.
  3. منطق سمت سرور CAPTCHA به طور پیش فرض یک راه حل موفق است.
  4. نتیجه چالش کپچا هرگز در سمت سرور را اعتبارسنجی نشود.
  5. فیلد ورودی یا پارامتر کپچا به صورت دستی پردازش می‌شود و به درستی تایید یا رد نمی‌شود.

برای ارزیابی اثربخشی کپچا موارد زیر مد نظر می‌باشد:

  1. چالش‌های کپچا را ارزیابی نموده و برای خودکار کردن راه‌حل‌ها بسته به دشواری، تلاش کنید.
  2. تلاش برای ارسال درخواست، بدون حل کردن CAPTCHA از طریق مکانیسم (‏های)‏ UI نرمال.
  3. تلاش برای ارسال درخواست با عدم موفقیت در چالش CAPTCHA.
  4. تلاش برای ارسال درخواست بدون حل کپچا بوسیله استفاده از یک HTTP Proxy . چرا که ممکن است مکانیزم کپچا در کدهای سمت کلاینت تنظیم شده باشد.
  5. تلاش برای فاز نمودن نقاط ورودی داده کپچا (‏در صورت وجود)‏ با تزریق پیلودهای رایج یا توالی کاراکترهای خاص.
  6. بررسی کنید که آیا راه حل CAPTCHA می‌تواند متن متناوب تصویر (ها) یا همان alt-text ، نام پرونده (ها) یا مقداری در یک قسمت پنهان مرتبط باشد.
  7. تلاش برای ارسال مجدد پاسخ‌های شناخته شده قبلی.
  8. بررسی کنید که آیا پاک کردن کوکی‌ها باعث می‌شود که کپچا Bypass شود (‏برای مثال اگر کپچا تنها بعد از چند شکست نشان داده شود)‏.
  9. اگر CAPTCHA بخشی از یک فرآیند چند مرحله ای است، سعی کنید به سادگی به یک مرحله فراتر از CAPTCHA دسترسی پیدا کنید یا آن را تکمیل کنید (به عنوان مثال اگر CAPTCHA اولین بخش از مراحل ورود به سیستم است، سعی کنید مرحله دوم [نام کاربری و رمز عبور] را ارسال کنید.)
    10ا روش‌های جایگزین دیگر را بررسی کنید که ممکن است کپچا در آن‌ها لحاظ نشده باشد، مانند یک نقطه پایانیAPI، که به منظور تسهیل دسترسی به برنامه‌های کاربردی تلفن همراه طراحی شده است.

این فرایند را برای هر قابلیت احتمالی که می‌تواند به مکانیزم قفل نیاز داشته باشد ، تکرار کنید.

مکانیسم Unlock

برای ارزیابی مقاومت مکانیزم unlock در برابر باز کردن حساب غیر مجاز، مکانیزم باز کردن را آغاز کنید و به دنبال نقاط ضعف بگردید. مکانیزم‌های معمول باز کردن ممکن است شامل Secret Question یا یک لینک Unlock که ایمیل شده است، باشد. لینک Unlock باید یک لینک تک زمانه (One-Time Link) منحصر به فرد باشد، تا مهاجم را از حدس زدن یا تکرار کردن لینک و انجام حملات Brute Force متوقف کند.

توجه داشته باشید که یک مکانیزم unlock فقط باید برای باز کردن حساب‌ها استفاده شود. این مکانیزم، مشابه مکانیزم بازیابی رمز عبور نیست، با این حال می‌تواند همان اقدامات امنیتی را دنبال کند.

Remediation

بسته به میزان ریسک، مکانیسم‌های باز کردن قفل حساب را اعمال کنید. به ترتیب از پایین ترین به بالاترین:

  1. انجام فرآیند Lockoutو Unlock براساس زمان.
  2. انجام فرآیند Unlock به صورت سلف سرویس (ارسال ایمیل Unlock به آدرس ایمیل ثبت شده)
  3. Unlockنمودن به صورت دستی توسط مدیر
  4. Unlock نمودن به صورت دستی توسط مدیر با شناسایی کاربر

عواملی که هنگام پیاده‌سازی مکانیزم قفل حساب باید در نظر گرفته شوند:

  1. خطر حدس رمز عبور brute force در برابر برنامه چیست؟
  2. آیا CAPTCHA برای کاهش این خطر کافی است؟
  3. آیا از یک مکانیزم قفل کردن سمت مشتری استفاده می‌شود (برای مثال JavaScript)‏؟ در این صورت کد سمت کلاینت را برای تست غیرفعال نمایید.
  4. بررسی تعداد تلاش‌های ورود ناموفق قبل از قفل کردن. اگر آستانه قفل کردن پایین باشد، ممکن است کاربران معتبر اغلب مسدود شوند و اگر آستانه قفل کردن بالا باشد، مهاجم می‌تواند قبل از قفل شدن حساب، تلاش بیشتری برای حمله Brute Force انجام دهد. بسته به هدف برنامه، محدوده 5 تا 10 تلاش ناموفق آستانه قفل کردن معمول است.
  5. نحوه Unlock نمودن حساب به چه صورت می باشد؟
    • به صورت دستی توسط سرپرست: این ایمن ترین روش است، اما ممکن است باعث دردسر کاربران شود و وقت “ارزشمند” مدیر را بگیرد.
    1. توجه داشته باشیدadministrator نیز باید یک روش بازیابی کلمه عبور داشته باشد تا در صورتی که حساب کاربری وی مسدود گردید، امکان بازیابی آن جود داشته باشد.
    2. اگر هدف مهاجم قفل کردن حساب‌های تمام کاربران برنامه کاربردی وب باشد، این مکانیزم Unlock ممکن است منجر به حمله انکار سرویس شود.

• بعد از یک دوره زمانی: مدت‌زمان مسدود ماندن حساب کاربری چقدر است؟ آیا این برای حفاظت از برنامه کافی است؟ به عنوان مثال. مدت زمان قفل 5 تا 30 دقیقه‌ای ممکن است سازش خوبی بین کاهش حملاتBrute Force و ایجاد مزاحمت برای کاربران معتبر باشد.

• از طریق یک مکانیزم سلف سرویس: همانطور که قبلا گفته شد، این مکانیزم سلف سرویس باید به اندازه کافی ایمن باشد تا از این که حمله‌کننده بتواند حساب‌ها را باز کند، جلوگیری نماید.

درباره نویسنده: احسان نیک آور

ممکن است دوست داشته باشید