آسیب پذیری Rate Limiting

Rate Limiting چیست؟

در طول آزمایش‌های نفوذ ما بر روی پلتفرم‌های وب، یکی از اصلی‌ترین بردارهای حمله که ما اغلب برای کشف و بهره‌برداری از آسیب‌پذیری‌ها استفاده می‌کنیم، محدود کردن نرخ است .

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

• حملات انبوه DoS (انکار سرویس) که شامل ایجاد تعداد زیادی درخواست به منظور بارگذاری بیش از حد سرور و در نتیجه جلوگیری از پردازش درخواست‌های قانونی آن است.
• حملات انکار سرویس هدفمندتر، شامل فراخوانی مکرر نقاط پایانی و عملکردهای برنامه فشرده با منابع با هدف مشابه با حمله قبلی است.
• حملات Brute Force ، شامل تلاش برای ترکیب های متعدد ورود به سیستم/رمز عبور به منظور به دست آوردن یک جلسه در پلت فرم و در نتیجه سرقت یک حساب کاربری.
• حملات Enumeration ، همانطور که از نام آن پیداست، شامل شمارش منابع پلتفرم با تلاش برای تکرار بر روی آنها است. این می تواند لیستی از شناسه ها، نام فایل ها، نام کاربری و غیره باشد.

همه این حملات را می توان با اجرای یک فرآیند ضروری که تعداد درخواست هایی را که مشتری می تواند به سرور ارسال کند محدود می کند: محدود کردن نرخ.

محدود کردن نرخ می تواند اشکال مختلفی داشته باشد، که ما با جزئیات بیشتر در مورد آنها صحبت خواهیم کرد. اما قبل از آن، نمونه‌های ملموسی از حملات brute force را ارائه می‌کنیم که به دلیل عدم محدودیت نرخ، امکان کشف و بهره‌برداری از آسیب‌پذیری‌های حیاتی را فراهم می‌کنند.

اجرای محدودیت نرخ برای مقابله با حملات brute force

عدم محدودیت نرخ، توکن brute force و تصاحب حساب کاربری

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

Login : kevin@plateforme.test 
Mot de passe : 558573 

Login : kevin@plateforme.test 
Mot de passe : 922145 

Login : kevin@plateforme.test 
Mot de passe : 498144 

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

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

عدم محدودیت نرخ، گذرواژه و 2FA brute force

بسیار آسان است که از عدم محدودیت نرخ به عنوان مثال، با استفاده از یک فرم ورود به سیستم، یک رمز عبور بی رحمانه استفاده کنید. تنها کاری که مهاجم باید انجام دهد این است که رمز عبوری را که قبلاً در یک فایل کامپایل و/یا ایجاد کرده است، یکی یکی امتحان کند

در مثال بالا، می‌توانیم ببینیم که سرور زمانی که درخواست ورود به سیستم را با کلمه عبور “peter” ارسال می‌کنیم، پاسخ متفاوتی می‌دهد. رمز عبور معتبر است و ما اکنون با حسابی وارد شده ایم که متعلق به ما نیست.

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

تکنیک های پیاده سازی محدود کننده نرخ چیست؟

محدود کردن نرخ جهانی

این محدودیت معمولاً در سطح سرور (یا پروکسی که در وهله اول درخواست‌ها را دریافت می‌کند، در صورت وجود) است و شامل حذف درخواست‌ها از IPهایی است که درخواست‌های زیادی ایجاد می‌کنند.

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

اما متأسفانه برای مقابله با حملات هدفمندتر کافی نیست. برای آن نیاز داریم…

محدود کردن نرخ هدفمند

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

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

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

در طول تست نفوذ، با ویژگی‌ای مواجه شدیم که به ما امکان می‌داد یک PDF از داده‌های JSON تولید کنیم. اجرای همزمان تعداد زیادی فایل پی دی اف حافظه سرور را به طور کامل اشباع کرد و سرویس را از دسترس خارج کرد. در این حالت می توان یک صف ایجاد کرد.

با این حال، یک مورد مشکل ساز وجود دارد: اگر رفتار کاربر مشکوک اما به طور بالقوه “عادی” باشد چه؟ به عنوان مثال، در موردی که 5 تلاش ناموفق برای ورود به سیستم انجام شده است، آیا فقط یک کاربر رمز عبور خود را فراموش کرده است یا یک عامل مخرب سعی در سرقت یک حساب کاربری دارد؟ چه باید کرد؟

مدیریت ربات و محدود کردن نرخ: مثالی از CAPTCHA

اکثریت قریب به اتفاق حملاتی که با محدودیت نرخ کاهش می‌یابند توسط ربات‌ها انجام می‌شوند. هیچ مهاجمی به صورت دستی تلاش نمی کند 1,000,000 رمز عبوری را که برای سرقت یک حساب کاربری قابل قبول تشخیص داده اند حدس بزند: آنها کار را به یک ماشین محول می کنند.

اما ماشین‌ها یک نقطه ضعف دارند: آن‌ها در تشخیص الگوها در تصاویر «آشوب» مشکل زیادی دارند، این دقیقاً همان چیزی است که یک CAPTCHA (تست تورینگ عمومی کاملاً خودکار برای تشخیص رایانه‌ها و انسان‌ها) نیاز دارد: یک فرم کوچک که مانع از ارسال درخواست تا زمانی می‌شود. مشتری الگوی مورد نظر را تشخیص می دهد که می تواند دنباله ای از حروف و اعداد، دایره ای باز در میان دایره های بسته، علائم، یک نوع وسیله نقلیه باشد

ویدیو آموزشی Rate Limiting