بررسی Account Enumeration and Guessable User Account
در این بخش از دوره آموزشی OWASP-WSTG به دومین بخش از استاندارد WSTG با شناسه WSTG-IDNT-04 می پردازیم که مربوط به بررسی Account Enumeration and Guessable User Account می باشد.
خلاصه
هدف از این تست بررسی این موضوع است که آیا امکان جمع‌آوری مجموعه‌ای از نام‌های کاربری معتبر از طریق تعامل با مکانیزم احراز هویت برنامه وجود دارد یا خیر.
اطلاعات به دست آمده در این تست برای حملات Brute Force مفید خواهد بود، که در آن تست نفوذگر با داشتن نام کاربری معتبر تایید می‌کند که آیا امکان پیدا کردن رمز عبور متناظر وجود دارد یا خیر.
اغلب، در برنامه‌های کاربردی وب، زمانی نام کاربری در سیستم وجود دارد، این موضوع توسط برنامه آشکار می‌گردد. این موضوع ممکن است در نتیجه پیکربندی نادرست بوده و یا به عنوان یک تصمیم در طراحی برنامه باشد.
برای مثال، گاهی اوقات، هنگامی که ما اعتبارنامه‌های اشتباه را ارسال می‌کنیم، پیامی را دریافت می‌کنیم که می‌گوید یا نام کاربری بر روی سیستم وجود دارد یا رمز عبور ارائه‌شده اشتباه است. اطلاعات به‌دست‌آمده می‌تواند توسط یک مهاجم برای به دست آوردن فهرستی از کاربران در سیستم مورد استفاده قرار گیرد. از این اطلاعات می‌توان برای حمله به برنامه کاربردی وب استفاده کرد.
تست نفوذگر باید با مکانیزم احراز هویت برنامه تعامل داشته باشد تا بفهمد که آیا ارسال درخواست‌های خاص باعث می‌شود برنامه به شیوه‌های مختلف پاسخ دهد یا خیر. این مساله به این دلیل وجود دارد که اطلاعات منتشر شده از برنامه‌های کاربردی وب یا سرور وب در زمانی که کاربر نام کاربری معتبری را ارایه می‌دهد، متفاوت از زمانی است که کاربر از نام کاربری نامعتبر استفاده می‌کند.
در بعضی موارد ، پیامی دریافت می‌شود که نشان می‌دهد credential ارائه شده اشتباه است زیرا از نام کاربری یا رمز ورود نامعتبر استفاده شده است. گاهی اوقات، تست نفوذگر می‌تواند با ارسال یک نام کاربری و یک رمز عبور خالی، کاربران موجود را شناسایی نماید.
اهداف تست
فرآیندهای مربوط به شناسایی کاربر را بررسی کنید (برای مثال ثبت‌نام، ورود به سیستم و غیره). کاربران را در صورت امکان از طریق تجزیه و تحلیل پاسخ، شناسایی یا Enumerate نمایید.
چگونه امتحان کنیم
در آزمایش جعبه سیاه، تست نفوذگر چیزی در مورد برنامه خاص، نام کاربری، منطق برنامه، پیام‌های خطا در صفحه لاگین یا امکانات بازیابی رمز عبور نمی‌داند. اگر برنامه آسیب‌پذیر باشد، تست نفوذگر پیام پاسخی را دریافت می‌کند که به طور مستقیم یا غیر مستقیم، برخی اطلاعات مفید برای شناسایی کاربران را نشان می‌دهد.
HTTP Response Message
تست به منظور اعتبارسنجی Credential ها
زمانی که یک User ID و گذرواژه معتبر را ارسال می‌کنید، پاسخ سرور را ثبت کنید.
با استفاده از یک پروکسی وب، به اطلاعات بازیابی شده از این احراز هویت موفق توجه کنید :
HTTP 200 Response
Length of the response
تست به منظور اعتبارسنجی کاربر معتبر با گذرواژه اشتباه
اکنون، تست نفوذگر باید سعی کند یک User ID معتبر را به همراه یک رمز عبور اشتباه وارد کند و پیام خطای ایجاد شده توسط برنامه را ثبت کند.
مرورگر باید پیامی شبیه به پیغام زیر را نمایش دهد:
برخلاف هر پیامی که وجود کاربر را مانند موارد زیر نشان می‌دهد:
Login for User foo: invalid password
با استفاده از یک پروکسی وب، به اطلاعات بازیابی شده از این احراز هویت موفق توجه کنید:
HTTP 200 Response
Length of the response
تست به منظور شناسایی عدم وجود نام کاربری
اکنون، تست نفوذگر باید سعی کند یکUser ID نامعتبر را به همراه یک رمز عبور اشتباه وارد کند و پاسخ سرور را ثبت کند (تست نفوذگر باید مطمئن باشد که نام کاربری در برنامه معتبر نیست). در این بخش نیز باید پیغام خطا و پاسخ سرور ثبت گردد.
اگر تست نفوذگر یک User ID غیر موجود را وارد نموده باشد، پیامی شبیه به پیام زیر را دریافت خواهد کرد:
یا پیامی مانند پیام زیر:
Login failed for User foo: invalid Account
به طور کلی برنامه باید با پیام خطا و طول یکسان به درخواست‌های نادرست مختلف پاسخ دهد. اگر پاسخ‌ها یکسان نباشند، تست نفوذگر باید تفاوت بین این دو پاسخ را بررسی و پیدا کند. برای مثال:
• Client request: Valid user/wrong password
• Server response: The password is not correct
• Client request: Wrong user/wrong password
• Server response: User not recognized
پاسخهای بالا به client این امکان را می‌دهد تا نام کاربری معتبر را شناسایی نماید. بنابراین آن‌ها می‌توانند با ارتباط گرفتن با برنامه و ارسال درخواست به آن و مشاهده پاسخ، مجموعه‌ای از User ID های موجود را استخراج نمایند.
راه‌های دیگر برای شناسایی کاربران
تست نفوذدگر می‌توانند کاربران را به چندین روش شمارش کنند، مانند:
تجزیه و تحلیل کد خطای دریافتی در صفحات ورود به سیستم
برخی برنامه‌های کاربردی وب، یک کد خطا یا پیام خاص را منتشر می‌کنند که ما می‌توانیم آن را تحلیل کنیم.
تجزیه و تحلیل آدرس‌ها و آدرس‌ها Re-directions
برای مثال:
همانطور که در بالا دیده می‌شود، زمانی که تست نفوذگر یک شناسه کاربری و رمز عبور را به برنامه کاربردی وب ارسال می‌کند، پیامی را می‌بینند که نشان می‌دهد یک خطا در URL رخ داده‌است. در مورد اول، آن‌ها نام کاربری و رمز عبور اشتباه را وارد نموده اند. در مرحله دوم، نام کاربری صحیح و رمز عبور اشتباه وارد شده است، بنابراین به همین طریق و بررسی پیام‌های خطا، آن‌ها می‌توانند نام‌های کاربری معتبر را شناسایی کنند.
URI Probing
برخی اوقات، یک وب سرور در صورتی که درخواستی برای وجود یا عدم وجود دایرکتوری دریافت نماید، پاسخهای متفاوتی خواهد داد. به عنوان مثال در برخی از پورتال‌ها هر کاربر با یک دایرکتوری در ارتباط است. اگر تست نفوذگر برای دسترسی به دایرکتوری موجود تلاش کنند، می‌تواند خطای سرور وب را دریافت کنند.
برخی از خطاهای رایج دریافتی از سرورهای وب عبارتند از:
403 Forbidden error code
404 Not found error code
مثال:
www.foo.com/account1 – we receive from web server: 403 Forbidden
www.foo.com/account2 – we receive from web server: 404 file Not Found
در حالت اول کاربر وجود دارد، اما تست نفوذگر نمی‌تواند صفحه وب را ببیند، در حالت دوم کاربر “account2” وجود ندارد. با جمع‌آوری این اطلاعات، تست کنندگان می‌توانند کاربران را شناسایی نمایند.
تحلیل Title صفحه وب
تست نفوذگران می‌توانند اطلاعات مفیدی را در Title صفحه وب دریافت کنند، که در آن می‌توانند کد خطا یا پیام‌های خاصی را به دست آورند که نشان می‌دهد آیا مشکلی با نام کاربری یا رمز عبور وجود دارد یا خیر.
به عنوان مثال، اگر یک کاربر نتواند به یک برنامه احراز هویت کند و یک صفحه وب دریافت کند، Title صفحه می‌تواند شبیه به موارد زیر باشد:
Invalid user
Invalid authentication
تجزیه و تحلیل یک پیغام دریافت‌شده از یک بخش بازیابی
هنگامی که ما از بخش بازیابی (به عنوان مثال یک تابع فراموشی رمز عبور) یک برنامه آسیب‌پذیر استفاده می‌کنیم ممکن است پیامی بازگشت داده شود که امکان شناسایی نام های کاربری را فراهم نماید. برای مثال، پیغام‌های مشابه با موارد زیر را در نظر بگیرید:
Invalid username: email address is not valid or the specified user was not found.
Valid username: Your password has been successfully sent to the email address you registered with.
پیغام خطای دوستانه ۴۰۴
هنگامی که ما یک کاربر را در دایرکتوری درخواست می‌کنیم که وجود ندارد، همیشه ۴۰۴ کد خطا دریافت نمی‌کنیم.
در عوض، ممکن است کد “200 OK” را با یک تصویر دریافت کنیم، در این مورد می‌توانیم فرض کنیم که وقتی تصویر خاصی را دریافت می‌کنیم، کاربر وجود ندارد.
این منطق را می‌توان برای دیگر پاسخهای سرور وب نیز به کار برد.
این ترفند، تحلیل مناسبی از وب سرور و برنامه‌های کاربردی وب است.
تحلیل زمان پاسخ
علاوه بر بررسی محتوای پاسخ‌ها، زمانی که پاسخ دریافت می‌شود نیز باید در نظر گرفته شود. به خصوص هنگامی که درخواست موجب تعامل با یک سرویس خارجی می‌شود (مانند ارسال یک ایمیل برای فراموشی کلمه عبور)، این می‌تواند چند صد میلی‌ثانیه به پاسخ اضافه کند که می‌تواند برای تعیین وجود کاربر درخواست‌شده مورد استفاده قرار گیرد.
Guessing Users
در برخی موارد شناسه کاربر با سیاست‌های خاص مدیر یا شرکت ایجاد می‌شود. به عنوان مثال می‌توانیم کاربرانی با User ID ای که با اعداد متوالی ایجاد شده است را مشاهده کنیم:
گاهی اوقات نام‌های کاربری با نام مستعار REALM و سپس اعداد متوالی ایجاد می‌شوند:
• R1001 – user 001 for REALM1
• R2001 – user 001 for REALM2
در نمونه بالا ما می‌توانیم شل اسکریپت‌های ساده‌ای را ایجاد کنیم که از شناسه کاربر تشکیل شده و یک درخواست با ابزاری مانند wget به منظور خودکار کردن یک پرس و جوی وب برای شناسایی کاربران ارسال نماید. از Perl و curl نیز می‌توان برای ایجاد چنین اسکریپت‌هایی استفاده نمود.
سایر احتمالات عبارتند از:
شناسه کاربر مرتبط با شماره کارت‌های اعتباری یا در اعدادی با یک الگو مشخص.
شناسه کاربران مرتبط با نام‌های واقعی، به عنوان مثال اگر Freddie Mercury دارای ID کاربر به صورت “fmercury” باشد، پس ممکن است حدس بزنید که نام کاربری Roger Taylo برابر با “rtaylor” باشد.
باز هم، می‌توانیم نام کاربری را از اطلاعات دریافتی از یک پرسوجوی LDAP یا از جمع‌آوری اطلاعات گوگل، برای مثال، از یک دامنه خاص حدس بزنیم. گوگل می‌تواند به یافتن کاربران دامنه از طریق پرس وجوهای خاص یا از طریق شل اسکریپت یا ابزارهای ساده دیگر به ما کمک کند.
انجام فرآیند شناسایی یا Enumerate نمودن حساب‌های کاربری، ممکن است ریسک قفل شدن حساب‌ها را پس از ارسال درخواست‌های متعدد به همراه داشته باشد که این موضوع بستگی به سیاست های برنامه دارد. همچنین، گاهی اوقات، ممکن است آدرس IP شما توسط قوانین موجود بر روی فایروال یا سیستم پیشگیری از نفوذ (IDS) مسدود شود.
آزمایش جعبه خاکستری
تست پیغام‌های خطای احراز هویت
تأیید کنید که برنامه برای هر درخواست کلاینت که تأیید اعتبار ناموفق را ایجاد می کند، به روش یکسان پاسخ می دهد. در این مسئله، تست جعبه سیاه و تست جعبه خاکستری بر اساس تجزیه و تحلیل پیام‌ها یا کدهای خطای دریافت شده از برنامه وب، مفهوم مشابهی دارند. برنامه باید به شیوه یکسانی به هر تلاش ناموفق احراز هویت پاسخ دهد.
برای مثال:
Credentials submitted are not valid
Remediation
اطمینان حاصل کنید که برنامه، پیام‌های خطای عمومی یکسانی را در پاسخ به نام حساب نامعتبر، رمز عبور یا دیگر اعتبارات کاربر وارد شده در طول ورود به سیستم باز می‌گرداند.
اطمینان از اینکه حساب‌های پیش‌فرض سیستم و حساب‌های تست قبل از انتشار سیستم در محیط Production، حذف می‌شوند (یا هنگامی که آن را در معرض یک شبکه غیرقابل اعتماد قرار می‌دهند).
ابزارها
• ZAP
• curl
• Perl
