Knowledge Center Monthly Newsletter - March 2025
Stay up to date with the latest from the Knowledge Center. See all new and updated Knowledge Center articles published in the last month and re:Post’s top contributors.
AWS WAF の HTTP リクエストの XSS または SQLi 検査から特定の URI を除外する方法を教えてください。
AWS WAF を使用すると、特定の HTTP リクエストで SQL インジェクション (SQLi) またはクロスサイトスクリプティング (XSS) の誤検出が発生します。HTTP リクエストの XSS または SQLi 検査から特定の URI を除外したいです。
簡単な説明
AWS マネージドルールとカスタムルールの XSS および SQLi ルール検査中に、誤検出が発生することがあります。誤検出を防ぐには、XSS および SQLi 検査から特定の URI パスを除外してください。そのためには、ネストされたステートメントを使用して例外を含むブロッキングルールを記述し、AWS WAF がリクエストを他のすべてのルールと照合して評価するようにします。
解決策
HTTP または HTTPS リクエストの例
http://www.amazon.com/path/string1?xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201
前述のリクエストの URI パスは /path/string1 です。疑問符 (?) に続く文字列はクエリ文字列です。この例では、クエリ文字列は xss=%3Cscript%3E%3Cscript%3E&sql=UNION%20ALL%20SELECT%201 です。
XSS または SQLi 検査からの特定の URI を許可するルールの例
**注:**以下のルール設定の例は参照用です。PositionalConstraint、SearchString、TextTransformations などの情報については、これらのルールをカスタマイズしてください。同様のロジックを使用して、特定のヘッダーやクエリパラメーターなどの設定を許可できます。
ケース 1: AWS マネージドルールを使用する
AWS マネージドルールグループ AWSManagedRulesCommonRuleSet には、以下のルールが含まれています。
- CrossSiteScripting_COOKIE
- CrossSiteScripting_QUERYARGUMENTS
- CrossSiteScripting_BODY
- CrossSiteScripting_URIPATH
AWSManagedRulesCommonRuleSet ルールグループには、リクエストの対応する部分に XSS 攻撃文字列がないか検査する BLOCK アクションがあります。詳細については、「コアルールセット (CRS) マネージドルールグループ」を参照してください。
同様に、ルールグループ AWSManagedRulesSQLiRuleSet には、クエリパラメータ、本文、URI パス、および SQLi インジェクション攻撃パターンに関する Cookie を検査するためのルールがあります。詳細については、「ユースケース固有のルールグループ」を参照してください。
リクエストがこれらのルールに一致すると、AWS WAF は対応するラベルを生成します。次に、ウェブ ACL のカスタムルールは、これらの AWS マネージドルールラベルを使用して、一致したルール署名から特定のリクエストを選択的に除外できます。
特定の URI を許可するには、次の手順を実行します。
- AWSManagedRulesCommonRuleSet ルールグループの以下のルールを Count モードのままにしておきます。
CrossSiteScripting_COOKIE
CrossSiteScripting_QUERYARGUMENTS
CrossSiteScripting_BODY
CrossSiteScripting_URIPATH - URI パスの例外があるブロックアクションを含むルールを作成します。AWSManagedRulesCommonRuleSet の優先順位よりも低い優先度でルールを設定します。AWS WAF コンソールで優先度を低く設定するには、ルールをリストの下位に配置します。JSON の優先度を低く設定するには、優先度の値を上げてください。
このルールは次のロジックを使用します。 (XSS_URIPATH or XSS_Cookie or XSS_Body or XSS_QueryArguments) AND (NOT allowlisted URIString) = BLOCK
次の設定を使用します。
注: この例では、OrStatement は、ウェブリクエストのすべてのラベルと部分 (本文、ヘッダー、URI パス、クエリ引数) から特定の URI を除外します。この例では、ウェブリクエストのすべての部分で同じ URI に対して誤検出が発生したことを前提としています。ただし、クエリの引数など、ウェブリクエストの一部でのみ誤検出が発生する可能性があります。この場合、ウェブリクエストの一部とそれに対応するラベルにのみ個別のルールを作成するのがセキュリティのベストプラクティスです。この個別のルールでは、ウェブリクエストのすべての部分から特定の URI パスを除外しないでください。{ "Name": "whitelist-xss", "Priority": 10, "Statement": { "AndStatement": { "Statements": [ { "OrStatement": { "Statements": [ { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_URIPath" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_Cookie" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_Body" } }, { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:core-rule-set:CrossSiteScripting_QueryArguments" } } ] } }, { "NotStatement": { "Statement": { "ByteMatchStatement": { "SearchString": "/path/string1", "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "whitelist-xss" } }
AWSManagedRulesSQLiRuleSet についても同じ手順を使用しますが、ラベルを AWSManagedRulesSQLiRuleSet が生成したラベルに置き換えてください。
検査から除外したい URI が複数ある場合は、NotStatement ステートメント内で OrStatementを使用してください。たとえば、**/path/string1 ** と /path/string2 を除外するには、次の NotStatement を使用します。
{ "NotStatement": { "Statement": { "OrStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "/path/string1", "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } }, { "ByteMatchStatement": { "SearchString": "/path/string2", "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], PositionalConstraint": "CONTAINS" } } ] } } } }
ケース 2: カスタムの XSS ルールと SQLi ルールを使用する
このルールは次のロジックを使用します。
(XSS_URIPATH or XSS_Cookie or XSS_Body or XSS_QueryArguments) AND (NOT allowlisted URIString) = BLOCK
次のルール設定を使用してリクエストの XSS 攻撃文字列を検査しますが、特定の URI_PATH を選択的に除外することもできます。
{ "Name": "xss-URI", "Priority": 10, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "xss-URI" }, "Statement": { "AndStatement": { "Statements": [ { "OrStatement": { "Statements": [ { "XssMatchStatement": { "FieldToMatch": { "UriPath": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "XssMatchStatement": { "FieldToMatch": { "Cookies": { "MatchPattern": { "All": {} }, "MatchScope": "ALL", "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "XssMatchStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, { "XssMatchStatement": { "FieldToMatch": { "AllQueryArguments": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } ] } }, { "NotStatement": { "Statement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "CONTAINS", "SearchString": "/path/string1", "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } ] } } }
**SQLi ** ステートメントを使用するときは、次の手順に従ってください。
注: URI だけを許可する優先度の高いルールを設定するのはベストプラクティスではありません。これにより、許可された URI_PATH のリクエストが、ウェブ ACL で定義された他のすべてのルールに対して評価されなくなります。
関連情報

関連するコンテンツ
- 質問済み 2年前lg...
- AWS公式更新しました 6ヶ月前
- AWS公式更新しました 10ヶ月前
- AWS公式更新しました 1年前
- AWS公式更新しました 3年前