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