はじめに
AWS WAFのマネージドルールについて、観測範囲における誤検知あるある事象をまとめておく。
AWS WAFの意図せぬブロックあるあるを知りたい。
— mazyu36 (@mazyu36) 2023年1月18日
複数のプロジェクトで経験したのはリクエストボディ8kb越えでブロックされるのと、OIDCのエンドポイントへのリクエストがSQLインジェクションにされるやつ
- 概要とよくとる対処方法を記載している。ただし対処についてはサービスの要件等を踏まえ、どこまでのリスクを許容するかを判断して設定する必要がある。
- 緩和する際もいきなり
Allowにするのではなく、Countモードを活用し想定通りの挙動となるか確認した方が良い。以下参考リンク。
- はじめに
- リクエストボディ8kb越えによるブロック（SizeRestrictions_BODY）
- ファイルのアップロードがブロックされる（複数ルール）
- クラウドプロバイダー経由のアクセスによるブロック（HostingProviderIPList）
- 認可リクエストがSQLインジェクションと判断されてブロック（AWSManagedRulesSQLiRuleSet）
- ALB-Cognito連携におけるブロック（複数ルール）
リクエストボディ8kb越えによるブロック（SizeRestrictions_BODY）
※2024/3/13追記 AWSのアップデートにより以下のように改善されました。
概要
AWSManagedRulesCommonRuleSetのSizeRestrictions_BODYが該当する。
観測範囲では最も見る事象。
リクエストボディが8kbを超過する場合はブロックするというものであり、例えばファイルのアップロード機能やリストの送信機能等がある場合は高確率で引っかかる。
SizeRestrictions_BODY
Inspects for request bodies that are over 8 KB (8,192 bytes).
対処方法
以下のような対処をすることが多い。
- URIを特定できない場合（サイズ超過のパスが大量にある等）の場合は、
SizeRestrictions_BODYを除外することを検討する。
ファイルのアップロードがブロックされる（複数ルール）
概要
ファイルのアップロード機能がある場合、いろいろなルールに引っかかりやすい。AWS公式のknowledge-centerにも掲載されている。
該当するルールは以下であり、ファイルのランダムな文字列に反応し、攻撃と誤検知してしまうケースがある。
- CrossSiteScripting_BODY
- SQLi_BODY
- WindowsShellCommands_BODY
- GenericLFI_BODY
- SizeRestrictions_BODY ※これは前述のリクエストボディのサイズ制限
対処方法
XSSやSQLインジェクションのルールは除外を避けたいので、ヘッダーやURIを元にスコープダウンステートメントを使用して、特定のリクエストのみWAFの検査対象外とすることが多い。
なお上記によらず、ファイルのマルウェア対策は検討が必要。
クラウドプロバイダー経由のアクセスによるブロック（HostingProviderIPList）
概要
AWSManagedRulesAnonymousIpListのHostingProviderIPListが該当する。
クラウドプロバイダーからのアクセスなどエンドユーザーからのトラフィックの可能性が低いものをブロックするというものである。
HostingProviderIPList
Inspects for a list of IP addresses from hosting and cloud providers, which are less likely to source end-user traffic. The IP list does not include AWS IP addresses.
よく見るケースとしては以下のようなものがある。
対処方法
以下のようにすることが多い。
- 広く一般的に公開するサービスの場合は
HostingProviderIPListを除外する（過去の事例では誤検知がかなり多く、邪魔でしかなかったケースあり）。 - クローズドに公開するサービスの場合は、スコープダウンステートメントにおいてIPを元に地道に除外設定をする。
認可リクエストがSQLインジェクションと判断されてブロック（AWSManagedRulesSQLiRuleSet）
概要
AWSManagedRulesSQLiRuleSet全般が該当するが、特にクエリパラメータに関するルールが該当（SQLi_QUERYARGUMENTS, SQLiExtendedPatterns_QUERYARGUMENTS）。
OAuthやOIDCにおける、認可リクエスト（認可エンドポイントへのリクエスト）がSQLインジェクションと判断されやすい。
特にクエリパラメータには様々な値を入れるため引っかかりやすい（経験があるのはKeycloakなど）。
対処方法
SQLインジェクションのためルール自体の除外は避け、ヘッダーやURIを元にスコープダウンステートメントを使用して、特定のリクエストのみWAFの検査対象外とすることが多い。
ALB-Cognito連携におけるブロック（複数ルール）
概要
ALBとCognitoで連携し、コード変更なしでマネージドなユーザー認証の仕組みを作る手段がある。
フローは上記参考資料から抜粋。
一方CognitoでWAFサポートが行われ、Hosted UIの保護などを目的としてCognitoに対してWAFを適用することがある。
※ALB-Cognito連携している状態で、ALBとCognitoにWAFを付与しても2重になるだけで意味ないのでは？と少し思ったが、直接Auth Endpointにアクセスしてきた場合などはCognitoに付与していないと防げない認識。違ってたらこっそり教えてください。
この時以下のリクエストがブロックされる。
/oauth2/authoraize：認可エンドポイントへのリクエスト。AWSManagedRulesSQLiRuleSetによりブロックされる。1つ前の事象と同様のもの。/oauth2/token：トークンエンドポイントへのリクエスト。AWSManagedRulesCommonRuleSetのNoUserAgent_HEADERによりブロック。ヘッダーにUser-Agentが存在しないことで検知される。
対処方法
パスが特定できているため、スコープダウンステートメントを元にWAFの検査対象外とする。
