2024年3月6日追記
「AWS の最新情報」にニュースとして公開されていましたが、現在は404になっているようです。また、WAFログを再度確認したところ、正規表現に関するルールステートメントを用いたルールで検知した場合の検知箇所が掲載されない状態となっています。

【目次】

  1. 1. はじめに
  2. 2. 検知内容の記載箇所
  3. 3. SQL インジェクション攻撃ルールステートメントでBLOCKした場合
  4. 4. 正規表現一致ルールステートメントでBLOCKした場合
  5. 5. AWSのマネージドルールでBLOCKした場合
  6. 6. 文字列一致ルールステートメントの場合
  7. 7. COUNTでの検知の場合
  8. 8. WafCharmルールの場合
  9. 9. おわりに

1. はじめに

2024年2月27日に、正規表現一致ルールステートメントあるいは正規表現パターンセット一致ルールステートメントを用いたルールで検知した場合、WAFログに検知箇所が記載されるというアップデートがリリースされました。
AWS WAF now supports ruleMatchDetails for Regex rules

本ブログ記事では、WAFログに記載される内容について確認します。

2. 検知内容の記載箇所

正規表現に関するルールステートメントを用いたルールで検知した場合、WAFログの 「terminatingRuleMatchDetails」や「nonTerminatingMatchingRules」という項目以下に検知した内容の詳細が記載されるようです。

テスト時のWAFログを見る限り、ステートメントなどによる細かい違いはありますが、共通している項目は以下の通りでした。

  • conditionType：条件の種類。正規表現一致ルールステートメントの場合はREGEXと記載される。SQL インジェクションおよびクロスサイトスクリプティング (XSS) 一致ルールステートメントの場合は、SQL_INJECTIONなどステートメントに応じた値が記載される。
  • location：検知した位置。クエリストリングの場合はQUERY_STRING、ボディの場合はBODYなどと記載される。
  • matchedData：検知した内容。
  • matchedFieldName：JSONボディやヘッダーなどでマッチした場合に、フィールド名が記載される。

なお、WAFログに記載される項目やその内容については AWS公式ドキュメントのログフィールドのページ に詳細がありますが、リリース時点での日本語訳では以下のように記載されており、以前の情報のままになっているように見受けられます。

これは、SQL インジェクションおよびクロスサイトスクリプティング (XSS) 一致ルールステートメントに対してのみ設定されます。一致ルールでは、複数の検査基準の一致が必要になる場合があるため、これらの一致の詳細は、一致基準の配列として提供されます。

以降では、複数のステートメントを用いたルールで実際にテストを行ってみます。
※WAFログは検知箇所に関する情報が記載されている項目のみを抜粋します。

3. SQL インジェクション攻撃ルールステートメントでBLOCKした場合

上記の通り、SQL インジェクションおよびクロスサイトスクリプティング (XSS) 一致ルールステートメントでは、これまでも「terminatingRuleMatchDetails」などに検知箇所の詳細が記載される仕組みでした。

今回のリリースによる更新ではありませんが、参考としてどのように記載されるかを確認したところ、以下の通りとなりました。
「SQL_INJECTION」のステートメントで、ボディに含まれていた値でマッチしたことがわかります。
リクエストで送信したボディデータは1行のデータでしたが、WAFログの「matchedData」では単語ごとの記載となりました。 

    "terminatingRuleMatchDetails": [
        {
            "conditionType": "SQL_INJECTION",
            "location": "BODY",
            "matchedData": [
                "select",
                "a",
                "from",
                "b"
            ],
            "matchedFieldName": "",
            "sensitivityLevel": "LOW"
        }
    ],

4. 正規表現一致ルールステートメントでBLOCKした場合

テストとして、ボディに「matched * data」という文字列が含まれていたら検知するルールを作成し、「this body contains matched data」という内容を送信しました。

正規表現のルールステートメントのため、「REGEX」かつボディでの検知となっています。
「matchedData」には、実際にマッチした部分のみが記載されます。
今回の場合、送信したボディデータは「this body contains matched data」ですが、「this body contains」の部分は検知箇所に該当しないため記載されません。

なお、正規表現ステートメントの場合、「matched data」に記載される値は1行となっており、単語ごとに別れることはありませんでした。この点がAWSが提供するSQL インジェクションやXSSのステートメントと異なるようです。 

        "terminatingRuleMatchDetails": [
            {
                "conditionType": "REGEX",
                "location": "BODY",
                "matchedData": [
                    "matched data"
                ],
                "matchedFieldName": ""
            }
        ],

また、どの程度の長さのデータが「matchedData」に記載されるのか確認したところ、以下の通りある程度の長さであれば検知箇所全体が記載されるようです。 

    "terminatingRuleMatchDetails": [
        {
            "conditionType": "REGEX",
            "location": "BODY",
            "matchedData": [
                "matched --------------random string for demo------------ data"
            ],
            "matchedFieldName": ""
        }
    ],

なお、「matchedData」は、テストした限りでは1000バイトまで記載可能なようです。
AWS公式ドキュメントでは、英語版でのみ以下の通り記載がありました。

The logs can report up to 1 K of the matching string for each rule, and truncates the string at 1 K.

検知箇所の冒頭（例：matched）と、末尾（例：data）の間に多数の文字があり、1000バイトを超えた場合、末尾の「data」については記載がされません。
また、日本語における注意点として、文字数ではなくバイト数でのカウントのため、日本語のデータの場合には記載される文字数がさらに少なくなります。

「matchedData」単体では検知箇所全体を確認できない場合がありますので、データが大きい場合には注意が必要です。

5. AWSのマネージドルールでBLOCKした場合

AWSが提供するマネージドルールでも、検知内容が記載されます。

コアルールセット (CRS) マネージドルールグループを用いてテストしたところ、これまでの例と同じようにデータが記載されました。 

        "terminatingRuleMatchDetails": [
            {
                "conditionType": "REGEX",
                "location": "BODY",
                "matchedData": [
                    "http://1.1.1.1"
                ],
                "matchedFieldName": ""
            }
        ],

なお、AWS公式ドキュメントにも記載の通り、CRSマネージドルールグループのクロスサイトスクリプティングのルールについてはクロスサイトスクリプティング攻撃ルールステートメントを使用しているため、SQLインジェクションステートメントと似た記載となっています。 

    "terminatingRuleMatchDetails": [
        {
            "conditionType": "XSS",
            "location": "BODY",
            "matchedData": [
                "<",
                "script"
            ],
            "matchedFieldName": ""
        }
    ],

6. 文字列一致ルールステートメントの場合

リリース内容に記載の通り、検知箇所の記載は正規表現に関するステートメントのみが対象となります。
実際に文字列一致ルールステートメントを用いたルールを作成しテストしてみたところ、「terminatingRuleMatchDetails」の箇所は空になりました。 

    "terminatingRuleMatchDetails": [],

文字列一致ルールステートメントは単純な文字列で一致させたい場合などには便利ですが、もしWAFログにて検知箇所を記載させたい場合は、ルールを作成する際に、正規表現一致ルールステートメントを使用する必要があります。

7. COUNTでの検知の場合

ルールアクションCOUNTで検知した場合は、「nonTerminatingMatchingRules」の「ruleMatchDetails」に詳細が記載されます。

上記の正規表現一致ルールステートメントで用いたルールで、アクションをCOUNTにした場合は以下のようになります。 

        "nonTerminatingMatchingRules": [
            {
                "ruleId": "regex-statement",
                "action": "COUNT",
                "ruleMatchDetails": [
                    {
                        "conditionType": "REGEX",
                        "location": "BODY",
                        "matchedData": [
                            "matched data"
                        ],
                        "matchedFieldName": ""
                    }
                ]
            }
        ],

仮にCOUNTルールの後ろにBLOCKルールがあり、両方のルールで検知した場合は以下のように「terminatingRuleMatchDetails」と「nonTerminatingMatchingRules」の両方に検知内容が記載されます。

以下では、ヘッダーに「test」と含まれていた場合にBLOCKするルールが追加された状態でテストしています。 

    "terminatingRuleMatchDetails": [
        {
            "conditionType": "REGEX",
            "location": "ANY_HEADER",
            "matchedData": [
                "test"
            ],
            "matchedFieldName": "test"
        }
    ],
（割愛）
    "nonTerminatingMatchingRules": [
        {
            "ruleId": "regex-statement",
            "action": "COUNT",
            "ruleMatchDetails": [
                {
                    "conditionType": "REGEX",
                    "location": "BODY",
                    "matchedData": [
                        "matched data"
                    ],
                    "matchedFieldName": ""
                }
            ]
        }
    ],

8. WafCharmルールの場合

WafCharmルールはAWS WAFが提供する各種ルールステートメントを用いて構成されています。
そのため、WafCharmルールでも正規表現に関するルールステートメントを用いているルールでの検知の場合は、以下のように「terminatingRuleMatchDetails」に詳細が記載される仕組みとなっています。 

        "terminatingRuleMatchDetails": [
            {
                "conditionType": "REGEX",
                "location": "BODY",
                "matchedData": [
                    "../../"
                ],
                "matchedFieldName": ""
            }
        ],

上記の通り、正規表現に関するルールステートメントを使用していない場合にはデータは記載されませんが、WafCharmルールで検知が発生し、検知箇所を知りたいといった場合にはWAFログの「terminatingRuleMatchDetails」の箇所もご参考ください。

※セキュリティの観点より、WafCharmルールの詳細は公開しておりません。

9. おわりに

これまではWAFログにはボディデータや検知箇所の詳細などは記載されていなかったため、特にボディデータに含まれる内容で検知した際は別途ボディデータの取得を行う必要があり、検知箇所の特定が難しい場合がありました。

正規表現に関するルールステートメント使用しているルールであることが前提とはなりますが、今回のリリースによりWAFログを確認するだけで検知箇所の特定ができるようになります。

データのサイズによっては検知箇所全体を把握することは難しいものの、誤検知が発生した際の調査や対応もやりやすくなったのではないでしょうか。