অ্যান্টিপ্যাটার্ন: RegularExpressionProtection নীতিতে লোভী কোয়ান্টিফায়ার ব্যবহার করুন

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান
তথ্য

RegularExpressionProtection নীতি রেগুলার এক্সপ্রেশনকে সংজ্ঞায়িত করে যা ইনপুট প্যারামিটার বা ফ্লো ভেরিয়েবলের রানটাইমে মূল্যায়ন করা হয়। আপনি সাধারণত এসকিউএল বা জাভাস্ক্রিপ্ট ইনজেকশনের মতো বিষয়বস্তুর হুমকি থেকে রক্ষা করতে বা ইমেল ঠিকানা বা URL-এর মতো বিকৃত অনুরোধের প্যারামিটারের বিরুদ্ধে পরীক্ষা করতে এই নীতিটি ব্যবহার করেন।

রেগুলার এক্সপ্রেশনগুলি অনুরোধের পাথ, ক্যোয়ারী প্যারামিটার, ফর্ম প্যারামিটার, হেডার, এক্সএমএল উপাদান (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>

অ্যান্টিপ্যাটার্ন

ডিফল্ট কোয়ান্টিফায়ার ( * , + , এবং ? ) প্রকৃতিতে লোভী: তারা সম্ভাব্য দীর্ঘতম ক্রমটির সাথে মিলতে শুরু করে। যখন কোন মিল খুঁজে পাওয়া যায় না, তারা প্যাটার্নটি মেলানোর চেষ্টা করার জন্য ধীরে ধীরে পিছনে ফিরে যায়। যদি প্যাটার্নের সাথে মিলে যাওয়া ফলাফলের স্ট্রিং খুব ছোট হয়, তাহলে লোভী কোয়ান্টিফায়ার ব্যবহার করতে প্রয়োজনের চেয়ে বেশি সময় লাগতে পারে। এটি বিশেষ করে সত্য যদি পেলোড বড় হয় (দশ বা শত শত KB)।

নিম্নলিখিত উদাহরণ এক্সপ্রেশন .* এর একাধিক উদাহরণ ব্যবহার করে, যা লোভী অপারেটর:

<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.*

প্রভাব

RegularExpressionProtection নীতির সাথে ওয়াইল্ডকার্ড ( * ) এর মতো লোভী কোয়ান্টিফায়ার ব্যবহার করা হতে পারে:

  • একটি মাঝারি পেলোড আকারের জন্য API অনুরোধের জন্য সামগ্রিক বিলম্বে বৃদ্ধি (1MB পর্যন্ত)
  • RegularExpressionProtection নীতির বাস্তবায়ন সম্পূর্ণ করতে আরও বেশি সময় লাগবে
  • এজ রাউটারে পূর্বনির্ধারিত টাইমআউট পিরিয়ড শেষ হয়ে গেলে বড় পেলোড (>1MB) সহ API অনুরোধ 504 গেটওয়ে টাইমআউট ত্রুটির সাথে ব্যর্থ হয়
  • প্রচুর পরিমাণে প্রক্রিয়াকরণের কারণে মেসেজ প্রসেসরে উচ্চ CPU ব্যবহার যা অন্যান্য API অনুরোধগুলিকে আরও প্রভাবিত করতে পারে

সর্বোত্তম অনুশীলন

  • RegularExpressionProtection নীতির সাথে রেগুলার এক্সপ্রেশনে . .* পরিবর্তে, .*? অথবা .*+ (কম সাধারন) যেখানেই সম্ভব।

আরও পড়া