الحد من معدل الطلبات¶

يتم تضمين استهلاك موارد غير محدود في قائمة أعلى 10 مخاطر لأمان API في OWASP 2023. نقص تحديد معدل الطلبات هو واحد من الأسباب الرئيسية لهذا المخاطر. بدون تدابير تحديد معدل الطلبات المناسبة، تكون واجهات برمجة التطبيقات معرضة للهجمات مثل الحرمان من الخدمة (DoS)، هجوم القوة الغاشمة، واستخدام API بشكل مفرط. توضح هذه المقالة كيفية حماية واجهة برمجة التطبيقات والمستخدمين مع قاعدة تحديد معدل الطلبات في Wallarm.

تقدم Wallarm قاعدة تعيين الحد من معدل الطلبات ‏‎ لمساعدتك في منع وصول الكثير من الطلبات إلى واجهة برمجة التطبيقات. تتيح لك هذه القاعدة تحديد الحد الأقصى لعدد الاتصالات التي يمكن تأمينها بشكل معين، مع ضمان توزيع الطلبات الواردة بسلاسة. إذا تجاوز الطلب الحد المحدد، يرفض Wallarm الطلب ويعيد الرمز الذي حددته في القاعدة.

Wallarm يفحص مختلف المعلمات الطلب مثل الكوكيز أو حقول JSON، مما يتيح لك الحد من الاتصالات لا يعتمد فقط على عنوان IP المصدر، ولكن أيضا على معرفات الجلسة، أسماء المستخدمين، أو عناوين البريد الإلكتروني. يتيح لك هذا الدقة المضافة تعزيز الأمان العام للمنصة على أي بيانات المنشأ.

لاحظ أن التحديد المعدل التي وصفتها في هذه المقالة هي أحد الطرق التي تقدمها Wallarm للتحكم في الحمل - بدلاً من ذلك، يمكنك تطبيق الحماية من هجمات القوة الغاشمة. استخدم الحد من معدل الطلبات لإبطاء الحركة الواردة وحماية القوة الغاشمة لحظر المهاجم تماماً.

إنشاء القاعدة وتطبيقها¶

لتعيين وتنفيذ الحد من معدل الطلبات:

انتقل إلى وحدة تحكم Wallarm → قواعد → إضافة قاعدة.
في إذا كان الطلب هو، صف نطاق تطبيق القاعدة عليه.
في ثم، اختر تعيين الحد من معدل الطلبات وحدد حدودا مرغوبة للاتصالات بنطاقك:
- الحد الأقصى لعدد الطلبات في الثانية أو الدقيقة.
- الانفجار - الحد الأقصى لعدد الطلبات الزائدة التي يمكن تخزينها مؤقتاً بمجرد تجاوز RPS / RPM المحدد والتي ستتم معالجتها بمجرد أن يعود المعدل إلى حالته الطبيعية. 0 كمعدل افتراضي.
  
  إذا كانت القيمة مختلفة عن 0، يمكنك التحكم في ما إذا كان سيتم الحفاظ على RPS / RPM المحدد بين تنفيذ الطلبات الزائدة المخزنة مؤقتاً.
  
  لا يوجد تأخير يشير إلى معالجة جميع الطلبات الزائدة المخزنة مؤقتا في وقت واحد، من دون تأخير في معدل الطلبات. التأخير يعني المعالجة المتزامنة للعدد المحدد من الطلبات الزائدة، والباقي تتم معالجتهم بتأخير معدل الطلبات في الثانية أو الدقيقة.
- رمز الاستجابة - الرمز الذي يجب إرجاعه كرد على الطلبات المرفوضة. 503 كمعدل افتراضي.
  
  أدناه مثال على سلوك الحد من معدل الطلبات بحد 5 r/s، انفجار 12 وتأخير 8.
  
  تتم نقل الطلبات الـ 8 الأولى (قيمة التأخير) بواسطة وحدة Wallarm بدون تأخير. يتم تأجيل الطلبات الـ 4 التالية (انفجار - تأخير) حتى لا يتجاوز الحد المحدد من 5 r/s. يتم رفض الطلبات الـ 3 التالية لأنه قد تم تجاوز حجم الانفجار الإجمالي. يتم تأجيل الطلبات اللاحقة.
في في هذا الجزء من الطلب، حدد نقاط الطلب التي ترغب في تحديد حدود لها. سيقوم Wallarm بتقييد الطلبات التي لديها نفس القيم لمعلمات الطلب المحددة.

يتم وصف جميع النقاط المتاحة هنا، يمكنك اختيار تلك التي تتناسب مع حالتك الخاصة، على سبيل المثال :
- remote_addr للحد من الاتصالات من عنوان IP المصدر
- json → json_doc → hash → api_key لتحديد الحد للاتصالات من العنصر api_key في جسم JSON
قيود على طول القيمة

أقصى طول مسموح به لقيم المعلمات التي تقيس حدودها هو 8000 رمز.
انتظر حتى يكتمل تجميع القاعدة.

أمثلة على القواعد¶

الحد من الاتصالات بواسطة IP لضمان توفر API بشكل عالي¶

بفتراض وجود شركة للرعاية الصحية تمتلك واجهة برمجة التطبيقات REST التي تتيح للأطباء تقديم معلومات المرضى من خلال طلب POST لنقطة النهاية /patients المضيفة لـ https://example-host.com. توفر هذه النقطة المنتهية هي في غاية الأهمية، ولذا فالجوانب الأمنية لمعلومات المرضى لا يجب أن تتعرض لكثير من الطلبات.

يمكن أن يحد الاتصالات بواسطة IP في فترة معينة خصيصًا لنقطة النهاية /patients من تسبب هذا. وهذا يضمن استقرار نقطة النهاية وتوفرها لجميع الأطباء، مع حماية الأمن أيضًا لمعلومات المرضى من الهجمات DoS.

على سبيل المثال، يمكن تعيين الحد على 5 طلبات POST في الدقيقة لكل عنوان IP على النحو التالي:

تحديد الاتصالات بواسطة الجلسات لمنع هجمات القوة الغاشمة على المعلمات الأمنية¶

من خلال تطبيق تحديد المعدل على الجلسات المستخدم، يمكنك التقييد ضربات القوة الغاشمة لإيجاد JWTs الحقيقية أو معلمات الاستيثاق الأخرى من أجل الوصول غير المصرح به إلى الموارد المحمية. على سبيل المثال، إذا جعلت القاعدة تسمح فقط بـ 10 طلبات في الدقيقة تحت جلسة، سيصل المهاجم الذي يحاول اكتشاف JWT صالحة بإجراء طلبات كثيرة بأعداد مختلفة من الرموز سريعًا إلى حد المعدل، وسيتم رفض طلباته حتى ينتهي فترة القيد.

بالافتراض أن تطبيقك يعين كل جلسة استخدم على نحو فريد من خلال واحد ويعكس عليه في رأس X-SESSION-ID. في هذه الحالة، تقبل نقطة النهاية للواجهة على ال URL https://example.com/api/login الطلبات POST التي تتضمن JVMware JWT في رأس Authorization. في هذا السيناريو، ستكون القاعدة التي تحد الاتصالات بواسطة الجلسات كما يلي:

الـregexp المستخدم لقيمة Authorization هو ^Bearer\s+([a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+[.][a-zA-Z0-9-_]+)$.

إذا كنت تستخدم JWT (كود تطبيقات JSON ويب) لإدارة جلسات المستخدمين، يمكنك ضبط القاعدة لـفك تشفير JWT واستخراج ID الجلسة من حمولتها على النحو التالي:

تحديد الاتصالات بواسطة معرفات العملاء لمنع الإرهاق في الخادم¶

دعنا نفترض وجود خدمة ويب توفر الوصول إلى بيانات الطلبات للعملاء لمنصة التجارة الإلكترونية. يمكن أن يساعد الحد من معدل الطلبات على معرفات العملاء في منع العملاء من تقديم الكثير من الطلبات في فترة زمنية قصيرة، والتي قد تضغط على إدارة المخزون وتلبية الطلبات.

على سبيل المثال، قد تبدو القاعدة التي تحدد عدد الطلبات لكل عميل في 10 طلبات POST في الدقيقة إلى https://example-domain.com/orders بالشكل التالي. يراعي هذا السيناريو عنوان البريد الإلكتروني و يعتبر المدرج اكتشاف في كائن الجسم JSON data.customer_id.

القيود والخصائص¶

تتميز وظيفة الحد من معدل الطلبات بالقيود والخصائص التالية:

يتم دعم الحد من معدل الطلبات في جميع أشكال نشر Wallarm باستثناء الصورة لـ Docker المبنية على على Envoy.
أقصى طول مسموح به لقيم المعلمات التي تقيس حدودها هو 8000 رمز.
إذا كان لديك عقدات Wallarm متعددة والحركة الواردة على كل عقدة تفي بقاعدة الحد من معدل الطلبات، يتم تحديدهم بشكل مستقل.
عندما تطبق قواعد الحد من المعدل على الطلبات الواردة، يتم استخدام القاعدة ذات الحد الأدنى لتحديد الطلبات.
إذا كان الطلب الوارد لا يحتوي على النقطة المحددة في قسم القاعدة في هذا الجزء من الطلب، فإن هذه القاعدة لا تعتبر محددة لذلك الطلب.
إذا تم تكوين خادم الويب الخاص بك للحد من الاتصالات (مثل استخدام وحدة ngx_http_limit_req_module NGINX) وكنت تطبق القاعدة أيضًا، فإن الخادم الويب يرفض الطلبات حسب القواعد المعدة ولكن Wallarm لا يفعل.
لا يحفظ Wallarm الطلبات التي تتجاوز الحد من معدل الطلبات، بل يرفضها فقط من خلال إرجاع الرمز الذي تم اختياره في القاعدة. الاستثناء هو الطلبات مع علامات الهجوم - يتم تسجيلها بواسطة Wallarm حتى لو تم رفضها بواسطة قاعدة الحد من معدل الطلبات.