Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
regularExpressionProtection की नीति ऐसे रेगुलर एक्सप्रेशन के बारे में बताती है जिनका आकलन इनपुट पैरामीटर या फ़्लो वैरिएबल पर रनटाइम के समय किया जाता है. आम तौर पर, इस नीति का इस्तेमाल SQL या JavaScript इंजेक्शन जैसे कॉन्टेंट से जुड़े खतरों से बचाने के लिए या ईमेल पते या यूआरएल जैसे गलत अनुरोध पैरामीटर की जांच करने के लिए किया जाता है.
रेगुलर एक्सप्रेशन को अनुरोध के पाथ, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर, हेडर, एक्सएमएल एलिमेंट (XPath का इस्तेमाल करके तय किए गए एक्सएमएल पेलोड में), JSON ऑब्जेक्ट एट्रिब्यूट (JSONPath का इस्तेमाल करके तय किए गए JSON पेलोड में) के लिए तय किया जा सकता है.
नीचे दिए गए उदाहरण की JournalExpressionProtection नीति बैकएंड को एसक्यूएल इंजेक्शन के हमलों से बचाती है:
<!-- /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 नीति के साथ वाइल्डकार्ड (*) में लालची संख्या बढ़ाने वाले टूल का इस्तेमाल करने पर, ये नुकसान हो सकते हैं:
- सामान्य पेलोड साइज़ के लिए, एपीआई अनुरोधों के इंतज़ार के कुल समय में बढ़ोतरी (1 एमबी तक)
- regularExpressionProtection नीति को पूरा करने में ज़्यादा समय लग रहा है
- Edge राऊटर पर पहले से तय टाइम आउट पीरियड खत्म हो जाने पर, बड़े पेलोड (1 एमबी से ज़्यादा) वाले एपीआई अनुरोध 504 गेटवे टाइम आउट की गड़बड़ियों के साथ पूरे नहीं हो पाते थे
- ज़्यादा प्रोसेस होने की वजह से, मैसेज प्रोसेसर के लिए सीपीयू का बहुत ज़्यादा इस्तेमाल किया जाता है. इससे, एपीआई के अन्य अनुरोधों पर भी असर पड़ सकता है
सबसे सही तरीका
- regularExpressionProtection नीति की मदद से, रेगुलर एक्सप्रेशन में
.*जैसे लालची मात्राओं का इस्तेमाल करने से बचें. इसके बजाय, जहां भी मुमकिन हो,.*?जैसे बिना इच्छा वाले क्वांटफ़ायर का इस्तेमाल करें. इसके अलावा, जहां भी मुमकिन हो वहां.*+जैसे क्वांटिफ़ायर का इस्तेमाल न करें.