أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلىمستندات Apigee X. info
تحدّد سياسة RegularExpressionProtection التعبيرات العادية التي يتم تقييمها في وقت التشغيل على مَعلمات الإدخال أو متغيّرات التدفق. عادةً ما تستخدم هذه السياسة للحماية من التهديدات المتعلّقة بالمحتوى، مثل هجمات حقن تعليمات SQL أو JavaScript، أو للتحقّق من مَعلمات الطلب غير الصالحة، مثل عناوين البريد الإلكتروني أو عناوين URL.
يمكن تحديد التعبيرات العادية لمسارات الطلبات أو مَعلمات طلب البحث أو مَعلمات النموذج أو العناوين أو عناصر XML (في حمولة XML محدّدة باستخدام XPath) أو سمات كائن JSON (في حمولة JSON محدّدة باستخدام JSONPath).
تحمي سياسة RegularExpressionProtection التالية الواجهة الخلفية من هجمات حقن تعليمات 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>
في هذا المثال، تحاول سياسة RegularExpressionProtection أولاً مطابقة أطول تسلسل ممكن
، أي السلسلة بأكملها. وفي حال عدم العثور على تطابق، تتراجع السياسة تدريجيًا. إذا كانت السلسلة المطابِقة قريبة من بداية الحمولة أو منتصفها، قد يستغرق استخدام أداة تحديد كمية جشعة، مثل .*، وقتًا أطول بكثير وقوة معالجة أكبر من أدوات تحديد الكمية المترددة، مثل .*? أو (بشكل أقل شيوعًا) أدوات تحديد الكمية التملّكية، مثل.*+.
تبدأ أدوات تحديد الكمية المترددة (مثل 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 خطوة فقط.
التأثير
يمكن أن يؤدي استخدام أدوات تحديد الكمية الجشعة، مثل أحرف البدل (*)، مع الـ
RegularExpressionProtection policy إلى ما يلي:
- زيادة في وقت الاستجابة الإجمالي لطلبات البيانات من واجهة برمجة التطبيقات لحجم حمولة معتدل (يصل إلى 1 ميغابايت)
- وقت أطول لإكمال تنفيذ سياسة RegularExpressionProtection
- فشل طلبات البيانات من واجهة برمجة التطبيقات التي تتضمّن حمولات كبيرة (>1 ميغابايت) مع ظهور أخطاء 504 Gateway Timeout Errors إذا انقضت فترة المهلة المحدّدة مسبقًا على جهاز التوجيه في Edge
- ارتفاع استخدام وحدة المعالجة المركزية (CPU) في معالِجات الرسائل بسبب حجم المعالجة الكبير، ما قد يؤثر أيضًا في طلبات البيانات الأخرى من واجهة برمجة التطبيقات
أفضل ممارسة
- تجنَّب استخدام أدوات تحديد الكمية الجشعة، مثل
.*، في التعبيرات العادية مع سياسة RegularExpressionProtection. بدلاً من ذلك، استخدِم أدوات تحديد الكمية المترددة، مثل.*?أو أدوات تحديد الكمية التملّكية، مثل.*+(بشكل أقل شيوعًا)، كلما أمكن ذلك.