Antipattern: استخدام محددات كمية كبيرة في سياسة RegionExpressionProtection

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X.
المعلومات

تُحدِّد سياسة regexionProtection التعبيرات العادية التي يتم تقييمها في وقت التشغيل وفقًا لمعلَمات الإدخال أو متغيّرات التدفق. يمكنك عادةً استخدام هذه السياسة للحماية من تهديدات المحتوى، مثل إدخال SQL أو JavaScript، أو للتحقّق من معلَمات الطلب التي تمت صياغتها بشكل غير صحيح، مثل عناوين البريد الإلكتروني أو عناوين URL.

يمكن تحديد التعبيرات العادية لمسارات الطلبات ومَعلمات طلب البحث ومَعلمات النماذج والعناوين وعناصر XML (في حمولة XML معرَّفة باستخدام XPath) وسمات كائن JSON (في حمولة JSON المحدّدة باستخدام JSONPath).

يعمل المثال التالي على حماية السياسة URIExpressionProtection الخلفية من هجمات حقن SQL:

<!-- /antipatterns/examples/greedy-1.xml -->
<RegularExpressionProtection async="false" continueOnError="false" enabled="true"
  name="RegexProtection">
    <DisplayName>RegexProtection</DisplayName>
    <Properties/>
    <Source>request</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <QueryParam name="query">
      <Pattern>[\s]*(?i)((delete)|(exec)|(drop\s*table)|
        (insert)|(shutdown)|(update)|(\bor\b))</Pattern>
    </QueryParam>
</RegularExpressionProtection>

مضادة للأنماط

محدِّدات الكميات التلقائية (* و+ و?) طبيعية في الطبيعة، حيث تبدأ في المطابقة مع أطول تسلسل ممكن. عند عدم العثور على أي تطابق، يتراجع تدريجيًا لمحاولة مطابقة النمط. إذا كانت السلسلة الناتجة التي تطابق النمط قصيرة جدًا، فيمكن أن يستغرق استخدام محددات الكميات الجشعة وقتًا أكثر من اللازم. وينطبق هذا على وجه الخصوص إذا كانت الحمولة كبيرة (بالعشرات أو المئات من الكيلوبايت).

يستخدم المثال التالي للتعبير مثيلات متعددة من .*، وهي عوامل تشغيل طيعة:

<Pattern>.*Exception in thread.*</Pattern>

في هذا المثال، تحاول سياسة RegionExpressionProtection أولاً مطابقة أطول تسلسل ممكن، السلسلة بأكملها. وفي حال عدم العثور على أي نتائج مطابقة، تتراجع السياسة بشكل تدريجي. إذا كانت السلسلة المطابقة قريبة من بداية الحمولة أو منتصفها، يمكن أن يستغرق استخدام أداة تحديد كمّية كبيرة مثل .* وقتًا وقوة معالجة أكبر بكثير من المؤهِّلات المترددة مثل .*? أو مُحدِّدات الكم (الأقل شيوعًا) مثل .*+.

تبدأ مُحدِّدات الكميات المترددة (مثل X*? وX+? وX??) بمحاولة مطابقة حرف واحد من بداية الحمولة وإضافة الأحرف تدريجيًا. تحاول محدِّدات الكميات الكبيرة (مثل X?+ وX*+ وX++) مطابقة الحمولة بالكامل مرة واحدة فقط.

بالنظر إلى النص النموذجي التالي للنمط أعلاه:

Hello this is a sample text with Exception in thread
with lot of text after the Exception text.

واستخدام .* الجشع غير جيد في هذه الحالة. يتطلّب النمط .*Exception in thread.* 141 خطوة للمطابقة. إذا استخدمت النمط .*?Exception in thread.* (الذي يستخدم أداة تحديد كمّية مترددة) بدلاً من ذلك، ستكون النتيجة 55 خطوة فقط.

التأثير

يمكن أن يؤدي استخدام محددات الكميات غير المرغوب فيها، مثل أحرف البدل (*) مع سياسة regexionProtection إلى ما يلي:

  • زيادة في وقت الاستجابة الإجمالي لطلبات واجهة برمجة التطبيقات ذات حجم حمولة متوسط (يصل إلى 1 ميغابايت)
  • وقت أطول لإكمال تنفيذ سياسة EnterpriseExpressionProtection
  • تعذُّر تنفيذ طلبات واجهة برمجة التطبيقات ذات الحمولات الكبيرة (أكبر من 1 ميغابايت) مع ظهور أخطاء "مهلة البوابة 504" في حال انقضت فترة المهلة المحدّدة مسبقًا على جهاز توجيه Edge
  • استخدام وحدة معالجة مركزية (CPU) بشكل كبير في معالِجات الرسائل بسبب كمية المعالجة الكبيرة التي يمكن أن تؤثر بشكل أكبر في الطلبات الأخرى من واجهة برمجة التطبيقات

أفضل ممارسة

  • تجنَّب استخدام مُحدِّدات الكميات الجسيمة مثل .* في التعبيرات العادية من خلال سياسة قاعدتي وسيلة للتعبير العادي. بدلاً من ذلك، استخدِم أدوات تحديد كمّية مترددة، مثل .*? أو أدوات قياس الكمية مثل .*+ (الأقل شيوعًا) كلما أمكن ذلك.

محتوى إضافي للقراءة