反模式：在 RegularExpressionProtection 政策中使用灰色量詞

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。 資訊

RegularExpressionProtection 政策定義可在以下位置評估的規則運算式： 執行非同步作業通常使用這項政策來防範 SQL 或 JavaScript 插入等內容威脅，或檢查是否有格式錯誤的請求參數 例如電子郵件地址或網址

您可以為要求路徑、查詢參數、form 參數 標頭、XML 元素 (使用 XPath 定義的 XML 酬載)、JSON 物件屬性 (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)，則傳回 true。

以下運算式使用多個是貪婪的 .* 例項 運算子：

<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 政策可能導致：

  • 中等酬載大小的 API 要求整體延遲時間增加 (最多 1 MB)
  • 規則運算式保護政策的執行時間較長
  • 含有大量酬載 (超過 1 MB) 的 API 要求失敗，並顯示 504 Gateway 逾時錯誤， 邊緣路由器的預先定義逾時期限
  • 由於處理量眾多，訊息處理器的 CPU 使用率偏高， 影響其他 API 要求

最佳做法

  • 避免在規則運算式中使用 .* 等貪婪的量詞 RegularExpressionProtection 政策。建議您改用替代量詞，例如 .*? 或 .*+ 等式量詞 (較不常見)

延伸閱讀