एंटीपैटर्न: रेगुलर एक्सप्रेशन प्रोटेक्शन नीति में लालची मात्रा बढ़ाने वाले टूल का इस्तेमाल करें

यहां Apigee Edge से जुड़े दस्तावेज़ देखे जा रहे हैं.
Apigee X से जुड़े दस्तावेज़ पर जाएं. info

RegularExpressionProtection नीति में, रेगुलर एक्सप्रेशन तय किए जाते हैं. इनका आकलन, इनपुट पैरामीटर या फ़्लो वैरिएबल पर रनटाइम के दौरान किया जाता है. आम तौर पर, इस नीति का इस्तेमाल, कॉन्टेंट से जुड़े खतरों से बचाने के लिए किया जाता है. जैसे, SQL या JavaScript इंजेक्शन. इसके अलावा, इसका इस्तेमाल, गलत तरीके से फ़ॉर्मैट किए गए अनुरोध पैरामीटर की जांच करने के लिए भी किया जाता है. जैसे, ईमेल पते या यूआरएल.

रेगुलर एक्सप्रेशन को अनुरोध पाथ, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर, हेडर, XML एलिमेंट (XPath का इस्तेमाल करके तय किए गए XML पेलोड में) और JSON ऑब्जेक्ट एट्रिब्यूट (JSONPath का इस्तेमाल करके तय किए गए JSON पेलोड में) के लिए तय किया जा सकता है.

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 नीति सबसे पहले सबसे लंबी संभव सीक्वेंस से मैच करने की कोशिश करती है. यानी, पूरी स्ट्रिंग. अगर कोई मैच नहीं मिलता है, तो नीति धीरे-धीरे पीछे हटती है. अगर मैच करने वाली स्ट्रिंग, पेलोड की शुरुआत या बीच में है, तो a लालची क्वॉन्टिफ़ायर जैसे .* का इस्तेमाल करने में, अनिच्छुक क्वॉलिफ़ायर जैसे .*? या (कम सामान्य तौर पर) पोज़ेसिव क्वॉन्टिफ़ायर जैसे .*+ की तुलना में ज़्यादा समय और प्रोसेसिंग पावर लग सकती है.

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 नीति को लागू करने में ज़्यादा समय लग सकता है
  • बड़े पेलोड (>1 एमबी) वाले एपीआई अनुरोध, 504 Gateway Timeout Errors के साथ फ़ेल हो सकते हैं. ऐसा तब होता है, जब Edge Router पर पहले से तय की गई टाइम आउट की अवधि खत्म हो जाती है
  • मैसेज प्रोसेसर पर सीपीयू का इस्तेमाल ज़्यादा हो सकता है. इसकी वजह यह है कि ज़्यादा प्रोसेसिंग की ज़रूरत होती है. इससे अन्य एपीआई अनुरोधों पर भी असर पड़ सकता है

सबसे सही तरीका

  • RegularExpressionProtection नीति के साथ, रेगुलर एक्सप्रेशन में .* जैसे लालची क्वॉन्टिफ़ायर का इस्तेमाल न करें. इसके बजाय, जहां हो सके वहां .*? जैसे अनिच्छुक क्वॉन्टिफ़ायर या .*+ जैसे पोज़ेसिव क्वॉन्टिफ़ायर (कम सामान्य तौर पर) का इस्तेमाल करें.

इस बारे में और पढ़ें