WAFに画像アップロードを阻まれたのを解決した話

Transcript

1. WAFに画像アップロードを阻まれたのを解決した話 2025/9/11 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 池田瑞生 JAWS-UG初心者支部#68 残暑のサメとあざらしSecurity-JAWSコラボLT回 LT資料
2. 2 自己紹介 • 名前：池田瑞生 • 所属：日本アイ・ビー・エム システムズ・エンジニアリング株式会社 • AWS歴 - 2023年4月新卒入社 - インフラ担当者として基盤設計構築業務などに従事 • AWSの資格 - AWS Certified Cloud Practitioner - AWS Certified Solutions Architect – Associate - AWS Certified Developer – Associate
3. 3 おことわり • 本資料の内容は個人の見解です。所属組織を代表する意見ではありませんので、ご理解ご認識のほ どよろしくお願いいたします。
4. 4 はじめに 概要: • WebアプリケーションからのS3への画像アップロード時の500エラー報告から始まった、AWS WAF関連のエラー解決 の紆余曲折をお話します。 本日の構成: • 1. システム構成と調査の経緯 - どのような報告があり、どのような環境で問題が起きていたのか。 • 2. 調査フェーズ1：500エラーの正体を突き止める - 報告された500エラーの裏に隠れていた、本当の原因をどう見つけたか。 • 3. 調査フェーズ2：403エラーの原因をWAFだと断定する - なぜWAFが原因だと確信できたのか。そのための切り分け検証プロセス。 • 4. 調査フェーズ3：原因となっているWAFルールを特定する - どのルールが影響していたのか。特定した具体的な手法。 • 5. まとめ
5. 5 システム構成の概要 CloudFrontをフロントに置いた一般的なSPA構成で、WAFによるセキュリティ対策と、Lambda@EdgeによるBasic 認証が導入された構成でした。 AWSManagedRulesCom monRuleSet を適用中 origin-request に Basic認証用関数を関 連付け カスタムエラーレスポンス: 4xx系のエラーを index.htmlに転送 Webアプリケーション distribution WAF Basic認証用 Lambda@Edge ユーザー Amazon API Gateway Amazon ECS (バックエンドアプリ） アップロード画像 保管用バケット
6. 6 AWS WAF Webサイトを不正なアクセスから守るためのファイアウォールです。CloudFrontなどに設置し、怪しい通信をブロックして くれます。 Web ACL: • WAFで使う「ルールの集まり」のことです。 • 「こういう通信は許可」「こういう通信はブロック」といったルールをまとめたもの。 マネージドルールグループ: • AWSが予め用意してくれている、便利なルールのセットです。 • 今回は ”AWS-AWSManagedRulesCommonRuleSet” をWeb ACLに設定し、一般的な攻撃か らシステムを保護していました。 • ルールに引っかかったときの動作としてBlock/Allowの他にCountというヒットしたリクエストを数えるだけの ものもあります。 包含関係: • WebACL>ルールグループ＞細かいルール
7. 7 Basic認証 アクセスを制限するBasic認証。IDとパスワードを知っている人だけが先にすすめます。 • Webサイトにアクセスした際に、ブラウザがIDとパスワードの入 力を求める小さなウィンドウを表示します。 • 正しい情報を入力しないと、コンテンツを見ることができません。 • 開発中の環境など、関係者以外にページを見られないように するための、シンプルで一般的なアクセス制限。 • 今回はこれをLambda@Edgeで実現していました。 • リクエストヘッダーに認証情報を含めて送信してる
8. 8 CloudFrontのカスタムエラーレスポンス機能 特定のエラーが発生した時に、指定した別のページ（例: トップページ）を代わりに表示させることができます。 • 通常、403や404といったエラーが起きると、ブラウザ標準のそっけないエラー画面が表示されます。 • 今回はエラーが起きてもトップページが表示されるように設定していました。 • ユーザーにエラーを感じさせず、サイト内に留まってもらうための工夫。
9. 9 調査の経緯 • アプリケーションに画像アップロード機能を実装中という状況 • アプリチームからローカルだと動くアップロード機能がAWSにデプロイしたらうまくいかないという相談をうけました。 • 再現するか確かめてみると - 実際に同様の環境で操作を試すと、確かに画像がアップロードされませんでした。 - ブラウザの開発者ツールを確認すると、POSTリクエストに対して500 Internal Server Errorが返されていまし た。 → この500エラーを起点に、調査を開始しました。
10. 10 調査1-1 500エラーの正体を突き止める ログ調査で後段にリクエストが届いていないことを確認し、設定を見直すことで、WAFの403エラーが隠されていたことを 突き止めました。 distribution WAF Basic認証用 Lambda@Edge ユーザー Amazon API Gateway Amazon ECS (バックエンドアプリ） 仮説1: アプリケーションのバグ？ 調査: APIGWやECSのアプリケーションログを詳細に確 認。 結果: しかし、該当する時間帯にリクエストが到達した痕 跡が全くなかった。 仮説2: そもそもリクエストが後段に届いていない? 調査範囲をCloudFront自身に絞り込む。 CloudFrontの設定を見直し、エラーの挙動を変化さ せているカスタムエラーレスポンスの設定を発見。 「このエラーページの設定を削除して、素の状態をみて みよう」となる。 → 結果500エラーではなく画像アップロード時の本 来のエラーは403であることに気づく
11. 11 調査1-2 500エラーの正体を突き止める カスタムエラーレスポンスの設定とorigin-request に関連付けしたBasic認証用関数により403エラーが500エラーに 見えていました。 distribution WAF Basic認証用 Lambda@Edge ユーザー Amazon API Gateway Amazon ECS (バックエンドアプリ） ① WAFでリクエストがブ ロックされる ② カスタムエラーレスポンス 機能が働きCloudFrontが index.htmlを取りに行く ③ origin-request に 関連付けしたBasic認証 用関数が認証情報がな いので500を返す ④ 500エラーを受け取る
12. 12 調査2 - 403エラーの原因をWAFだと断定する この403エラーの原因を探るため2つの切り分け検証を行い、その結果WAFが原因であると確定しました。 Amazon API Gateway 検証1：WAFを経由しない経路でのテスト 調査: CloudFrontを通さず、API Gatewayのエンドポイントを直接リクエ ストする。 結果: 成功 (HTTP 200) → バックエ ンドのアプリケーションは正常であると確 認。 検証2：WAFのみを無効化するテスト 調査: CloudFrontの設定から、WAFの Web ACLのみを一時的にデタッチする。 結果: 成功 (HTTP 200) → CloudFrontの他の機能は問題ないことを 確認 → 上記2つの検証が成功したことにより、 403エラーの原因はWAFであると断定で きた。 distribution WAF Amazon ECS (バックエンドアプリ） Amazon API Gateway Amazon ECS (バックエンドアプリ）
13. 13 調査3 - 原因となっているWAFルールを特定する Countモードへの切り替えとテストを繰り返し原因となるルールを特定しました。 • 設定していたマネージドルールグループ内の細かい ルールのBlock/Count を変更しながら画像をアッ プロードし原因となるルールを絞り込み。 → SizeRestrictions_BODY （リクエストボディ のサイズを検査するルール）が原因だと判明。 • ルールグループ全体を一度Countモードにし てログを確認し、原因ルールを特定すると いうこともできそうだと後から気づく
14. 14 結局何が起きていたのか ① 500エラーの原因 • ユーザーの画像アップロードがWAFで止まる（本来は403） • CloudFrontの仕組みで、403のときに /index.html を内部で取りに行く設定が動作 • その内部取得に対して origin側の Basic 認証（Lambda@Edge） が働き、認証がうまくいかず処理が失敗。 • その結果、外から見ると 500エラーのように見えていた。 ② 403エラーの原因 • API Gateway を直接叩くと成功。 • CloudFront から WAF を外すと成功。 • WAFが原因と特定。 ③ WAFのどのルールがアップロードを阻んでいたか • Countモードによる調査の結果、CommonRuleSet内のSizeRestrictions_BODYルールがブロックの原因であ ると特定できた。 → 問題のルールを Count に切り替え、対象をアップロード経路だけに限定しました。
15. 15 まとめ • カスタムエラーレスポンスの設定はよく知らないままとりあえず入れていたのでここを疑うのに少し手間がかかりました。自 分がしていることを理解しながら実施するのは大切だなと学びました。 • WebACLのルールグループの細かい設定について詳しく知らないまま使っていましたが、中身を調べてみる良い機会に なりました。 • 調査段階ではログはしっかり取っていたのが役に立ちました。一方でログの保管期間が短くて今回のために見返したら 消えていて少しがっかりでした。 • ややこしい問題を自分で解決できて自信になりました。