[アップデート]AWS WAFに不正なアカウント作成対策向けのAWSマネージドルールグループが追加されました

初めに

先日のアップデートにてAWSが提供するマネージドルールに不正なアカウント作成(ASFP)に対する防御のためのルールグループが追加されました。

本ルールグループはBOTによる機械的なアカウントの作成といった不正なアカウントへの対策に特化したルールグループとなります。

含まれるルール

ルール数も多いため以下のマネージドルールグループのページをご参照ください。

ルールの傾向としては繰り返しや一定アクセスパターンにに対するアクションも多くBOT ControlのTargetに一部通じるものはありますが、電話番号の繰り返しの規則的な入力パターンの検知等の会員登録ページ特有のパターンに特化したルールとなります。

また、デフォルトでは対象ページのすべてのリクエストに対してChallengeアクションを行うようになっておりBOTを許さないという気配を感じます。

料金

本マネージドルールを適用する場合通常のWAFの料金に加えて本ルールグループの検査数による追加料金が発生します。 (執筆時英語ページのみに記載有)

https://aws.amazon.com/waf/pricing/

執筆時点では本ルールグループの料金は$1.00/"1k"リクエスト(10kリクエスト以降、2Mリクエスト迄)となっており、Bot ControlのTargetが$10.00/"1M"リクエストとなります。

１リクエストあたりの検査料金をBot ControlのTargetと比較すると100倍近くの差があるため、相対的にですが高額なルールとなりそうです。

実際には本ルールグループは会員登録ページといった極一部のページで使うことになりますので、本ルールによる検査リクエスト自体がそこまで多くならない可能性もあります（サイト特性による）。

検討される際は単純にリクエストあたりの料金だけではなく、この点も含めご検討いただければと思います。

ルールグループ固有の設定値

本ルールグループ固有の設定値として、会員登録ページおよび登録情報送信先ページや、登録情報送信時に検査をする必要がある電話番号などの属性キーの指定があります。

ログイン・会員登録ページ、ログインの成功・失敗時のボディの指定は必須となり他はオプションとなりますが、試す限りオプション値は未指定の場合プレースホルダーで見えるキー相当のもので探索されるのではなくその属性は判定されなくなるようです。

電話番号や住所といった属性のチェックも行えるので、本来の用途ではないかと思いますがECサイトのゲスト注文での不正受注対策といった別の部分の対策にも使えないか？と思いを馳せているところではあります。

認証情報の判定

リクエストの繰り返し以外でわかりやすく見えそうなのがこちらの項目であったため試してみました。

admin/passwordといったありがちな単純にパスワードで送信してみましたところブロックが確認され、ラベルでもawswaf:managed:aws:acfp:signal:credential_compromisedが付与されており、SignalCredentialCompromised起因でブロックされていることが確認できます。

"labels":[
    {"name":"awswaf:managed:aws:acfp:risk_score:high"},
    {"name":"awswaf:managed:token:accepted"},
    {"name":"awswaf:managed:aws:acfp:risk_score:contributor:stolen_credentials_credential_pair:high"}, 
    {"name":"awswaf:managed:aws:acfp:signal:credential_compromised"},
    {"name":"awswaf:managed:aws:acfp:signal:creation_page"}
]

awswaf:managed:aws:acfp:risk_score:highで接続元が危険なIP扱いされたり色々なタグがついていますが、弾かれなさそうなランダムな文字列で再度アクセスしてみると特に拒否されなかったので各種ラベルは複合的な要因でつくこともありそうです。

一方SignalCredentialCompromisedは他ルールに比べID/PWを使い回ししている方等を意図せずブロックしてしまう等リスクの高いルールとは感じます。

対応の一例として公式ドキュメントではルールアクションをCountに変更し、カスタムレスポンスによりユーザに情報提供を行う設定例が提示されています。

安全性的にこのルールに引っかからないユーザ登録をしてもらうのが良いとは思いますが、とはいえユーザ層的にここが壁となり会員登録をやめてしまう問題もあるかと思いますのでサイトの作り的に問題ないかだけではなく、ユーザ層的に許容できるものであるかというのも含め設定を検討する必要が出てきそうです。

検査対象が絞り込まれているルールもある

AWS WAFにはルールの設定としてスコープダウンステートメントを設定することにより特定のパスのみにルールやルールグループを適用することができます。

ただ本ルールグループではそれとは別に含まれるルールによってそれとは別に特定のパスのみを検査するようになっているようです。

Applies the rule action to requests that access the registration page path. You configure the registration page path when you configure the rule group.

例えばAllRequestはregistration page pathで指定されるパスのみが対象と明記されています。

ただ実際の挙動を見る限りcreation page pathに対してもChallengeは行われていることを考えるとこのルールに限らず、明記されていないだけでルール内部的に判定先のパスは絞り込まれているかもしれません。

#関係のないindex.htmlにアクセスした場合はChallengeが行われずステータスが200で返却される
% curl https://xxxxxx.cloudfront.net/index.html --verbose
....
< HTTP/2 200
< content-type: text/html
< content-length: 413
< date: Thu, 15 Jun 2023 05:32:05 GMT
...
# registration page pathで指定したentry.htmlにアクセスすると202が返却される(Challengeアクションの挙動)
% curl https://xxxxx.cloudfront.net/entry.html --verbose
...
< HTTP/2 202
< server: CloudFront
< date: Thu, 15 Jun 2023 05:32:10 GMT
...
# ただし同じパスであってもGETには反応するがPOSTには反応しない(405になってるのは別の設定起因です)
% curl https://xxxxx.cloudfront.net/entry.html --verbose -X POST
...
< HTTP/2 405
< content-type: application/xml
< allow: HEAD, DELETE, GET, PUT
< date: Thu, 15 Jun 2023 05:32:29 GMT
< server: AmazonS3
...
# creation page pathに指定したlogin.htmlにアクセスした場合も同様にChallengeが行われる
% curl https://xxxxx.cloudfront.net/login.html --verbose -X POST
...
< HTTP/2 202
< server: CloudFront
...
# creation page pathに対しては逆にGETには反応せずPOSTが反応する
% curl https://xxxxx.cloudfront.net/login.html --verbose
...
< HTTP/2 200
< content-type: text/html
< content-length: 12
...

仕組みとして検査はされていないようですが、スコープダウンステートメント側で対象外にせずルールの内部側として検査されていない場合、課金対象外となるかまでは今回見れていないのでスコープダウンでも絞り込んだ方が良い可能性がある点は留意いただければと思います。

終わりに

今回新しく追加されたマネージドルールグループは主にはBOT対策とはなりそうですが、Bot Controlと比べ会員登録というユースケースに特化している分具体的な項目への対策ルールもあり、ユースケースさえ合えば強力な防御手段としての選択肢の１つとして考えられそうです。

SignalCredentialCompromisedは強力すぎて利用者への影響が出てしまうような気もしますが、情報DBも自動でアップデートされるようなのでこれを強制できるようなシステムであれば不正なユーザ作成からサイトを守るだけではなく、通常利用者に危険度の高い認証情報を使わせず守るということもできそうで非常に興味深いルールとなっております。

BOT等対策は行っているもののいまいち効果が出ず不正なユーザを作成されてしまっているようなケースに対して有効となるケースがあるかもしれないため、事象として困っているのであればまずはCountで設定し影響が出ない範囲でどの程度防御できる余地があるか一度試してみてはいかがでしょうか。

また今回は特に触れていなかったのですが、現在まだサポートされていないようですがCognitoに関する検査も含まれているので将来的にそちらへのアクセス経路にも対応される可能性がありそうなので楽しみなところではあります。